BGP AS-PATH manipulation techniques: local-as, prepending, allowas-in, as-override

The AS-PATH is one most interesting BGP path attribute. It's a well known, mandatory, and transitive path attribute, so it must be included in every BGP Update. It is primarily used to influence inbound path selection (with prepending) and used as a loop prevention mechanism: if a router receives an NLRI with his own AS number in the AS-PATH, it discards that NLRI. In this post we're going to take a look at few techniques how we can manipulate this attribute: how we can migrate from an AS to a different AS without negotiating with our eBGP peers, and also how we can "disable" the loop prevention feature.

We're going to work with the following simple topology:

Local-AS

We're starting with the Local-AS feature. We use this when we want to change our AS number, but without negotiating with our eBGP peers. So let's say R3 which is in AS 30 now, migrates to AS 3000. His eBGP neighbors R2 and R4 won't be notified, so their configuration won't change. R2 still thinks that R3 is in AS 30: neighbor 100.0.23.3 remote-as 30, and the same thing is true for R4, on R4 R3 is configured as the following: neighbor 100.0.34.3 remote-as 30.

Now let's change the ASN on R3:

R3(config)#no router bgp 30
R3(config)#router bgp 3000
R3(config-router)#neighbor 100.0.23.2 remote-as 20
R3(config-router)#neighbor 100.0.23.2 local-as 30
R3(config-router)#neighbor 100.0.34.4 remote-as 40
R3(config-router)#neighbor 100.0.34.4 local-as 30

The local-as command changes the ASN in the BGP OPEN message, which has to match with the remote-as command configured on the remote peer. This is the BGP OPEN message R3 sends to R4 for example:

BGP OPEN R3 sends to R4 — BGP OPEN sent from R3 to R4

R3 advertises that he's in AS 30, he hides his real AS number (AS 3000). AS 30 matches with the remote-as command configured on R4, so they can become neighbors. They send BGP KEEPALIVES to each other, and now they can exchange prefixes. So R3 effectively "lies" about his real AS number, if we didn't issue the local-as 30 command on R3, it would advertise AS 3000 in his BGP OPEN, and we would see messages like the following:

BGP-3-NOTIFICATION: received from neighbor 100.0.34.4 passive 2/2 (peer in wrong AS) 2 bytes 0BB8
BGP-5-NBR_RESET: Neighbor 100.0.34.4 passive reset (BGP Notification received)
BGP-5-ADJCHANGE: neighbor 100.0.34.4 passive Down BGP Notification received
BGP_SESSION-5-ADJCHANGE: neighbor 100.0.34.4 IPv4 Unicast topology base removed from session BGP Notification received

In that case R4 would send back a BGP NOTIFICATION, effectively terminating the BGP session. Now let's take a look how the local-as command changes the AS-PATH attribute. R1 advertises the 1.1.1.1/32 prefix in this topology, so let's take a look at the BGP table of R3 first:

R3#show bgp ipv4 unicast | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.23.2 0 30 20 10 i

We can see that by default R3 prepends his old ASN (AS 30) for the prefixes RECEIVED from any eBGP peer. Now let's check the BGP table of R4:

R4#show bgp ipv4 unicast | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.34.3 0 30 3000 30 20 10 i

R3 prepends this new ASN (AS 3000) and also his old ASN (AS 30) to the AS-PATH for prefixes sent to any eBGP peer. Notice that R3 also has to prepend his new ASN (AS 3000) to prevent routing loops.

BGP Update between R3 and R4 — BGP Update sent by R3 to R4: R3 prepends his new ASN (AS 3000) and his old ASN (AS 30) to the AS-PATH

Local-AS with no-prepend

What if we configure our remote peer with the no-prepend keyword like this (notice that this is also a disruptive operation, normally we would do this in a maintenance window):

R3(config-router)#neighbor 100.0.23.2 local-as 30 no-prepend
BGP-5-NBR_RESET: Neighbor 100.0.23.2 reset (Local AS change)
BGP-5-ADJCHANGE: neighbor 100.0.23.2 Down Local AS change
BGP_SESSION-5-ADJCHANGE: neighbor 100.0.23.2 IPv4 Unicast topology base removed from session Local AS change
BGP-5-ADJCHANGE: neighbor 100.0.23.2 Up

Now R3 doesn't prepend his old ASN (AS 30) for routes RECEIVED from eBGP peers:

R3(config-router)#do show ip bgp | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.23.2 0 20 10 i

Now we don't prepend AS 30 in the AS-PATH as we did previously. Notice that this doesn't affect routes ADVERTISED to eBGP peers, this command only applies to routes learned INbound. R3 still prepends his old ASN (AS 30) and new AS (AS 3000) when he sends the prefix to R4:

R4#show bgp ipv4 unicast | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.34.3 0 30 3000 20 10 i

Local-AS with no-prepend replace-as

Let's take a look at what the replace-as keyword does, when we use with the no-prependlike this:

R3(config-router)#neighbor 100.0.23.2 local-as 30 no-prepend replace-as
BGP-5-NBR_RESET: Neighbor 100.0.23.2 reset (Local AS change)
BGP-5-ADJCHANGE: neighbor 100.0.23.2 Down Local AS change
BGP_SESSION-5-ADJCHANGE: neighbor 100.0.23.2 IPv4 Unicast topology base removed from session Local AS change
BGP-5-ADJCHANGE: neighbor 100.0.23.2 Up

Configuring this would also terminate the BGP session. This command actually doesn't affect the received routes from eBGP peers. Here is the BGP table of R3:

R3(config-router)#do show ip bgp | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.23.2 0 20 10 i

The AS-PATH is the same as before. This command only affects the routes advertised to eBGP peers. So let's configure this for R4 as well:

R3(config-router)#neighbor 100.0.34.4 local-as 30 no-prepend replace-as

Now external peers (R4 in this example) only see the old ASN (AS 30), R3 doesn't prepend his new ASN (AS 3000):

R4#show bgp ipv4 unicast | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.34.3 0 30 20 10 i

Now R3 only prepends AS 30, he hides AS 3000. Use this with great care, because this could lead to routing loops. So to summarize: the no-prepend only affects routes received from eBGP peers, and the replace-as only affects routes advertised to eBGP peers.

AS-PATH loop prevention, prepending

Now R3 has kind of "two identities", he has two ASNs. Let's take a look how the AS-PATH loop prevention works in this case. Does R3 discard routes if he detects either AS 3000 or AS 30 in the AS-PATH? Let's find out! We'll use AS-PATH prepending on R1, and let's prepend AS 30 first:

R1(config)#ip prefix-list LO0 permit 1.1.1.1/32
R1(config)#route-map AS30_PREPEND permit 10
R1(config-route-map)#match ip address prefix-list LO0
R1(config-route-map)#set as-path prepend 30
R1(config-route-map)#exit
R1(config)#route-map AS30_PREPEND permit 20
R1(config-route-map)#exit
R1(config)#router bgp 10
R1(config-router)#neighbor 100.0.12.2 route-map AS30_PREPEND out
R1(config-router)#do clear ip bgp * out

We're using a route-map applied outbound to the eBGP neighbor R2, now R2 sees the AS-PATH as the following:

R2#show ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.12.1 0 0 10 30 i

R1 sends the prefix as if it was originated in AS 30. Does R3 discard this prefix? Or he only discards the prefixes with AS 3000 in the AS-PATH?

BGP(0): 100.0.23.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS;

R3 in fact drops this prefix, by default he does not accept anything with his old ASN (AS 30) in the AS-PATH.

Now let's send the prefix with AS 3000:

R1(config)#route-map AS30_PREPEND permit 10
R1(config-route-map)#no set as-path prepend 30
R1(config-route-map)#set as-path prepend 3000
R1(config)#do clear ip bgp * out

This is what R2 receives, AS 3000 has been prepended to the AS-PATH:

R2#show ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.12.1 0 0 10 3000 i

R3 doesn't accept this either:

BGP(0): 100.0.23.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS

So the AS-PATH loop prevention works for both the old and the new ASN as well.

Allowas-in

How can we disable this mechanism? Let's say that on R3 we want to accept prefixes with AS-PATH containing our own ASN (either AS 30 or AS 3000). Let's assume that we can be certain that we don't run into routing loops. In this case we can configure allowas-in on the neighbor from which we want to accept the prefixes with the AS-PATH containing our own ASN. In this case this is R2:

R3(config-router)#neighbor 100.0.23.2 allowas-in

And let's advertise the prefix with both AS 30 and AS 3000 prepended on R1:

R1(config)#route-map AS30_PREPEND permit 10
R1(config-route-map)#set as-path prepend 30 3000
R1(config)#do clear ip bgp * out

Without the allowas-in R3 would drop this prefix, now he accepts it, even if the AS-PATH has AS 30 and AS 3000 included:

BGP(0): 100.0.23.2 rcvd UPDATE w/ attr: nexthop 100.0.23.2, origin i, merged path 20 10 30 3000, AS_PATH

R3(config-router)#do show ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.23.2 0 20 10 30 3000 i

Use this feature carefully! It can lead to routing loops. We would usually use this feature in an MPLS L3VPN environment where the customer has the same ASN on both sites, just like I did in this or in this lab. Alternatively in the previous MPLS L3VPN environments the service provider can also use the as-override which has the same purpose.

AS-override

Before examining this feature in detail, let's quickly remove the allowas-in on R3:

R3(config-router)#no neighbor 100.0.23.2 allowas-in

R1 still sends the prefix with AS 30 and AS 3000 prepended, so now on R3 the AS-PATH loop prevention kicks in and it drops the prefix:

BGP(0): 100.0.23.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS

The AS-override serves the same purpose as the allowas-in: it used when we want to accept prefixes with the AS-PATH attribute which might contain our own ASN. But it is configured on the neighbor router from which we receive the prefixes and it works OUTbound, not INbound. So we configure this on R2:

R2(config)#router bgp 20
R2(config-router)#neighbor 100.0.23.3 as-override

What this command does is the following: if R2 sends a prefix to R3 he checks the AS-PATH attribute. If the AS-PATH contains the ASN which has been configured with the remote-as command for R3 (neighbor 100.0.23.3 remote-as 30), so in this case AS 30, R2 would override that with his own ASN (AS 20). Notice that R2 doesn't know anything about AS 3000, so R2 leaves AS 3000 as is in the AS-PATH, R2 only changes AS 30 to AS 20. This is how R2 sends the NLRI to R3:

BGP Update sent by R2 after as-override — BGP Update sent by R2 to R3 after the `as-override` command

Normally without as-override R2 would send the AS-PATH as the following: 20 10 30 3000. With as-override R2 changes R3's ASN (AS 30) to his own ASN (AS 20) and R2 sends 20 10 20 3000. Notice that in this case R3 still drops the prefix, because it contains AS 3000 which is the real AS of R3, and R2 doesn't know that R3 is configured the local-as command:

BGP(0): 100.0.23.2 rcv UPDATE w/ attr: nexthop 100.0.23.2, origin i, originator 0.0.0.0, merged path 20 10 20 3000, AS_PATH , community , extended community , SSA attribute

But if R1 prepends just AS 30 a bunch of times like this:

R1(config)#route-map AS30_PREPEND permit 10
R1(config-route-map)#set as-path prepend 30 30 30 30 30
R1(config)#do clear ip bgp * out

R2 changes every single instance of AS 30 to AS 20

BGP Update sent by R2 after as-override 2 — BGP Update sent by R2 to R3 after the `as-override` command (2)

Without the as-override R2 would send the following: 20 10 30 30 30 30 30. With as-override R2 sends 20 10 20 20 20 20 20. Notice that the number of the AS-hops doesn't change because R2 just replaces the ASNs to his own ASN, it doesn't change the length of the AS-PATH.

And now R3 can accept the prefix:

R3(config-router)#do show ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 100.0.23.2 0 20 10 20 20 20 20 20 i

So the main thing to remember is that both the allowas-in and the as-override used for the same purpose. The as-override is a bit safer to use, with the allowas-in we can easily run into routing loops if we don't use it carefully. The allowas-in is an INbound feature: it simply "turns off" the AS-PATH loop prevention. The as-override works OUTbound, and it is configured on the neighbor router, and this feature changes the ASNs in the AS-PATH attribute, so that we can accept the prefixes which we would drop normally.