12-04-2021 10:00 AM
Hi all,
I am doing several tests with routers that support 4-byte AS numbers, both IOS and IOS-XR and I am encountering a strange behavior.
The BGP sessions are established correctly no matter what AS number I use, but there is something strange, when I analyze the OPEN messages I see that the ones that use an AS > to 65535 have in the 'My AS' field the AS_TRANS (23456).
For example:
R1 (AS99000) <-> RS (AS77000)
Both establish a BGP session without problems but both OPEN messages have the AS_TRANS in 'My AS', why this behavior?
One additional question:
In today's enterprise networks where all routers support 4-byte AS, do you think it is necessary to migrate the private range from 64512 -65534 to the private range 4200000000 - 4294967294?
Thanks in advance,
Solved! Go to Solution.
12-04-2021 12:13 PM - edited 12-04-2021 12:21 PM
Hi @TelesEC ,
> Both establish a BGP session without problems but both OPEN messages have the AS_TRANS in 'My AS', why this behavior?
This is expected behavior. The 4 octet ASN capability is negotiated through the open message. As you do not know whether the peer supports 4 octet ASN or not, you can't pass the 4 octet ASN in the "My AS" field. The "My AS" field is defined as 16 bits and could not contain the 4 octet ASN anyway. The 4 octet ASN is rather specified as part of the 4 octet ASN negotiation section of the open message. For more information, please refer to RFC6793.
https://datatracker.ietf.org/doc/html/rfc6793
> do you think it is necessary to migrate the private range from 64512 -65534 to the private range 4200000000 - 4294967294?
You can certainly start using the extended private range if you want. I haven't seen that many customers needing to move to the extended range though.
Regards,
12-04-2021 12:13 PM - edited 12-04-2021 12:21 PM
Hi @TelesEC ,
> Both establish a BGP session without problems but both OPEN messages have the AS_TRANS in 'My AS', why this behavior?
This is expected behavior. The 4 octet ASN capability is negotiated through the open message. As you do not know whether the peer supports 4 octet ASN or not, you can't pass the 4 octet ASN in the "My AS" field. The "My AS" field is defined as 16 bits and could not contain the 4 octet ASN anyway. The 4 octet ASN is rather specified as part of the 4 octet ASN negotiation section of the open message. For more information, please refer to RFC6793.
https://datatracker.ietf.org/doc/html/rfc6793
> do you think it is necessary to migrate the private range from 64512 -65534 to the private range 4200000000 - 4294967294?
You can certainly start using the extended private range if you want. I haven't seen that many customers needing to move to the extended range though.
Regards,
12-04-2021 12:49 PM
Thank you very much for your quick and excellent response, it has been a great help to me.
Regarding my second question, do you think it is necessary to migrate from the 'old' private AS rang to the new private AS rang? Or can both private rangs cohabit indefinitely?
Regards,
Andrés
12-04-2021 01:14 PM - edited 12-04-2021 01:22 PM
Hi @TelesEC ,
You are very welcome.
I do not think you actually need to migrate from the initial range to the extended range. The initial range provides for plenty of ASNs. Just make sure that all of you network devices support 4 octet ASN before you decide to go down that path. And yes, both ranges can cohabit indefinitely.
Regards,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide