BGP local-as
24/12/10 17:05 Filed in: bgp
A quick review of bgp local-as command. This is the topology:
R1 in AS100 expects R2 to be in AS202.
On R1 we get a BGP notification message:
*Mar 1 00:22:30.603: %BGP-3-NOTIFICATION: sent to neighbor 10.0.12.2 2/2 (peer in wrong AS) 2 bytes 00C8
Remember, notification message in BGP alway means something bad is happening. The error message contains the expected AS. hex 00C8 means 200 in decimal.
So how do we fix it?
R2(config-router)#neighbor 10.0.12.1 local-as 202
R1: *Mar 1 00:25:32.743: %BGP-5-ADJCHANGE: neighbor 10.0.12.2 Up
Fine! Let's set next-hop-self on R2 and advertise in BGP the loobpacks of the routers.
R2(config-router)#nei 10.0.23.3 next-hop-self
R2(config-router)#nei 10.0.12.1 next-hop-self
Now we check how locas-as command works on BGP.
****** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 200 i
*> 3.3.3.3/32 10.0.12.2 0 202 200 300 i
On R1 prefixes coming from R2 have AS202 prepended.
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 202 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
On R2 prefixes coming from R1 have AS202 prepended too.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 202 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
On R3 we can see that AS202 is prepended only for prefixes coming from AS100 (1.1.1.1/32), not for prefixes originated by R2 (2.2.2.2/32).
So BGP behaves as if a "ghost" AS 202 is inserted between R1 and R2: AS 100 -- AS 202 -- AS 200 -- AS 300
***** NO-PREPEND *****
Now we insert the "no-prepend" option on R2 to check how the output changes:
R2(config-router)# neighbor 10.0.12.1 local-as 202 no-prepend
***** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 200 i
*> 3.3.3.3/32 10.0.12.2 0 202 200 300 i
Nothing changed on R1
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
On R2 there's no more AS202 on the as-path of prefixes coming from AS 100.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
Neither on R3 we can see AS 202.
Based on the output the "no-prepend" option hides AS 202 for every prefix except for the ones sent to R1. The "ghost as" AS 202 is seen only by R1.
***** REPLACE-AS
We have another option on the command: "replace-as", let's see how it works:
R2(config-router)# neighbor 10.0.12.1 local-as 202 no-prepend replace-as
***** R1
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 10.0.12.2 0 0 202 i
*> 3.3.3.3/32 10.0.12.2 0 202 300 i
On R1 we can see no more AS 200 in prefixes coming from R2, only AS 202 is there.
So the "ghost as" is still there and the real AS is gone. From R1's point of view the logical topology would be: AS 100 -- AS 202 -- AS 300
***** R2
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.12.1 0 0 100 i
*> 2.2.2.2/32 0.0.0.0 0 32768 i
*> 3.3.3.3/32 10.0.23.3 0 0 300 i
Nothing changes on R2.
***** R3
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.0.23.2 0 200 100 i
*> 2.2.2.2/32 10.0.23.2 0 0 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
Nothing changed on R3.
R1 is the only one that knows about the existence of AS 202.
***** DUAL-AS
The last option of the command is "dual-as". This command enables R2 to answer as connections to both AS200 and AS202, it became double-face!
How do we check it? Fire-up OSPF on R1 and R2, on loopbacks too, peer loopbacks on AS 100 and AS 200:
Remember to enable ebgp-multihop, tune ttl-security or disable-connected-check on both R1 and R2 since we're peering eBGP between not-connected interfaces.
***** R1
On R1 we have two peering sessions towards R2, one for AS 200 and one for AS 202:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 200 7 13 30 0 0 00:01:59 2
10.0.12.2 4 202 84 83 30 0 0 00:19:52 2
We can see that R1 can reach prefixes advertised by R2 with two paths:
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
* 2.2.2.2/32 2.2.2.2 0 0 200 i
*> 10.0.12.2 0 0 202 i
* 3.3.3.3/32 2.2.2.2 0 200 300 i
*> 10.0.12.2 0 202 300 i
If you enabled debugs you'll see some messages about routing loops and denied paths:
*Mar 1 01:11:50.747: RT: recursion error routing 2.2.2.2 - probable routing loop
*Mar 1 01:13:18.431: BGP(0): 2.2.2.2 rcv UPDATE about 1.1.1.1/32 -- DENIED due to: AS-PATH contains our own AS;
Just for fun let's fix the routing loop. The easiest way is to set OSPF distance to a value below eBGP, 19 should be good. On both R1 and R2 we set:
R1(config)#router ospf 1
R1(config-router)#distance 19
Done!