MPLS Intro Series – Understanding a Simple LSP

In the previous article, we created an interesting situation with an iBGP configuration.  In that example, we made Edge2 aware of a route via BGP that the intermediary hops would not see. In this article, we will fix this problem using MPLS and label switching. Before getting started, I feel compelled to rename these routers based on their target role in an MPLS our network.


  • MPLS – multiprotocol label switching – using labels or tags to forward packets over a network (as opposed to traditional destination based routing)
  • LSR – Label switch router (transit router), aka P router, switches labels
  • LER – Label edge router or Edge LSR, often called a PE router, may push (impose) labels
  • LSP – Label Switched Path
  • Push – insert/impose a lable
  • Swap – change a label
  • Pop – remove a label

As we left it in our previous configuration, the router on the right sees a route to via BGP but it cannot reach that destination. It is worth mentioning that I disabled BGP sync (following the last example I shared in the previous article).

LER2#show ip route | inc
B [200/0] via, 00:10:57

LER2#ping source loop0
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)

I am going to enable MPLS on all of the physical connections in this topology.

interface GigabitEthernet 2
 description to LSR
 mpls ip
interface GigabitEthernet 3
 description to LSR 
 mpls ip

interface GigabitEthernet 2
 mpls ip
interface GigabitEthernet 3
 mpls ip
interface GigabitEthernet 4
 mpls ip

Now I want to ask a new series of questions regarding this topology. Since this builds on the previous example, I will summarize that there is an iBGP session between LER1 and LER2. OSPF is configured for all of the shown physical interfaces and Loopback0 for each router. Loopback1 on LER1 has an address of and is advertised only in BGP (as configured in MPLS Intro Series – Destination Routing.

  1. Is reachable from LER2?
  2. Is in the RIB (route table of LSR2 and LSR4)?
  3. How could these results be possible?
LER2#ping source loop0
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 100 percent (5/5), round-trip min/avg/max = 25/32/42 ms
//The answer to question one is a definitive YES

LSR2#show ip route
% Network not in table
LSR4#show ip route
% Network not in table
//The answer to question two is NO

At an initial glance it seems impossible that LER2 could deliver a packet to a destination on LER1 that is unknown to the intermediary routers. The reason this is possible is because the LSRx routers do not care about the destination IP address in this case. This is true because there is a label switched path (LSP) across these routes.

We can examine the CEF table on LER2 and see what a packet would look like for this destination.

LER2 (push operation)

LER2#show ip cef
  nexthop GigabitEthernet2 label 20009-(local:2010)
  nexthop GigabitEthernet3 label 40009-(local:2010)
LER2#show int desc | inc Gi2|Gi3
Gi2                            up             up       to LSR2
Gi3                            up             up       to LSR4

Notice that packets to toward LSR2 will receive a label of 20009. Likewise, packets to LSR4 will receive a label of 40009. For the sake of brevity, we will examine the path through LSR2 and determine what it would do with packets with an MPLS label of 20009.

LSP through LSR2 (swap operation)

LSR2#show mpls forwarding-table labels 20009
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
20009      10009   2102          Gi2
LSR2#show interface description | inc Gi2
Gi2                            up             up       to LSR1

We can see in this example that packets arriving tagged with the label 20009, will be sent out Gi2 with label 10009. Gi2 happens to connect to LSR1. Notice that a route table was lookup was performed.

The next step is to see what LSR1 will do with packets arriving with the MPLS label 10009.

LSP through LSR1 (pop operation)

LSR1#show mpls forwarding-table labels 10009
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
10009      Pop Label   2613          Gi4
LSR1#show int description | inc Gi4
Gi4                            up             up       to LER1

In this case, we can see that the packets would be label switched to Gi4 after Popping the Label. This removal of the label at next to the last MPLS hop is know as penultimate hop popping. This packet will be presented as untagged IP as it is received by LER1. LER1 does the first IP address lookup that we’ve seen since the original lookup was performed at LER2. This is “directly connected” on Loopback1 of LER1.

LER1 (RIB lookup)

PE1#show ip route
Routing entry for
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Advertised by bgp 1
  Routing Descriptor Blocks:
  * directly connected, via Loopback1
      Route metric is 0, traffic share count is 1

We could trace the reverse flow (LER1 to LER2) and find that the process would be very similar.

Earlier we saw that LER1 can reach on LER2. We also confirmed this true without a valid route existing in LSR1-LSR4. We now see that this works because there is a label switched path (LSP) that is utilized through that part of the network. In this case, LER2 imposes (pushes) a label that is utilized by the next hop instead of the destination IP. Each hop through the MPLS portion of the network will change (swap) the label as necessary and remove (pop) it at the hop before the final IP lookup has to occur.

This has been a very simple example of how MPLS functions to create an LSP. The next article will demonstrate how we leverage stacked labels to network VRFs. This configuration is known as VPNv4 and is quite useful for macro segmentation across a shared physical network.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design and tagged . Bookmark the permalink.