Control-plane chapters explain how routers agree on labels; this one is about the nanoseconds in between — what the forwarding hardware actually does to a labelled packet. The structure doing the work is the Label Forwarding Information Base (LFIB), indexed by incoming label: each entry names an operation (swap to label X / pop / push additional labels), an outgoing interface, and a next hop. Three operations, composed along a path: push at ingress, swap through the core, pop at (or near) the egress.
P1# show mpls forwarding-tableLocal Outgoing Prefix Bytes Outgoing Next HopLabel Label or Tunnel Id Switched Interface24007 24012 10.255.1.4/32 1842219 Gi0/1 10.1.23.324008 Pop Label 10.255.1.2/32 99120 Gi0/0 10.1.12.2
PHP: why the last swap is a pop
Consider the egress router without PHP: it receives a labelled packet, looks up the label (lookup one), finds 'pop and route', then looks up the IP destination (lookup two). Penultimate-hop popping moves the pop one router upstream: the egress advertises implicit-null (reserved label 3) for its own prefixes, which tells the penultimate router 'do not swap — just remove the label and send me the packet'. The egress then does a single IP lookup, like any router. Implicit-null never appears in a packet; it exists only in advertisements, as an instruction.
PHP has a cost: the label's 3-bit traffic-class field — where MPLS QoS marking lives — is discarded with the label, one hop early. Where the egress must see those bits (strict SP QoS boundaries), it advertises explicit-null (label 0) instead: the penultimate hop swaps to label 0, the QoS marking survives to the egress, and the egress pops it there. mpls ldp explicit-null flips the behaviour.
The stack: one core, many services
The bottom-of-stack bit in each label header is what makes MPLS a service platform. A VPN packet crossing a provider core carries two labels: the outer transport label — LDP-learned, swapped hop by hop, targeting the egress PE's loopback — and beneath it the service label — BGP-learned, untouched by the core, telling the egress PE which VPN table or pseudowire the payload belongs to. The core routers see and switch only the top label; the service label might as well be payload. Add TE and the stack grows: a tunnel label on top, transport beneath, service at the bottom. PHP composes perfectly: the penultimate hop pops the transport label, and the packet arrives at the egress PE leading with exactly the service label that router needs.
- Reserved labels worth knowing: 0 explicit-null (IPv4), 1 router-alert, 3 implicit-null (the pop instruction), 7 entropy-label indicator; 4–15 otherwise reserved.
- MPLS TTL: at ingress the IP TTL copies into the label TTL, decrements per hop, and copies back at egress — so traceroute works; providers often disable propagation so customer traceroutes shows one hop where the core is.
- MTU: every label adds 4 bytes; core links need the headroom (mpls mtu or, better, jumbo interface MTU), or 1500-byte customer packets with DF set die mysteriously mid-LSP.
A useful habit for every design and every outage: narrate the stack. 'Ingress PE pushes 24007 over 30 — P1 swaps 24007 to 24012 — P2 pops 24012 — egress PE reads 30, routes into the customer VRF.' If you can tell that story for a path, you understand it; when you cannot, the router that breaks your narration is where the problem lives. The next chapter turns that narration into commands.