MPLS L3VPN Label Stack Packet Capture

Lesson Contents

This packet capture shows customer traffic crossing an MPLS Layer 3 VPN: a CE router with address 1.1.1.1 pings a CE router with address 5.5.5.5 on the other side of the provider network. In one direction the packets carry two labels, a transport label and a VPN label. In the other direction they carry only one, because of penultimate hop popping. That difference shows you exactly where the capture was taken.

If you want to build this yourself, the MPLS Layer 3 VPN configuration lesson walks through the setup. The transport labels come from LDP, which you can see in the MPLS LDP Session and Label Mapping Packet Capture. More captures are in the Packet Capture Library.

Want to open this capture in Wireshark yourself? The pcap file is free with a NetworkLessons account. Your free account also unlocks all our free lessons and every capture in the Packet Capture Library.

Create a free account to download the pcap

Already have an account? Log in and the download button appears here.

Capture overview

File	mpls-l3-vpn-packet.pcap
Packets	70 (10 MPLS packets: five echo requests and five echo replies)
Protocol	MPLS (RFC 3032), MPLS L3VPN (RFC 4364), ICMP
Capture point	The link between the ingress PE and the P router
Devices	Cisco IOS routers
Wireshark filter	`mpls`

The capture also contains lab background traffic (OSPF, LDP, ARP, IGMP and some Windows name lookups). Apply the mpls display filter to see only the labeled packets.

Packets in this capture

No.  Source   Destination  Labels   Info
32   1.1.1.1  5.5.5.5      17, 19   Echo (ping) request
33   5.5.5.5  1.1.1.1      19       Echo (ping) reply
34   1.1.1.1  5.5.5.5      17, 19   Echo (ping) request
35   5.5.5.5  1.1.1.1      19       Echo (ping) reply
...

Packet walkthrough

Echo request: two labels (packet 32)

Ethernet II, Src: Cisco_ed:7a:f1 (00:17:5a:ed:7a:f1), Dst: Cisco_be:0e:c8 (00:16:c7:be:0e:c8)
    Destination: Cisco_be:0e:c8 (00:16:c7:be:0e:c8)
    Source: Cisco_ed:7a:f1 (00:17:5a:ed:7a:f1)
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header, Label: 17, Exp: 0, S: 0, TTL: 254
    0000 0000 0000 0001 0001 .... .... .... = MPLS Label: 17 (0x00011)
    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
    .... .... .... .... .... ...0 .... .... = MPLS Bottom Of Label Stack: 0
    .... .... .... .... .... .... 1111 1110 = MPLS TTL: 254
MultiProtocol Label Switching Header, Label: 19, Exp: 0, S: 1, TTL: 254
    0000 0000 0000 0001 0011 .... .... .... = MPLS Label: 19 (0x00013)
    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1
    .... .... .... .... .... .... 1111 1110 = MPLS TTL: 254
Internet Protocol Version 4, Src: 1.1.1.1, Dst: 5.5.5.5
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Total Length: 100
    Time to Live: 254
    Protocol: ICMP (1)
    Source Address: 1.1.1.1
    Destination Address: 5.5.5.5
Internet Control Message Protocol
    Type: Echo (ping) request (8)
    Code: 0

Here’s what’s in the label stack:

EtherType 0x8847: MPLS unicast. There’s no IP header right after the Ethernet header, so a router on this link only looks at the top label.
Top label 17, S bit 0: the transport label. The ingress PE learned it from LDP (or another label protocol) for the BGP next hop, the loopback of the egress PE. The P routers only swap this label. They don’t know anything about the VPN.
Bottom label 19, S bit 1: the VPN label. The egress PE allocated it and advertised it to the ingress PE in an MP-BGP VPNv4 update, together with the customer prefix. Only the egress PE looks at it, to find the right VRF and outgoing interface. The S (bottom of stack) bit marks this as the last label. The egress PE knows an IPv4 packet follows because it allocated label 19 for an IPv4 VRF prefix.
TTL 254: the CE sent the packet with TTL 255. The ingress PE decremented it to 254 and copied that value into both labels (TTL propagation, the Cisco default).
4 bytes per label: the request is 122 bytes on the wire, 8 bytes more than an unlabeled frame would be. Keep this in mind for MTU: a two-label stack adds 8 bytes.

Echo reply: one label (packet 33)

Ethernet II, Src: Cisco_be:0e:c8 (00:16:c7:be:0e:c8), Dst: Cisco_ed:7a:f1 (00:17:5a:ed:7a:f1)
    Type: MPLS label switched packet (0x8847)
MultiProtocol Label Switching Header, Label: 19, Exp: 0, S: 1, TTL: 253
    0000 0000 0000 0001 0011 .... .... .... = MPLS Label: 19 (0x00013)
    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1
    .... .... .... .... .... .... 1111 1101 = MPLS TTL: 253
Internet Protocol Version 4, Src: 5.5.5.5, Dst: 1.1.1.1
    Time to Live: 254
    Protocol: ICMP (1)
Internet Control Message Protocol
    Type: Echo (ping) reply (0)
    Code: 0

The reply has only the VPN label. The transport label is gone because of penultimate hop popping (PHP):

The PE on this link (MAC 00:17:5a:ed:7a:f1) is the egress PE for traffic to 1.1.1.1. It advertised implicit null (label 3) for its own loopback through LDP.
The P router (00:16:c7:be:0e:c8) is the penultimate hop, so it popped the transport label instead of swapping it. The PE only has to do one lookup on the VPN label.
The MPLS TTL is 253 instead of 254 because the P router decremented it. The IP TTL inside is still 254. The routers don’t touch it while the packet is label-switched.

Both PEs happened to allocate label 19 as the VPN label for their customer prefix. Labels only mean something to the router that allocated them, so this is a coincidence and not a requirement.