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.

MPLS VPNs with RIPv2 Complete

Wow, I actually am getting better at this MPLS stuff. When moving from static routes to RIP, the complexity increases greatly. It's a good thing RIP itself is such a simple protocol.

So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.

For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under 10.0.0.0, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.

I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.

I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.