MPLS VPNs with BGP Site-Of-Origin Complete

This was an interesting lab that took a bit of research for me to understand what was happening.

When we use as-override, the intention is to work around the loop prevention mechanism of eBGP so that a CE router will accept a route from another CE router with the same AS.

But sometimes that loop prevention mechanism is still needed. This typically occurs when two CE routers have a backdoor (i.e. non-PE) connection to each other, in addition to the PE connection.

Such a connection can create a routing loop when used in conjunction with as-override. This is because the PE router strips the originating AS and then advertises the route back out to the other CE. This CE router has no idea that this is the same route it is learning from its backdoor neighbor, so a routing loop can be created.

To prevent this, the site-of-origin (soo) extended community can be set via a route-map. No filtering is required, everything happens automatically once it is set. When a PE router learns a route with an SOO set, it will not advertise another route with the same SOO set to its CE neighbor.

The catch to this is that the backdoor route cannot be used as a redundant connetion to the other CE router. If the MPLS connection drops, traffic cannot be rerouted dynamically through the other CE router.

To check if SOO is set on the PE router, use sh ip bgp vpnv4 all X.X.X.X

MPLS VPNs and VRF Export Map Complete

The Export Map allows much more granular control over which networks get advertised to which vpnv4 prefixes. There's a great example at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_e1.html#wp1012602

I learned a bit more about the order of operations of MPLS during this exercise. I mistakenly forgot to import the route-targets on R3. During troubleshooting, I noticed that the routes that were supposed to be imported were not present in sh ip bgp vpnv4 all. Apparently this table does not get populated until the specific route-targets are imported by a vrf.

MPLS VPNs with Extranets Complete

I was pretty surprised I got this one right the first time. It's simply a matter of getting the route target imports and exports correct.

I think I'm still a little fuzzy on the transition from an IP address to a route descriptor to a route-target, and how they all interoperate with routing protocols and redistribution.

This lab did help to tie it together somewhat. I suppose my understanding is that it goes something like this:

When an interface is setup for vrf forwarding, it is no longer part of the global routing table. Instead, the router performs a lookup to get more details about the vrf that the interface is an instance of. It goes to the vrf configuration and finds the route descriptor, which is uses to relate this interface to IGPs and ipv4 BGP. Then, it sends out a BGP vpnv4 route for each export target. These export targets get flooded throughout the BGP vpnv4 peers, which should encompass all PE routers. Finally, with these vpnv4 routes flooded, the import route-target is used to load the remote vpnv4 routes into the particular vrf routing table.

Central Service MPLS VPNs Complete

I found this lab really neat. They had me go back to RIP as the PE-CE routing protocol, which was nice to help me commit the syntax to memory. The trick this time was I had to create 4 different vrf's and allow the R5 vrf to act as a central services VPN. This acts kind of like a promiscuous port in switching terminology: all the other vrfs can access it, but individual vrfs are isolated from each other.

The interesting part here is I finally got to play around with import/export route targets. It actually worked pretty intuitively. Under the R5 vrf, I configured it to import and export all of the other route-targets. Once RIP propagated about 30 seconds later, everything magically worked. That was all there was to it. Way too easy.

The solutions guide specified to import R5 into the other 3 vrfs, instead of exporting to the other vrfs from R5. It appears to be 6 one way and a half dozen the other, but I do wonder if there is a standard to try to import when possible. Sort of like in an access-list it's a good idea to set it up inbound. This makes sense on an access-list because filtering it ingress saves processor time and bandwidth utilization.

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 150.1.3.3
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 150.1.4.4 0 100 0 100 i
*> 10.1.7.0/24 10.1.37.7 0 0 100 i
*> 10.1.37.0/24 0.0.0.0 0 32768 ?
*>i10.1.45.0/24 150.1.4.4 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 150.1.4.4 0 100 0 200 i
*> 10.1.8.0/24 10.1.38.8 0 0 200 i
*>i10.1.46.0/24 150.1.4.4 0 100 0 ?

Note there is not a route to 10.1.38.0/24 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 150.1.3.3 0 100 0 i
*> 10.1.46.0/24 0.0.0.0 0 32768 ?

MPLS VPNs with EIGRP Complete

Nothing too challenging with this lab. EIGRP is configured similarly to RIP where address families are named under the EIGRP process. What is interesting is that different autonomous system numbers are used for each EIGRP vrf.

MPLS VPNs with OSPF Complete

I'm getting faster and faster at these. OSPF was pretty straightforward, there was probably just one oddity I found.

When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.

However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.