Getting to know MPLS

By Jeremy Stretch

I've been reasonably familiar with MPLS ever since studying for the CCNP ISCW exam, but haven't bothered to lab it out until today. I set up a modest lab containing two each of CE, PE, and P routers, with an IS-IS core, IBGP between the PEs and EBGP to the CEs.

My goal wasn't to become more familiar with MPLS itself, but rather to examine what benefits (if any) it provides to vanilla routing. Obviously MPLS is popular for its ability to implement VPNs and for traffic engineering, but implementing MPLS for plain IP routing alone seemed unnecessary. Why add labels when prefix-based packet switching works just fine?

Take another look at the lab topology. Notice that although IS-IS is running on all P and PE routers, IBGP is only running between the two PE routers. Traffic between the BGP routers must traverse a non-BGP router. This presents a problem: the P routers (which ultimately provide transit between the CE routers) have no knowledge of the customer routes (192.168.*.0/24).

P1# show ip route
...
 10.0.0.0/30 is subnetted, 6 subnets
i L2    10.0.0.8 [115/20] via 10.0.0.1, FastEthernet0/0
i L2    10.0.0.12 [115/20] via 10.0.0.5, FastEthernet0/1
i L2    10.0.2.0 [115/20] via 10.0.0.5, FastEthernet0/1
C       10.0.0.0 is directly connected, FastEthernet0/0
i L2    10.0.1.0 [115/20] via 10.0.0.1, FastEthernet0/0
C       10.0.0.4 is directly connected, FastEthernet0/1

Although disabling synchronization and using next-hop-self allows the IBGP routers to successfully peer and exchange customer routes, the P routers will not know how to forward packets destined for a customer network. Even after verifying full route convergence, a ping from 192.168.10.1 on CE1 to 192.168.40.1 on CE2 fails.

CE1# ping 192.168.40.1 source 192.168.10.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.40.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1 
.....
Success rate is 0 percent (0/5)

To remedy this situation, we could redistribute customer routes into our IGP, but that's messy. Another option is to include the P routers in BGP, but that might not be workable. Alternatively, we can implement MPLS to provide a wrapper for the IP traffic.

MPLS assigns labels to forwarding equivalence classes (FECs) based on IP prefixes, and attaches one or more tangible labels to each packet. This gives the P routers an alternate destination address to work with, eliminating the need to maintain IP routes for destinations outside the MPLS domain. This point should become clearer after an example.

Configuring MPLS is simply a matter of choosing a distribution protocol (Label Distribution Protocol (LDP) in modern configurations) and designating MPLS interfaces:

PE1(config)# mpls label protocol ldp
PE1(config)# int <interface>
PE1(config-if)# mpls ip

After MPLS has been enabled on all P and PE routers, labels will be dynamically assigned for all internal (10...*) prefixes. The LFIB entries can be examined on MPLS routers with show mpls forwarding-table:

P1# show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
tag    tag or VC   or Tunnel Id      switched   interface              
16     Pop tag     10.0.0.8/30       0          Fa0/0      10.0.0.1     
17     Pop tag     10.0.0.12/30      0          Fa0/1      10.0.0.5     
18     Pop tag     10.0.2.0/30       9452       Fa0/1      10.0.0.5     
19     Pop tag     10.0.1.0/30       0          Fa0/0      10.0.0.1     

After deploying MPLS, we can try the ping from CE1 to CE2 again. Here's a rundown of the process from end to end:

1. PE1 receives the packet and performs a CEF lookup for 192.168.40.1. The route (learned via IBGP) indicates 10.0.2.1 as the next hop. CEF also indicates an MPLS label should be added, since the outbound interface is MPLS enabled.
2. PE1 inserts an MPLS header with the appropriate label between the layer 2 and layer 3 headers of the packet and sends it toward the next hop.
3. Depending on the load balancing in use, the next hop will be either P1 or P2; for demonstration purposes we'll assume P1 is chosen.
4. P1 receives the packet and performs a lookup on the label instead of the destination IP address. As the P routers have labels for all IGP-learned routes, P1 is able to make an intelligent decision on how to forward the packet.
5. P1 consults its LFIB and determines that the label should be popped because the next hop is the end of the label-switched path (LSP); this is known as penultimate hop popping (PHP). If there were additional hops in the LSP, the label would instead be swapped for another.
6. PE2 receives the unlabeled packet and normal IP routing occurs to route the packet to CE2.

To recap, MPLS enables P routers to bear transit traffic between IBGP peers not directly connected. Instead of relying on the destination IP address to determine a next hop, an intermediate label is used within the MPLS domain to designate a label-switched path (LSP) between the IBGP peers.