The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

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
... is subnetted, 6 subnets
i L2 [115/20] via, FastEthernet0/0
i L2 [115/20] via, FastEthernet0/1
i L2 [115/20] via, FastEthernet0/1
C is directly connected, FastEthernet0/0
i L2 [115/20] via, FastEthernet0/0
C 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 on CE1 to on CE2 fails.

CE1# ping source

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with a source address of 
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       0          Fa0/0     
17     Pop tag      0          Fa0/1     
18     Pop tag       9452       Fa0/1     
19     Pop tag       0          Fa0/0     

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 The route (learned via IBGP) indicates 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.

Posted in MPLS


July 16, 2008 at 2:55 p.m. UTC

Very nice writeup!

Joey Boyer
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

very nice


June 30, 2011 at 3:47 a.m. UTC

Really nice and very helpful to understand how the MPLS work for a beginner.Thanks

A guest
October 11, 2011 at 5:57 a.m. UTC

Hi Stretch,

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.

Thaddy Hayes
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

Hi Jeremy,

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

Hi Jeremy,

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.


Comments have closed for this article due to its age.