Local AS
Last updated
Last updated
Topology: russo-bgp-iol
Load unix:local.as.init.cfg
R1 is now in AS 64901 and R6 is now in AS 64906. ASN 65000 has not been updated to use R1 and R6’s new ASNs.
On R1 and R6 we must allow the peering sessions with AS 65000 to form without changing the global ASN.
On R1, allow R2 to peer with either 64901 or 65001. This will allow R1 to easily switchover in the future.
On R6, we will not allow R4 or R5 to peer with 64906.
On R6, prepend routes received from R4 with 65006, and prepend routes sent to R4 with 65006
On R6, do not prepend routes received or sent from/to R5.
First, here is a tip to reduce the flood of “received NOTIFICATION from peer, peer in wrong AS” messages if you are using console - use no bgp log-neighbor-changes. This helps you complete the beginning of the lab while the neighbor log messages are occuring. (When using clab, you are using SSH, so this isn’t a problem unless you have term mon enabled).
The local-as feature allows the router to peer with a neighbor using a different ASN than the global ASN. This helps with migrating to a new ASN.
There are a few keywords with this feature that can be a little confusing:
dual-as
Allows the neighbor to peer with the local router using either the local-as or the global ASN.
Must be configured with both no-prepend and replace-as
no-prepend
Does not prepend the local ASN on received routes
Otherwise, received routes have the local real ASN prepended, resulting in [local-real-ASN peer’s-ASN rest-of-AS-path…]
i.e. if the real ASN is 64906 and you are peering with local ASN 65006:
With nothing configured, received paths will have ASN 65006 appended
With no-prepend, received paths will be “as normal”
replace-as
Replaces the global ASN with the local ASN when sending routes to the neighbor
Otherwise, outgoing routes have both the global and the local ASN
In practice, this means that when replace-as is used, the peer only sees routes as coming from the local ASN.
i.e. <local ASN> <rest of path>
When replace-as is not used, the peer sees routes as coming from the peer’s real ASN first.
i.e. <local ASN> <real ASN> <rest of path>
The requirement for R1 is to allow R2 to peer using either ASN. This forces us to use all three keywords.
The requirement for R6 and R4 is for routes received and sent to R4 to have the global ASN prepended. This is the default behavior, so we do not use any keywords.
The requirement for R6 and R5 is for routes received and sent to R5 to not have the global ASN prepended. We use both no-prepend and replace-as to achieve this.
First we’ll verify the peering between R1 and R2. R1 should not prepend any routes received or sent. We can see that ASN 65001 is not seen on received routes:
We also see on R2 that ASN 64901 is not seen on routes sent by R1. R1 is replacing the global ASN with its local ASN.
We should also be able to peer with R1 on its new ASN on R2 with no changes needed on R1.
The peering session immediately comes back up.
The received routes now have R1’s global ASN prepended instead of the local AS.
We’ll now examine the peering on R6. R6 should be prepending routes received from R4 with its local ASN, but not routes received from R5.
Likewise, R6 should be prepending its local ASN on routes sent to R4, but not on routes sent to R5. Notice below that R4 has a better path through R5 because it has a shorter AS_PATH length.
There is no situation in which the router can prepend only its global ASN. This would cause a problem if the peering router was using bgp enforce-first-as, which appears to be on by default.
