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 220.127.116.11 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 18.104.22.168 B 22.214.171.124 [200/0] via 10.10.10.10, 00:10:57 LER2#ping 126.96.36.199 source loop0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 U.U.U Success rate is 0 percent (0/5)
I am going to enable MPLS on all of the physical connections in this topology.
//LER1-LER2 interface GigabitEthernet 2 description to LSR mpls ip interface GigabitEthernet 3 description to LSR mpls ip //LSR1-LSR4 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 220.127.116.11/32 and is advertised only in BGP (as configured in MPLS Intro Series – Destination Routing.
- Is 18.104.22.168/32 reachable from LER2?
- Is 22.214.171.124/32 in the RIB (route table of LSR2 and LSR4)?
- How could these results be possible?
LER2#ping 126.96.36.199 source loop0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 188.8.131.52, timeout is 2 seconds: Packet sent with a source address of 184.108.40.206 !!!!! 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 220.127.116.11 % Network not in table LSR4#show ip route 18.104.22.168 % 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 22.214.171.124 126.96.36.199/32 nexthop 188.8.131.52 GigabitEthernet2 label 20009-(local:2010) nexthop 184.108.40.206 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 220.127.116.11 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 10.10.10.10/32 2102 Gi2 18.104.22.168 ! 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 10.10.10.10/32 2613 Gi4 10.100.1.2 ! 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 22.214.171.124 Routing entry for 126.96.36.199/32 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 188.8.131.52 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.