Scope note: command syntax targets Cisco IOS-XE, the most common platform for MPLS PE/P roles in the field. Arista EOS supports MPLS/LDP only on specific ASICs (e.g. Jericho-based 7280R/7500R series) — items marked VERIFY should be confirmed against your specific platform before relying on them. RSVP-TE / Segment Routing are separate topics not covered here — this focuses on LDP-signaled hop-by-hop MPLS and BGP/MPLS L3VPN (RFC 4364).
PE-A · ingress LER
LDP
PE-Z · egress LER
01 Verify & Inspect
✓
MPLS Interfaces
Cisco IOS-XEshow mpls interfaces
Confirms which interfaces have MPLS forwarding actually enabled — a link can be up/up and still not be label-switching.
Walks the label-switched path hop by hop using MPLS echo request/reply — confirms the data plane matches what the control plane believes.
⚑
First-Look Diagnostics
show mpls ldp neighbor
show ip cef x.x.x.x detail
show mpls forwarding-table x.x.x.x
debug mpls ldp session (use sparingly)
◍
CEF Dependency
MPLS label imposition rides on CEF — confirm show ip cef isn't disabled
Process-switched packets bypass the LFIB entirely
02 Base Configuration (Cisco IOS-XE)
+
Enable MPLS Globally
ip cefmpls ip
CEF is required and enabled by default on most current platforms — verify rather than assume on older images.
if
Enable Per Interface
interface Gi0/1 mpls ip
Enables LDP discovery and label switching on that link specifically — global mpls ip alone does nothing without this.
🆔
LDP Router ID
mpls ldp router-id Loopback0 force
Use a loopback, not a physical interface IP, so the LDP session survives any single link flapping.
tp
Label Protocol
mpls label protocol ldp
LDP is the default on modern IOS-XE — the legacy alternative, TDP, is Cisco-proprietary and effectively obsolete; only relevant on very old gear.
🔒
LDP Authentication
mpls ldp neighbor x.x.x.x password MyKey
MD5 on the LDP TCP session — must match on both peers, same principle as BGP's TCP MD5.
📏
MTU for Labels
mpls mtu 1512
VERIFY — each label adds 4 bytes to the frame; if end-to-end MTU wasn't planned for the label stack depth in use, this is a common source of silent drops for large packets.
03 Label Operations Along the Path
Ingress LERPUSH
unlabeled IP in → label 100 added
→
P RouterSWAP
label 100 → label 200
→
PenultimatePOP
label removed one hop early (PHP)
→
Egress LERFORWARD
plain IP lookup, deliver
PUSH
Ingress (LER)
The router entering the MPLS domain classifies the packet (usually by destination prefix / FEC) and imposes the first label. Everything downstream forwards on the label, not the IP header.
SWAP
Transit (P Router)
A core/transit router does a simple label lookup, swaps the incoming label for the outgoing one, and forwards — no IP-layer lookup needed at all, which is the core performance/scale argument for MPLS.
POP
Penultimate Hop Popping
By default the second-to-last router pops the label before forwarding to the egress LER, so the egress router does one lookup (IP) instead of two (label, then IP). This is why a traceroute through an LDP-signaled LSP often shows the penultimate hop replying without a label.
Implicit-null (label value 3) signals "pop, don't forward with a label" — this is what enables PHP. Explicit-null (label value 0 for IPv4) keeps a label on the wire for QoS/EXP-bit preservation purposes even at the last hop, at the cost of losing the PHP optimization.
04 MPLS Label Header (32 bits)
Field
Width
Purpose
Label
20 bits
The actual label value used for the swap/pop lookup (0–15 reserved, e.g. 0 = IPv4 explicit-null, 3 = implicit-null)
TC (EXP)
3 bits
Traffic Class — carries QoS marking through the MPLS domain (formerly called EXP)
S (Bottom of Stack)
1 bit
Set to 1 on the last label in the stack — tells the router where the label stack ends and the payload (or next label) begins
TTL
8 bits
Decrements per hop like IP TTL — the mechanism traceroute mpls relies on
Multiple labels can be stacked (e.g. transport label + VPN label) — only the outer label is inspected for forwarding at each hop; inner labels ride along until the outer one is popped.
05 MPLS L3VPN Concepts (RFC 4364)
01
VRF
A virtual routing table on the PE, isolating one customer's routes from another's and from the global table — the fundamental building block of L3VPN separation.
02
RD (Route Distinguisher)
Prepended to a customer prefix before it enters MP-BGP, making otherwise-overlapping customer address spaces (e.g. two customers both using 10.0.0.0/8) unique in the shared VPNv4 table. It does not control import/export policy — that's the RT's job.
03
RT (Route Target)
An extended community that controls which VRFs a route is imported into/exported from. This is what actually implements hub-and-spoke, full-mesh, or extranet VPN topologies.
04
Two-Label Stack
Data plane uses two labels: an outer transport label (LDP-signaled, gets the packet PE-to-PE across the P routers) and an inner VPN label (BGP-signaled, tells the egress PE which VRF/CE interface to forward out of).
05
PE-CE Routing
Static routes, eBGP, or OSPF are the most common PE-CE protocols — routes learned from the CE get redistributed into MP-BGP with the VRF's RD/RT attached.
06
MP-BGP Overlay
PEs peer with each other (directly or via a route reflector) under address-family vpnv4 to exchange customer routes + labels — the P routers in the core never see a customer route at all, only the transport label.
Extended community is mandatory here — RT is carried as an extended community, and without send-community extended the remote PE can't import the route into any VRF.