Saturday, November 15, 2008

MPLS VPNs with eBGP Complete

Two interesting pieces to this lab.

First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.

To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.

The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.

Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is
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
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 0 100 0 100 i
*> 0 0 100 i
*> 0 32768 ?
*>i10.1.45.0/24 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 0 100 0 200 i
*> 0 0 200 i
*>i10.1.46.0/24 0 100 0 ?

Note there is not a route to in BGP. But who cares? And then it dawned on me.

When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.

This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.

To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.

Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.

*>i10.1.38.0/24 0 100 0 i
*> 0 32768 ?

No comments: