First off, I know it's been a while since I've posted anything. Between failing the CCIE (again), moving and changing jobs... I've been busy. Back off. That being said, I'm getting the itch again, and it's time to start studying, I don't care if it takes 20 tries over 3 different blueprints I'm going to get my number in R&S. So to get things rolling, I thought I'd start with my favorite topic - MPLS.
Let's get some lingo straight first, that way you impress all your friends with new acronyms.
LSR - Label Switch Router. This guy's life is label switching, LSRs make up your MPLS backbone.
LER - Label Edge Router. Your provider edge (PE), and as the name implies the edge of your MPLS network.
LSP - Label Switch Path. The MPLS path for a particular source and destination.
You'll notice we're dealing with more "P" routers than usual, but having a few extra LSRs should help visual the MPLS process. First off, before setting up any VRFs, or doing any l2 vpns let's take a look at probably the single most important command for troubleshooting MPLS. That's right kids, I'm talking about show mpls forwarding-table. As a sample we'll look at the LFIB (Label Forwarding Information Base) on P1.
Alright... what are looking at right?? I'll get to that, first let's examine why this command is so darn important, simple. By issuing it on our MPLS enabled routers, we can establish our LSP between two given endpoints. After all, MPLS is multiprotocol label switching, so when we're troubleshooting it we should always give the labels the majority of our attention. Now, what are we looking at? The first column is our local labels, generated by the router we're on. The second column, when all is working well, will have either an out going label received (in this case) via LDP or it will show "Pop Label". Without digging too deep, Pop Label comes from penultimate hop popping, really fun to say by the way. This is the process whereby the second to the LSR in an LSP will pop the label off an mpls packet, this is an efficiency mechanism.
Now back to show mpls forwarding-table. Let's say there is a VPN built between PE1 and PE2, routing tables on the CEs look correct, import export statements look good while you're troubleshooting. However, CE1 and not ping CE2. So spoiler alert, I played proctor and jacked up P3 with some control plane policing, more on that later. Further more, since the LFIB is built off the FIB I adjusted the ospf cost on P4's link to PE2 so that P3 was the preferred path. VPNs are built between the PEs, and for a VPN to work there has to be a fully functional LSP between their peering address (loopbacks in our example). So starting on PE1, we'll verify we have labels to get to 22.22.22.22 (PE2's loopback).
So far so good. We have egress labels of 24 and 26 going to P1 and P2 respectfully. Next hop, I'm going to look at P1, but you could go to either.
Trouble in paradise, P1 shows that it's forwarding the packet out with no label towards P3, and has no other path. Let's see what P2 shows.
Same thing, at this point we can jump onto P3 and start diagnosing. First up, look at the labels.
Well that's not good! Why doesn't P3 have any labels?? I know I've told you the problem already, but humor me. So what next? We verify the router has any mpls enabled interfaces, then if we have any neighbors.
Alright that looks good, so now back our TCP and UDP ports... do we have any access-lists configured?
We do! Great... now where are they applied??
"match access-group" sounds like a class-map, let's take a look.
And finally, where is it applied?
P3#show policy-map control-plane <-- Nailed it!
So now we can modify CoPP to allow for tcp communication on 646. After doing that LDP will come back up, and CE1 will be able to ping CE2. Mystery solved.