BGP local-as, dual-as and replace-as

On Cisco routers running BGP, the command local-as can be used to tweak the AS number announced to BGP peers. This can be handy in some situations to overcome (mostly political) obstacles, but it can be harmful if not thoroughly thought out.

Under normal conditions, a BGP router will advertise routes which originate within its autonomous system (AS) with an AS path length of one, listing only its own AS number specified under BGP process configuration (e.g.router bgp 65001). Contrary to what might be assumed, the local-as command does not replace the AS number advertised to peers. Rather, it prepends it to the actual AS number, resulting in an AS path length of two. Routes advertised to neighbors with a local AS configured will appear to arrive via the specified AS, but will still be known to have originated from the actual AS.

When might this be of concern? Suppose we were to establish BGP adjacencies between three spoke routers and a central hub router, illustrated below. The hub site is AS 65000, and the three spoke sites are to be AS 65001, 65002, and 65003.

Unfortunately, the third spoke router has been misconfigured as AS 65002. The hub router expects to peer with us as AS 65003, and duly complains that something is wrong using a BGP notification. Note that 0xFDEA is the hexadecimal equivalent of the decimal AS number 65002.

%BGP-3-NOTIFICATION: received from neighbor 172.16.0.9 2/2 (peer in wrong AS) 2 bytes FDEA

There are two ways to rectify this error. The preferred way would be to reconfigure the spoke router's BGP process with the correct AS number. Unfortunately, this requires tearing down and restoring the entire BGP configuration. This might not be immediately feasible, particularly if other adjacencies have already been established using the incorrect AS number.

The other, presumably more convenient option, is to associate a local AS with the hub router adjacency using thelocal-as parameter. The relevant configuration would look like this:

router bgp 65002
 neighbor 172.16.0.9 remote-as 65000
 neighbor 172.16.0.9 local-as 65003
 !
 address-family ipv4
  neighbor 172.16.0.9 activate
 exit-address-family

From the hub router, it appears that R3 is advertising the 192.168.3.0/24 network as AS 65003, but the route appears to have originated in AS 65002:

Hub# show ip bgp 192.168.0.0 255.255.0.0 longer-prefixes
BGP table version is 10, local router ID is 172.16.0.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      172.16.0.2               0             0 65001 ?
*> 192.168.2.0      172.16.0.6               0             0 65002 ?
*> 192.168.3.0      172.16.0.10              0             0 65003 65002 ?

While this hack is effective in establishing the BGP adjacency, it prevents the networks behind R2 and R3 from communicating with one another. This is because BGP routers don't install routes advertised with their own AS in the path. In fact, the hub router, knowing this rule, doesn't even propagate the networks advertised by R3 to R2:

R2# show ip bgp neighbors 172.16.0.5 received-routes
BGP table version is 5, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/30    172.16.0.5                             0 65000 65001 ?
*> 192.168.1.0      172.16.0.5                             0 65000 65001 ?

Total number of prefixes 2 

The reverse is also true for routes advertised from R2 toward R3. Thus, the networks behind R2 and R3 can both talk to the networks behind R1, but not to one another. Only when R3 is reconfigured with the proper BGP AS will full communication be established.

router bgp 65003
 neighbor 172.16.0.9 remote-as 65000
 !
 address-family ipv4
  neighbor 172.16.0.9 activate
 exit-address-family

R2# show ip bgp neighbors 172.16.0.5 received-routes
BGP table version is 11, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network          Next Hop            Metric LocPrf Weight Path
*> 172.16.0.0/30    172.16.0.5                             0 65000 65001 ?
*> 172.16.0.8/30    172.16.0.5                             0 65000 65003 ?
*> 192.168.1.0      172.16.0.5                             0 65000 65001 ?
*> 192.168.3.0      172.16.0.5                             0 65000 65003 ?

Total number of prefixes 4 

---------------------------------------------

… making your network appear as a set of nested autonomous systems:There are two reasons for the weird AS path:

R1 inserts local-as into inbound EBGP updates
R2 (configured like R1) inserts local-as as well as its real AS (65001) in outbound EBGRP update

To fix the AS path, you need the BGP Support for Dual AS Configuration introduced in IOS release 12.3T. This feature adds two options to the local-as configuration command:

no-prepend disables local-as prepending on incoming EBGP updates;
replace-as replaces router's own AS with local-as on outgoing EBGP updates.

When the configuration on R1 and R2 includes these two keywords …:
router bgp 65001
 neighbor 10.1.0.2 remote-as 10
 neighbor 10.1.0.2 local-as 20 no-prepend replace-as
 neighbor 10.1.0.2 description EBGP to AS 10
… the path propagated through AS 65001/AS 20 looks as expected:
AS30#show ip bgp | include 20
*> 172.16.0.0     10.1.0.5     0 20 10 i