IE Vol 1: MPLS TE Explicit PE-PE Tunnels Complete

This is the same as the last lab, but instead of dynamic tunnels, explicit tunnels are used.

To do this, an ip explicit path list needs to be created, which lists each ingress interface on each router in the path.

When I set it up, I used one of the wrong IPs. The nice part was the sh mpls tra tun told me which was incorrect:

Last Error: PCALC:: Explicit path has unknown address, 150.1.45.4

MPLS Traffic Engineering: PE to PE Tunnels Complete

I must confess, I made it thorough all the written exams so far without touching Traffic Engineering. I knew a tiny bit of theory, such as it relied on RSVP and inserted yet another label on the stack, but that was about it.

This first TE lab was a pretty good introduction. This link describes the configuration process really well.

In a nutshell, a tunnel interface needs to be created on the two endpoints. The tunnel gets configured as mode mpls traffic-eng, along with a bunch of other options under the tunnel interface.

Then, the mpls network needs to be configured to support this tunnel. This is accomplished through the monotonous configuration, on each router, of:

• enabling mpls traffic engineering globally
• enabling mpls traffic engineering on each interface between the tunnel endpoints
• configuring ip rsvp bandwidth on each interface between the tunnel endpoints
• configuring ospf (or isis) for traffic engineering on each mpls router

It seems if you miss a link in the path, little info is given as to which one you've missed. Instead, all you get is a message saying that the path isn't valid when you do a show mpls tra tun. Once all the links have been completed, the tunnel interface comes up/up.

IE Vol 1 Controlling MPLS label distribution Complete

Nothing fancy here, the lab just has you only send MPLS labels for the BGP endpoints. Those two are the only IPs required for the vpn labels to have igp labels to ride. So getting rid of all the extraneous lables has no effect on the vpn functionality.

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.