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
1 Like
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
2 Likes
Thanks Laz for the explanation.
Enjoy your weekend,
Minh
1 Like
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
1 Like
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
1 Like