Thanks Laz now convinced.
1 Like
Hi,
There is an error on Rene’s example:
#AS 5434995
5434995 / 65536 = 82
5434995 - (82 * 65536) = 61043
asdot = 82.6104
It should be 82.61043.
I could not understand the as-dot here , can you please help me ??
Hello Narad
A 4 byte AS number is represented by 32 bits. For AS numbers less than 65536, these numbers are simply represented as numbers ranging from 1 to 655356. For larger numbers, ASdot represents them as two 16 bit numbers separated by a dot. So for example:
- An AS number of
00000000 00000000 00000000 11111111is
- 256 in decimal
- 256 in Asdot
- 0.256 in Asdot+
- An AS number of
00000000 00000000 11111111 11111111is
- 65535 in decimal
- 65535 in Asdot
- 0.65535 in Asdot+
- An AS number of
00000000 00000001 11111111 11111111is
- 131071 in decimal
- 1.65535 in Asdot
- 1.65535 in Asdot+
So if the two leftmost octets are zeros, then Asdot is the same as decimal. If however there is even a single “1” in any of the two leftmost octets, Asdot will revert to Asdot+.
I hope this has been helpful!
Laz
Hi Team
Would you explain how AS_TRANS calculated, i just didnt see any formula how exactly is created! you pick 23456 for remote as on R1, randomly chosen or whats the base here ? Thanks
Hello Nahro
The AS_TRANS number is defined as 23456 by the IANA and is always the same. The RFC4893 states that:
…this document introduces a reserved 2-octet AS number – AS_TRANS. The AS number 23456 has been assigned by the IANA for AS_TRANS.
I hope this has been helpful!
Laz
1 Like
Thanks Sir Laz
This is why we love Network Lessons, geting reply for all questions
1 Like
Rene/Laz,
With regards to the 4-byte ASNs, what would be appropriate workaround while using communities since standard is limited to 2-bytes. Cisco’s extcommunity attribute doesn’t seem to fit the bill for using route oriented declarations. Would you then be limited to using standard reserved ASNs eg. 65535 for iBGP purposes only? Thanks.
Hello William
It seems that the IETF has provided for such cases by defining a new type of BGP extended community that carries a 4-octet AS. This is defined in RFC5668. However, the set community route-map command can still only accommodate 2-byte ASNs. (Take a look at this Cisco community thread which sheds some light on that).
Cisco’s extended communities have been designed to accommodate 8 octets, which is what is needed for use of communities with a 4-byte ASN, however, these are used most often for MPLS VPN to share the RTs, and can be seen being used in these lessons:
Currently, there doesn’t seem to be a workaround for 4-byte ASNs, however, can you tell us a little bit more about what you want to achieve? It may help in devising a solution to the problem.
Is there a particular scenario that you have in mind? Let us know so that we can help you further.
I hope this has been helpful!
Laz
Hello!
Please, how do we make regular expressions work with 4-byte AS numbers? I have this simple topology here
and I want to only allow routes that originated from AS 1.1 to be accepted from R1
Yet it filters completely everything that comes from AS 1.1 and instead uses the path through AS 1.5 instead
The problem is that it only seems to work if I issue
bgp asnotation dot
but it still takes extremely long to convergence for some reason.
Can someone please explain to me how RegEx works with 4-Byte AS numbers?
Thank you in advance.
David
Hello David
When using a 4-byte AS number in your BGP implementations, then the regular expressions that are used for BGP must conform to the format that has been configured in the local router. For example, if the format you are using is
When using regular expressions with BGP, if you are using a 4-byte format of the ASN, then the syntax must match the configured AS notation. For example, the default notation is ASplain. In such a situation, you must use the decimal number between 0 and 4294967295 in your regular expressions.
If you have configured the device to use ASdot notation, then you must use that notation in your regular expressions. I have confirmed this in the lab. Here you see a BGP table of R1 with the AS displayed using the default ASplain notation:
R1#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.2 0 0 12000013 i
To see what regular expression will match this, we try the following show commands:
R1#show ip bgp regexp ^183.6925$
R1#show ip bgp regexp ^12000013$
BGP table version is 2, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.2 0 0 12000013 i
Note that the first show command tries to display the prefixes that correspond to the ASdot notation of the AS, but there are no results. When using the ASplain notation, we get a result.
Let’s try it the other way around. Below I have changed the notation to ASdot, and have displayed the BGP table once again. You can see that the AS number is displayed as ASdot.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router bgp 12000012
R1(config-router)#bgp asnotation dot
R1(config-router)#exit
R1(config)#exit
R1#show ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.2 0 0 183.6925 i
R1#
Now let’s try to show the prefixes with the appropriate regular expression:
R1#show ip bgp regexp ^12000013$
R1#show ip bgp regexp ^183.6925$
BGP table version is 2, local router ID is 192.168.12.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.12.2 0 0 183.6925 i
R1#
Using the ASplain notation nothing shows up, but using the configured ASdot notation, it shows up.
So the format you should use in your regular expressions for the ASNs should match the configured format in the local router. This is why your regular expression containing ^1\.1$ only matches when the ASdot notation is configured.
I hope this has been helpful!
Laz
Hello Laz
It all makes sense now, thank you for your help!
1 Like
Hello team,
I have a question regarding the backward compatibility with 2 byte AS systems.
In the Wireshark capture from the second example (1.2 2-byte AS support) we see that R2 (192.168.12.2) sends a BGP OPEN message with My AS: 23456 (AS_TRANS).
Here is my question:
How would the R2 router know (at this point) that his peer is not capable of supporting 4 byte AS numbers? There must have been a previous exchange of messages, correct?
Or is it the default behavior of 4 byte supported AS routers to send the BGP OPEN message in this format and include the “real” AS in the Capability field.
In my opinion the only way how R2 could know that its eBGP peer only supports the 2 Byte AS numbers is the fact that R1 tried to peer with R2 on AS number 23456. → However this message is not visible in the capture. It starts with R2.
Thank you for clarifying this.
Hello Thomas
Take a look at the BGP OPEN message format as indicated in RFC 4271:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Autonomous System |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Optional Parameters (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the “My Autonomous System” or "My AS"field is 16 bits (or 2 bytes) in length, and it is fixed. If the BGP router is using 2-byte ASes, the AS value will simply be found in the “My AS” field. However, if the BGP router is using 4-byte ASNs, the value of the My AS field will always be 23456, and the value of the 4-byte ASN will be found in the optional parameters where 4-byte ASN number capability is expressed.
This way, if the neighboring BGP router is capable of reading 4-byte ASNs, it will see the AS_TRANS value of 23456 and it will know to look for the 4-byte ASN value in the optional capabilities field. If the neighboring BGP router is incapable of reading 4-byte ASNs, it will simply use the 23456 and ignore the optional parameter.
So you don’t have to establish ASN 4-byte compatibility between BGP neighbors before exchanging OPEN messages. It’s just a matter of interpretation of the information found in the OPEN message itself.
The ASN appears only in the OPEN message. Once established, ASNs are no longer exchanged between BGP routers other than as part of the AS_PATH values.
I hope this has been helpful!
Laz