This topic is to discuss the following lesson:

Hi Rene,

Very Good Stuff.A quick questions for you â€¦

How R2 know R1 only 2 byte supported before sending any open message ??

br//zaman

Hi Zaman,

It doesnâ€™t. When R2 receives a reply from R1 without the â€śsupport for 4-octet AS number capabilityâ€ť in its OPEN message, it knows that R1 doesnâ€™t support it.

You can see it in the wireshark capture:

https://www.cloudshark.org/captures/d8e5e9240959

Take a look at the 1st packet from R2 and the 2nd packet from R1. R1 is missing the capability.

Hope this helps!

Rene

Hi Rene,

I have question in 2-Byte & 4-Byte AS compatibility situation.

In case of we adding R3 (AS3) and connect it to R2. R1 advertises one prefix (for example: 1.1.1.1/32) to R2 and R2 will forward to R3.

What will be in the AS path on R3? (22222222 1 or 23456 1)?

Thanks,

Minh

Hello Minh

This is an excellent question. Essentially what you are asking (allow me to put it more generally) is how is the AS path displayed when there is a 2-byte AS compatible router in the mix?

Well, if you display the AS path on the 2-byte AS compatible router, then you will see the 23456 AS in place of the incompatible 4-byte AS number. So essentially the AS_TRANS attribute replaces the 4-byte AS number. However, the AS4 PATH number is an attribute that is received by the 2-byte AS compatible device, and is transitive. It may not understand it, but it will send it down the line. So if you have yet another router connected to your R3 that is 4-Byte AS compatible, it will receive the AS4 path attribute correctly and actually use the correct 4-Byte ASâ€™s for the full path.

I hope this has been helpful!

Laz

Thanks Laz for the explanation.

Enjoy your weekend,

Minh

If we had another router R3 (4 byte support) connected to R1 (2 byte support), then on R1 we would configure R3 neighbor using the same 23456 AS (neighbor 192.168.13.3 remote-as 23456)? R1 would have believed that it is dual homed connected to the same AS?

Thanks,

Stefanita

Hello Staut

Yes, that is correct. This is a limitation of the feature and thus must be used carefully,. This could result in routers using the 4-byte AS not being able to reconstruct the entire AS path information correctly.

I hope this has been helpful!

Laz

Hi Laz,

Will the My AS field always set o 23456 in open message when the router is configured for 4 byte AS. I am unable to test and capture it since my lab device donâ€™t have support for 4 Byte AS, Could you please let me know.

Regards,

Madhu.

Hello Madhu

If you have an AS of 23456 and you are using 4 byte AS, then BGP will always place the 23456 AS in the My AS field, and will place the actual 4byte AS in the Optional Parameters field as the â€śSupport for 4-octet AS number capabilityâ€ť. You can see this in the cloudshark capture in the lesson, and as shown below:

I hope this has bee helpful!

Laz

I think one the examples is wrong. The result of #AS 5434995 should be 82.61043, not 82.6104. Am i correct?

Hello Remy

Yes, you are correct, it seems that itâ€™s a typo. I will let @ReneMolenaar know.

Thanks for pointing it out!

Laz

Hi Guys,

Shouldnâ€™t AS 65538 become 1.2?

*"For AS numbers above 65535, we use the next high order bit value and start counting again at 0. For example:*

*AS 65536 becomes 1.0*

*AS 65537 becomes 1.1*

*AS 65538 becomes 1.1"*

Thanks,

Gareth.

Hi Gareth,

I just fixed this error, thanks.

Rene

Hi Rene,

what would be the range for higher bit Asdot+ starting from ::

65536- 1.0

65537-1.1

65538-1.2

!

!

!

will be continued till last AS no but what will be the last AS value for this ( ? becomes ?.?) .

Also please emphasize it in this way that it can show starting, Medium and last values ?

Hello Pradyumna

If you continue this sequence, you will get:

- AS 65536 becomes 1.0
- AS 65537 becomes 1.1
- AS 65538 becomes 1.2
- â€¦
- â€¦
- AS 131071 becomes 1.65535
- AS 131072 becomes 2.0
- AS 131073 becomes 2.1
- AS 131074 becomes 2.2
- â€¦
- â€¦
- AS 4294967296 becomes 65535.65535
- AS 4294967297 becomes 65536.1
- AS 4294967298 becomes 65536.2
- â€¦
- â€¦
- AS 4295032831 becomes 65536.65535
- AS 4295032832 becomes 65536.65536

Now all of these values can be calculated, but many of them are reserved for various purposes including private ASâ€™es and other uses. These can be seen at the following IANA link. Another cool tool you might find useful is this IANA converter of the various ASN formats.

I hope this has been helpful!

Laz

Hi Laz,

Thanks for this explanation but I think it must be stopped at AS 4295032831 becomes 65536.65535 as we know sequence started from 1.0 and 0-65535 makes total count 65536 and so 1-65536 makes total count 65536 so according to last AS value post dotted notation becomes 65537th which is exceeding the range.

Am i right or not ?

Hello Pradyumna

My numbers were incorrect. It seems it should actually end at **4294967295** which is **65535.65535** which in binary is just **32 ones**. But I was using the IANA converter to verify, and it seems to be able to convert ASNs up to **4295032832** or **65536.65536** which is incorrect, because in order to represent these numbers you need 33 bits, but ASNs are only 32 bits.

So it seems that IANAâ€™s converter is incorrect unless there is some other explanation for this.

I hope this has been helpful!

Laz

Thanks Laz for this correction and well explanation.

But Still confused for 65536 range b/c as per total counts b/w range, it should be up to 65536:65535 b/c before decimal value staring from 1 not 0?

Hello Pradyumna

Remember that asdot simply represents a 32 bit binary number. In binary, we have:

`11111111111111111111111111111111`

We can separate this into two 16 bit numbers like so:

`1111111111111111 1111111111111111`

Now if we translate these into decimal and put a dot between them we get:

65535.65535

This is the highest AS number you can get. Remember, that we start counting at 0, and if you include 0, we have a total number of 65536 values, but in decimal their representation goes from 0 to 65535.

I hope this has been helpful!

Laz