Getting to know MPLS
By stretch | Wednesday, July 16, 2008 at 1:02 a.m. UTC
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in MPLS
July 16, 2008 at 2:55 p.m. UTC
Very nice writeup!
July 17, 2008 at 5:15 p.m. UTC
As always, great information. Much obliged.
November 29, 2008 at 1:48 p.m. UTC
October 27, 2009 at 2:58 p.m. UTC
Looks like you've got a spelling mistake in your diagram, IGBP and EGBP when I think you mean IBGP and EBGP. Not a huge deal but given the quality of your material (exceptional) I figure you'd want to correct this.
June 18, 2011 at 3:42 a.m. UTC
June 30, 2011 at 3:47 a.m. UTC
Really nice and very helpful to understand how the MPLS work for a beginner.Thanks
October 11, 2011 at 5:57 a.m. UTC
I am a newbie in MPLS and have question to ask you why IS-IS is running on all P and PE routers, and IBGP is only running between the two PE routers. Is it any advantage for this practice, can we run IBGP for all P and PE routers or using OSPF running on all P and PE routers. I would like to know the purpose of the setting.
Many Thanks !!!!!
November 17, 2011 at 2:58 p.m. UTC
thanks brother !!
March 20, 2012 at 2:20 p.m. UTC
Serch ends HERE!!!!!!!!!!
February 26, 2013 at 4:16 a.m. UTC
You are an excellent writer and I am a great fan of this site.You are doing a good work by helping people out with your cheat sheet.May the Almighty shower his blessing and prosperity on you.Please keep continuing with this great work.
August 5, 2013 at 6:03 p.m. UTC
Hi Jeremy, Awesome job dude. You are the Rockstar of packets. keep it up. When I read any stuff from the owners of this devices, I always visit here to get it broken down so much so that a smart kindergaten kid can easily comprehend it. Good Job!
August 6, 2013 at 8:05 a.m. UTC
My understanding of MPLS is becoming easier
December 27, 2013 at 3:50 p.m. UTC
Excellent blog...Crystal Clear
December 29, 2013 at 12:32 a.m. UTC
Thank you for this. I keep coming back to ground myself on the MPLS principle's, and happy when I can re-read your study guides.
It has been a great help for me.
April 28, 2014 at 5:05 p.m. UTC
Awesome explanation as usual Mr. Stretch
April 29, 2014 at 12:11 p.m. UTC
am planning to stimulate one lab, Here I couldn't able to enable IPV6 MPLS L3 Vpn. Request you to help me to get the proper IOS which support IPV6 MPLS L3 in GNS3.
I have tested 3725 and 7200 series router.
Looking forward to hear from you!
August 28, 2014 at 8:35 a.m. UTC
I am not sure if i am correct but isn't it true that ldp only generates labels for igp learned prefixes since customer routes are bgp prefixes, will it generate a label for that ??
October 13, 2014 at 9:32 p.m. UTC
I have a LAB that I'm working on very similar to this LAB I'm running MPLS on all provide router (P, and PE) and running eBGP between PE and CE. I can see the routes coming from each CE on the PEs bu those routes are not being sent to CE. I'm not doing redistribution because it is supposed to happen automatically between BGP. I'm running MBGP between the PE with VPNV4 and each PE has a VRF to CEs. Can you help find the problem?
May 25, 2015 at 12:46 a.m. UTC
Your blog is very informative, thank you.
I have the same question as Kapil, I think MPLS needs valid IGP routes, No?
May 25, 2015 at 1:07 a.m. UTC
And also based on the basic routing rules the destination address never changes along path to the destination, only the the layer-2 address is swapped in every hop (switching) and P1 doesn't know the CE's prefixes. Could you please help me to clarify this.