Implications of BGP local-as on IOS

By stretch | Tuesday, June 19, 2012 at 2:22 a.m. UTC

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.

topology.png

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 the local-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 

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


rao (guest)
June 19, 2012 at 3:41 a.m. UTC

Thank You


danrog
June 19, 2012 at 4:00 a.m. UTC

Hi Jeremy. In my experience you don't see this behavior with VRF's (as long as those are setup correctly as well). Have you seen situations where this is an issue when using VRF's? We use 'local-as' today with VRF's (I wouldn't even think about using 'local-as' without VRF's for the very reason you mentioned)


morpheus282
June 19, 2012 at 4:53 a.m. UTC

I'm actually in the middle of a project where we're using the local AS command to change ASNs with minimal downtime. We're using the "no-prepend replace-as dual-as" arguments to the command to mitigate the problem you describe above and ensure the peer relationship comes back online while we're waiting for the SP to complete their changes.


Will (guest)
June 19, 2012 at 4:10 p.m. UTC

Very fun post. Loved it.


Scott (guest)
June 20, 2012 at 3:03 a.m. UTC

All you need to do is add the "no-prepend" and "replace-as" options to the "local-as" command. Only a single AS is now advertised.


Spencer (guest)
June 20, 2012 at 3:18 p.m. UTC

Excellent post. I was not aware of this behavior when using the local-as command, nor was I of the no-prepend and replace-as options that can go along with it. Good stuff guys


vsaltao
June 27, 2012 at 10:47 a.m. UTC

As others already said, if we use "no-prepend" and "replace-as" only a single AS will be advertised, it works pretty good with vrf´s.


Duro (guest)
June 30, 2012 at 6:53 p.m. UTC

there is another way how to force spokes communicate to each other without correcting ASN feature allowas-in

http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a0080b59d08.shtml

These two features could completely ruin bgp loop prevention and crate nice mess. Only brave admin, who don't want sleep wll and hate weekends should use these feature often.


Elvin Arias (guest)
July 1, 2012 at 11:37 p.m. UTC

@ Stretch

Stretch wrote:

"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"

This is false. The router called "Hub" efectively sends the update recived from "R3" to other eBGP peers (including "R1" and "R2" respectively), but when "R2" receives the update from the "Hub" router it rejects the update, since he sees itself listed in the AS_Path.

When the eBGP update is received by R2 (the original router with the REAL 65002 AS) it generate this message "BGP(0): rcv UPDATE about 192.168.3.0/24 -- DENIED due to: AS-PATH contains our own AS;". You will need to enable the "debug ip bgp update" command. This message proves that the "Hub" router sends the update to it's eBGP peers.

eBGP must send the updates to it's eBGP peerings, that's the default rule for eBGP.

Keep the REALLY good work. :)

Elvin


stretch
July 1, 2012 at 11:41 p.m. UTC

@Elvin: In my lab, the route was not listed on the hub router as an advertised route to that peer.


Elvin Arias (guest)
July 2, 2012 at 4:25 p.m. UTC

@ Stretch

On "R2" execute the "debug ip bgp updates" command when the route from "R3" is initially advertised and you will see when "R2" receives the route from the "Hub" router, but as already mentioned the route will be rejected/withdrawn, since "R2" will see it's own AS listed in the update to reach the 192.168.3.0/24 network. In this case the AS_Path loop prevention mechanism is rightfully used as already mentioned.

The point i want to clarify is when you said: "...In fact, the hub router, knowing this rule, doesn't even propagate the networks advertised by R3 to R2". This is false. The "Hub" router do advertise the (192.168.3.0/24 - R3) route to "R2", but "R2" doesn't accept it because of the AS_Path loop prevention.

Elvin


Mat (guest)
July 16, 2012 at 2:25 p.m. UTC

@ Stretch @ Elvin

The behaviour you describe actually depends on the software version you use.
From my experience, older IOS release behave like Stretch describes (e.g. BGP router does not send path to peer A if peer A's AS is in the AS path), while newer behave as described by Elvin.
Strangely enough, IOS-XR behaves like the older IOS releases... though this may change ! (it renders the allowas-in feature useless)


Elvin Arias (guest)
July 21, 2012 at 1:10 p.m. UTC

@ Mat

That could be the reason why I was not accepting the process Stretch described on the earlier post, good to know that this specific process changes from IOS-to-IOS. Thanks for the clarification, Mat.

Elvin


Khaled (guest)
September 10, 2012 at 1:04 a.m. UTC

Jeremy,

Just a side note.

You don't have to tear down the entire BGP for you to apply the correct ASN.

There is a set of command where you can clear BGP per neighbour rather than the entire BGP session with all the neighbours.

i.e. clear ip bgp neighbor ... soft (not sitting in front a router but the command is close enough)

The above command softly-reset the BGP session.

Regards,
Khaled


Cichas (guest)
November 27, 2012 at 7:18 a.m. UTC

"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"

This also depends on configuration style. If you will use peer-group (even with one member) – only one BGP update is send to all neighbors – no way to filter per-neighbor outgoing updates. So if you will configure R2 as peer-group member – all networks from R3 will be propagated to R2 even if it have its own AS number in path.


zerocode85
March 27, 2013 at 5:25 p.m. UTC

Nice Discussion Guys :)


emad (guest)
January 5, 2014 at 7:30 a.m. UTC

thank you bro, your blogs are worth reading. Keep it up.

Leave a Comment


Optional; will not be displayed publicly or given out.
No commercial links. Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.
Layer five of the OSI model is the _____ layer.