In our last article, we configured and tested a basic VPNv4 configuration. In this article, we will do a hop by hop analysis of each device and look at a packet capture for a couple of the steps in the label switched path. We are using the exact same topology and router names. For the example, I have shut down the connection between P4 and PE2 so no load balancing will occur and we have a deterministic path to analyze.
For the analysis, we will examine the path from CE_Site_1 to 22.214.171.124 at CE_Site_2. For each device, we want to determine the egress interface, the next hop and any MPLS labels that should be present.
CE_Site_1 – forwarding a packet to destination 126.96.36.199
CE_Site_1#show ip cef 188.8.131.52 0.0.0.0/0 nexthop 10.1.1.1 GigabitEthernet2
CE_Site_1 is using the default route with a next-hop of 10.1.1.1
PE1 – receive a packet on Gi4 (vrf RED), forwarding for destination 184.108.40.206
//based on physical topology, we know this will arrive on Gi4 of PE1 PE1#show vrf brief Name Default RD Protocols Interfaces BLUE 110:210 ipv4 Gi5 Mgmt-intf ipv4,ipv6 Gi1 RED 100:200 ipv4 Gi4 //Gi4 is in VRF RED. Routing will occur based on this. PE1#show ip route vrf RED 220.127.116.11 Routing Table: RED Routing entry for 18.104.22.168/24 Known via "bgp 1", distance 200, metric 0, type internal Last update from 22.214.171.124 01:41:44 ago Routing Descriptor Blocks: * 126.96.36.199 (default), from 188.8.131.52, 01:41:44 ago Route metric is 0, traffic share count is 1 AS Hops 0 MPLS label: 2009 MPLS Flags: MPLS Required //we see that this will require a label of 2009, next we need to see how to reach the next hop PE1#show ip route 184.108.40.206 Routing entry for 220.127.116.11/32 Known via "ospf 1", distance 110, metric 4, type intra area Last update from 10.100.1.1 on GigabitEthernet2, 04:45:32 ago Routing Descriptor Blocks: * 10.100.1.1, from 18.104.22.168, 04:45:33 ago, via GigabitEthernet2 Route metric is 4, traffic share count is 1 PE1#show ip cef 22.214.171.124 126.96.36.199/32 nexthop 10.100.1.1 GigabitEthernet2 label 10008-(local:1014) //we can see that a transport label of 10008 will be added as this is sent out Gi2
Based on the output above, we expect PE1 to impose a bottom label of 2009 and a top label of 10008. Based on the physical topology, Gi2 is connected directly to P1. So we need to look at P1 and determine what will happen when it receives a packet with an MPLS label of 10008 (the top label).
P1 – forward a packet for label 10008 (DST_IP is irrelevant now)
P1#show mpls forwarding-table labels 10008 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 10008 20007 188.8.131.52/32 31294 Gi2 184.108.40.206 //incoming label of 10008 gets switched to 20007 and forwarded out GI2
Based on the above, we can see that P1 will send this out Gi2 with a label swap to 20007. Gi2 is connected directly to P2 in the physical topology. The bottom label (2009) is not evaluated or changed during this operation.
P2 – forward a packet for label 20007 (DST_IP is irrelevant now). The transport label will be popped (removed)
P2#show mpls forwarding-table labels 20007 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 20007 Pop Label 220.127.116.11/32 30003 Gi4 18.104.22.168 //incoming label of 20007 gets removed (popped) and the packet is sent out Gi4
We can see that the transport label is removed at P2, not swapped as it was on P1. The packet is forwarded out Gi4 to PE2 with only the bottom label (2009).
PE2 – Determine VRF membership based on the remaining bottom label and perform a destination lookup for 22.214.171.124 in the associated VRF
PE2#show mpls forwarding-table labels 2009 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 2009 No Label 126.96.36.199/24[V] 1140 aggregate/RED //we can see that this is for a prefix in a vrf [V] and that vrf is RED //so there is a need for a route lookup in that VRF PE2#show ip route vrf RED 188.8.131.52 Routing Table: RED Routing entry for 184.108.40.206/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 1 Advertised by bgp 1 Routing Descriptor Blocks: * directly connected, via GigabitEthernet4 Route metric is 0, traffic share count is 1
Since Gi4 is a standard interface on the PE node, our packet destined for 220.127.116.11 will be sent without any MPLS label. This will arrive as a normal packet at CE_Site_2.
When we pull this together, the following is the behavior when CE_Site_1 sends a packet to 18.104.22.168.
- CE_Site_1 sends a normal packet to PE1 without any MPLS information
- PE1 pushes a bottom label (2009) to identify the VRF and a top label (10008) to provide a path out Gi2 toward P1
- P1 swaps the top label (10008) to 20007 and forwards it out Gi2
- P2 pops the top label (20007) and sends the packet toward PE2 with only the bottom label (identifying the vrf)
- PE2 pops the bottom label and does a route lookup for the appropriate vrf. Then PE2 forwards a normal packet to the destination
I don’t think it is necessary to show the PCAP for every hop. I do want to show a capture in two places. After step 3 is interesting because it demonstrates that the two expected labels (20007/2009) are present.
Capture Between P1 and P2 (top label and bottom label)
Capture Between P2 and PE2 (shows only the existence of bottom label)
This is a fairly simplistic packet walk for a VPNv4 environment. The next article in the MPLS Intro Series will introduce BGP as a customer protocol and will allow routes to be introduced by the CE nodes.
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.