MPLS Intro Series – VPNv4 Packet Walk

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 20.2.2.2 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 20.2.2.2

CE_Site_1#show ip cef 20.2.2.2
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 20.2.2.2

//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 20.2.2.2

Routing Table: RED
Routing entry for 20.2.2.0/24
  Known via "bgp 1", distance 200, metric 0, type internal
  Last update from 20.20.20.20 01:41:44 ago
  Routing Descriptor Blocks:
  * 20.20.20.20 (default), from 20.20.20.20, 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 20.20.20.20
Routing entry for 20.20.20.20/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 20.20.20.20, 04:45:33 ago, via GigabitEthernet2
      Route metric is 4, traffic share count is 1
PE1#show ip cef  20.20.20.20
20.20.20.20/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      20.20.20.20/32   31294         Gi2        100.1.2.2

//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  20.20.20.20/32   30003         Gi4        20.100.2.2

//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 20.2.2.2 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   20.2.2.0/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 20.2.2.2

Routing Table: RED
Routing entry for 20.2.2.0/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 20.2.2.2 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 20.2.2.2.

  1. CE_Site_1 sends a normal packet to PE1 without any MPLS information
  2. PE1 pushes a bottom label (2009) to identify the VRF and a top label (10008) to provide a path out Gi2 toward P1
  3. P1 swaps the top label (10008) to 20007 and forwards it out Gi2
  4. P2 pops the top label (20007) and sends the packet toward PE2 with only the bottom label (identifying the vrf)
  5. 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.

No related content found.

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.