The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
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.
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
Posted in Routing
Comments
June 19, 2012 at 3:41 a.m. UTC
Thank You
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)
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.
June 19, 2012 at 4:10 p.m. UTC
Very fun post. Loved it.
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.
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
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.
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.
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
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.
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
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)
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
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
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.
March 27, 2013 at 5:25 p.m. UTC
Nice Discussion Guys :)
January 5, 2014 at 7:30 a.m. UTC
thank you bro, your blogs are worth reading. Keep it up.
May 1, 2015 at 7:04 p.m. UTC
While using the command neighbor 10.0.12.2 local-as 101. neighborship went down. Please suggest in this case . Configurations of both the routers are as follows:-
R1#sh run | sec router bgp router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.0 mask 255.255.255.0 network 10.0.12.0 mask 255.255.255.0 neighbor 10.0.12.2 remote-as 200 neighbor 10.0.12.2 local-as 101 neighbor 10.0.12.2 soft-reconfiguration inbound no auto-summary R2#sh run | sec router bgp router bgp 200 no synchronization bgp log-neighbor-changes network 2.2.2.0 mask 255.255.255.0 network 10.0.12.0 mask 255.255.255.0 neighbor 10.0.12.1 remote-as 100 neighbor 10.0.12.1 next-hop-self no auto-summary
February 5, 2016 at 11:05 a.m. UTC
@Raj
It's probably because on R2 you have:
neighbor 10.0.12.1 remote-as 100
instead of
neighbor 10.0.12.1 remote-as 101
:)