IE Vol 2 Lab 1

7:00am Lab Started
7:30am Diagrams and read-through complete
7:55am 1.1 complete, 3 points
8:01am 1.2 compete, 3 points (switchport protected)
8:08am 1.3 complete, 2 points
8:13am 1.4 complete, 2 points
8:17am 1.5 complete, 2 points
9:10am 1.6 complete, 0 points (cell mode mpls, had to cheat)

9:27am 2.1 complete, 3 points
9:34am 2.2 complete, 2 points
9:46am 2.3 complete, 3 points (assuming non-broadcast)

10:02 am 3.1 complete, 3 points
10:11am 3.2 complete, 3 points
10:26am 3.3 complete, 3 points
10:47am skipping 3.4 until mpls is complete, 0 points

11:02am 4.1 complete, 3 points
11:03am 4.2 complete, 3 points
11:05am 4.3 complete, 3 points

**BREAK***

1:49pm back from break

skipping 4.4 MPLS TE

1:57 5.1 complete, 3 points
2:06 5.2 complete, 3 points
2:14 5.3 complete, 3 points
2:39 5.4 complete, 3 points
3:23 5.5 complete, 0 points (cheated)
3:32 5.6 complete, 3 points
3:42 5.7 complete, 2 points

That's it. My energy is gone so I'm calling it a day.

IE Vol 1: MPLS TE Unequal Cost Load Balancing Complete

This time, we create two tunnels. One uses explicit paths, the other uses dynamic paths. Setting the traffic-eng bandwidth different on each tunnel causes unequal-cost load-balancing to occur.

One troubleshooting note, there are three requirements to have the TE tunnels show in the routing table:

• tunnel mpls traffic-eng autoroute announce must be configured on each tunnel
• the TE tunnels must show up/up in sh mpls traf tun brie
  
• the TE tunnels must have ip unnumbered or an IP address assigned

Not having an IP unnumbered assigned to the tunnel interfaces caused me a lot of grief. Everything showed up and functioning, but I didn't see the tunnels in the routing table. Once I added ip unnumbered loo0, everything looked great. Note the traffic share counts that are different between the two paths. Try doing that in OSPF without MPLS-TE!

R4#sh ip route 150.1.3.3
Routing entry for 150.1.3.3/32
Known via "ospf 1", distance 110, metric 5, type intra area
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 5, traffic share count is 2
directly connected, via Tunnel1
Route metric is 5, traffic share count is 1

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.