← Interview Prep

MPLS — Theory

Label switching that sits between L2 and L3: how forwarding on a fixed-length label replaces the IP lookup, and the services it unlocks.

MPLS (Multiprotocol Label Switching) forwards packets on a short, fixed-length label instead of doing a longest-prefix-match IP lookup at every hop. The label is inserted in a shim header between the L2 frame and the L3 packet — hence the informal name "Layer 2.5." The point is not raw speed (modern silicon does line-rate IP lookups anyway) but decoupling the data plane from the control plane: the core forwards on labels it was told to install, and rich services (VPNs, TE, FRR) are expressed by which labels get pushed at the edge.

The core (P routers) never looks at the customer IP header — it only swaps a top label. All the intelligence lives at the edge (PE routers), which map a packet into a FEC and push the right label stack. This edge-smart / core-dumb split is the entire value proposition of MPLS.

The label & shim header

An MPLS label is a 32-bit shim. The EtherType announcing it is 0x8847 for unicast (0x8848 for multicast). Multiple shims can be stacked.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Label (20 bits)                | TC  |S|   TTL   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Ethernet: [ DA | SA | 0x8847 | MPLS shim(s) | IP packet ... ]

Label stack

Labels stack LIFO. The outer/top label is what the transport (the LSP) forwards on; inner labels identify a service. A typical L3VPN packet carries two labels:

  +-----------------+  <- transport label (LDP/RSVP/SR) : how to reach the egress PE
  | outer  S=0      |
  +-----------------+  <- VPN/service label (BGP)        : which VRF / which pseudowire
  | inner  S=1      |
  +-----------------+
  | customer IP payload ...
  +-----------------+

Reserved labels to know: 0 = IPv4 Explicit NULL, 2 = IPv6 Explicit NULL, 1 = Router Alert, 3 = Implicit NULL (the "pop and forward" signal used for PHP).

Roles: PE/LER vs P/LSR, FEC, LIB/LFIB

How an LSP gets built

1. The IGP (OSPF/IS-IS) floods reachability so every router knows the next hop toward each FEC prefix.
2. A label distribution protocol (LDP, RSVP-TE, BGP-LU, or SR via the IGP) assigns a local label to each FEC and advertises it to neighbours — building the LIB.
3. Each router picks, for the IGP next hop, the label its downstream neighbour advertised, and installs an LFIB entry: in-label → swap to out-label, send to next hop. The stitched chain of these entries is the LSP.

Downstream-unsolicited is the usual LDP mode: a router advertises "to reach FEC X, send me label L" without being asked. Labels are locally significant — each hop chooses its own values.

Label operations: PUSH, SWAP, POP

Worked example — hop-by-hop

PE1 sends a customer packet toward prefix behind PE2, across core P1→P2. Transport labels are locally significant; the VPN label (assigned by PE2) is untouched until egress.

Topology:   CE1 --- PE1 --- P1 --- P2 --- PE2 --- CE2
                    (LER)  (LSR)  (LSR)  (LER)

Ingress PE1 :  PUSH  [transport=17][vpn=90] onto IP packet
               (classify into FEC "prefix behind PE2" + VRF label)

  PE1 ── [17][90] IP ──▶ P1
P1  LFIB   :  in 17  -> SWAP to 22, next hop P2
  P1  ── [22][90] IP ──▶ P2
P2 is penultimate hop; PE2 advertised implicit-null (label 3):
P2  LFIB   :  in 22  -> POP (PHP), next hop PE2
  P2  ── [90] IP ──▶ PE2                (top transport label removed)
Egress PE2 :  in 90 -> POP vpn label, IP lookup in the VRF
  PE2 ── IP ──▶ CE2

Notice PE2 receives only the single VPN label 90 (transport already popped by P2), so it does exactly one label lookup to pick the VRF — that saving is the whole reason for PHP.

PHP & explicit-null

PHP (Penultimate Hop Popping): the egress PE tells the second-to-last router (the penultimate hop) to pop the transport label before forwarding, by advertising the special implicit-null label 3 for its FECs.

• Why it saves a lookup: without PHP the egress PE would receive [transport][vpn], pop the transport label, then look up the VPN label — two label operations on one box. With PHP the transport label is gone one hop early, so the egress does a single lookup (the VPN label, or a plain IP lookup for global/6PE). It removes a redundant double-lookup at the busiest node.
• Implicit null (label 3) never actually appears on the wire — it is a signal meaning "pop, don't swap." The penultimate router sends the packet with that label already removed.
• Explicit null (label 0 / 2) is the alternative: the label does stay on the wire (value 0 for IPv4, 2 for IPv6) so the egress still receives a labeled packet. Used when you must preserve the TC/EXP QoS bits all the way to the egress PE, since popping early would discard them. The egress pops it and forwards.

TTL handling: uniform vs pipe mode

When a packet enters the LSP the ingress must decide how the MPLS TTL relates to the IP TTL, and on egress whether the tunnel's hops are exposed. This controls what a customer's traceroute reveals.

Short pipe is a variant where the egress PE uses the customer's (inner) marking for its final queuing decision rather than the tunnel's TC, while still hiding the core hops. The interview point: uniform exposes the core to traceroute, pipe hides it as one hop.

Control plane: how labels are distributed

MPLS forwarding is one thing; signaling which label maps to which FEC is a separate control plane. Four options, each a topic of its own:

Services MPLS enables

Everything above is transport. The reason operators run MPLS is the services layered on top, expressed by the inner (service) label:

MTU considerations

Each label adds 4 bytes to the frame. A packet is enlarged by 4 × (number of labels), and that growth happens inside the provider network where the customer can't see it.

• If core links keep the default 1500-byte MTU, a full-size 1500-byte customer packet + two labels = 1508 bytes and gets dropped or fragmented. The standard fix is a core "jumbo"/baby-giant MTU (e.g. 1508–9216) so labels fit without shrinking the customer MSS.
• Because PMTUD's ICMP can be unreliable across the core, operators commonly clamp the customer MSS at the PE and always over-provision core MTU. "Add 4 bytes per label" is the number to state in the interview.