IE Vol 1: VRF-lite Complete

One would think with a name like VRF-lite, things wouldn't be too bad. That really wasn't the case. I'd hate to see what VRF-heavy looks like.

In actuality, VRF-lite refers to having VRFs without running MPLS. We're keeping separate routing tables, but are separating the traffic on the link using dot1q tags or DLCIs instead of labels.

There really weren't any tricks here, just a lot of stuff going on at the same time.

The setup starts with a basic iBGP vpnv4 session between two routers. But this time, the two BGP routers have separate subinterfaces for each vrf.

Next, the next downstream router has two subinterfaces mapped to vrf's as well. That router is running the customer IGP, but keeping them separate via subinterfaces, rather than running bgp vpnv4 to the upstream router to learn labels and sending traffic via MPLS.

So in effect, this is brining the MPLS domain one more router upstream from the edge.

IE Vol 1: Carrier Supporting Carrier - Hierarchical MPLS VPNs Complete

Nothing fancy going on in this lab. The configuration ends up with two separate vpnv4 sessions, I'm just a little unsure of how to refer to the two. Perhaps by going with the old Access/Distribution/Core model we could say the Core P (CP) network, Distribution P (DP) network, and consider the C network to be access? It's not a perfect analogy but good enough...

So that gives us a vpnv4 session on the Core P network to carry the Distribution P routes. Then there's a Distribution vpnv4 network to carry the C routes.

Like anything else, the key is just to build from the ground up and verify each step along the way.

IE Vol 1: Carrier Supporting Carrier - MPLS Enabled Complete

Nothing too fancy about this lab. About the only note worth mentioning is next-hop-self is required on the PE routers iBGP session. This is because the CE link is not advertised in OSPF, therefore the P routers don't have reachability to them. But, since we have the loopback interfaces in OSPF, the P routers have those links in their routing tables and build MPLS labels for them.

IE Vol 1: Inter-AS MPLS VPNs with Multihop MP-eBGP Complete

This was very similar to the last lab, with one fundamental difference. This time, the BGP AS border routers no longer participate in vpnv4. Instead, the MPLS PE routers peer directly via ipv4 and vpnv4.

A very interesting problem occurs because we're using MPLS VPNs. Remember that a MPLS VPN packet contains an IGP label and a VPN label. The situation encountered is as follows:

................AS1. AS2 ..............
C---PE----P-----P-----P-----P----PE---C
.................^... ^..................
..............BGP-ASBRs.............

The 2 BGP-ASBR P routers do not run MPLS on their neighboring interfaces. If we were not running VPN, the BGP-ABR router could simply pop the label, do an IP lookup, and then forward the packet to the next router.

But since we use VPN, when the BGP-ABR router pops the label, it now has a VPN label which it does not understand. Therefore, it must drop the packet.

To alleviate this, we need to ensure a single label switched path exists across both AS's.

This is accomplished with the neighbor send-label command.

IE Vol 1: Inter-AS MPLS VPNs with MP-eBGP for VPNv4 Exchange Complete

Wow, that title sure is a mouthful. This lab seriously threw me for a loop. No matter what I did, my provider PE routers would not load the vpnv4 routes advertised by the customer PE routers.

After playing with enough debug commands, I finally came across the following:

R2#debug ip bgp vpnv4 uni upd
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd UPDATE w/ attr: nexthop 150.1.3.3, origin ?, localpref 100, metric 0, extended community RT:1:100
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd 1:100:10.1.37.0/24 -- DENIED due to: extended community not supported;

Huh? What does it mean extended community not supported?

As it turns out, extended communities, by default, are not accepted from eBGP peers. This is the first lab that I've tried to exchange vpnv4 routes across eBGP, so it's the first time I've run into this.

The command to enable extended communities across eBGP peers is no bgp default route-target filter. The details can be found here.

IE Vol 1: Inter-AS MPLS VPNs with Back-to-Back VRF Complete

Things are starting to get really complex. I was stumped a few times on this one and had to look at the answers. Most of my problem involved incorrect assumptions about bgp vpnv4.

Prior to this lab, the general rule has been to only peer bgp vpnv4 with PE routers. But in this lab, two separate bgp ASs are peering separate vrf's over separate interfaces. Rather than two providers sharing routes over vpnv4, they split them over the interfaces as ipv4 neighbors.

So it actually ends up with each provider's edge router actually acting like a CE router and a PE router at the same time. Each provider is each other's customer.

I guess this is what back-to-back VRF means. Rather than sharing the vpnv4 information across bgp, we strip the rd information out, but dedicate a subinterface for each vrf. Then on the other side of the link, the router loads the routes back into bgp and reconstructs the vpnv4 routes.

Why do it this way? One reason seems to make sense--what if you need to carry MPLS VPNs across separate providers but each provider is using different route descriptors? This would allow each provider to load their own rd when the routes are imported. If vpnv4 routes were shared, rd's would need to be consistent across the entire path.

IE Vol 1: Carrier Supporting Carrier - IP Only

In this lab, the goal is to segment one AS (something like a tier-2 carrier) with another AS (a tier-1 carrier). It's quite interesting how this ends up working out. The Tier-1 carrier becomes the P network, and the tier-2 carrier becomes the C network. iBGP relationships can still be formed by CE routers across the P network, since as far as the CE routers are concerned, the routes are all being learned via OSPF. The entire separate AS is completely transparent to the C network.

There really wasn't anything particularly challenging about this lab, there was just a lot going on. It's definitely required to build each piece step by step and verify along the way. A simple missing mpls adjacency, ospf neighbor, or bgp next-hop-self missing could make troubleshooting really difficult.

The mpls verification was quite interesting. On the PE routers, a separate MPLS adjancency is actually formed inside of the vrf. To check this, the commands sh mpls ldp neigh vrf VPN_A and sh mpls for vrf VPN_A are required.

Aside from that, I had to go back and do a couple of redistribute connected's into bgp. This was required so that I could ping from the outgoing interface rather than the loopback of the true customer routers.