MPLS common mistakes
MPLS · Understand the traps and how to avoid them.
Treating the label as a global identifier and assuming a label value learned from one neighbor means the same thing everywhere in the network.
Candidates memorize 'labels are locally significant' but still reason about label 1001 as if it were an end-to-end circuit ID, because the LDP label binding table they labbed on showed a single value per prefix.
What to do instead
For every label question, first identify the label space: per-platform (LDP, RSVP-TE, SR-MPLS global index is the exception) versus per-interface. State explicitly that an incoming label is only meaningful in the context of the interface it arrived on, and that the LFIB entry is (in-label, incoming interface) mapped to (out-label, next-hop). Practice by tracing one prefix through three routers and writing the three different in/out label pairs.
Confusing the control plane (label binding advertised) with the data plane (label actually installed in the LFIB), and assuming a received label is being forwarded.
Troubleshooting answers often stop at 'the neighbor advertised the prefix', which is true even when the route was rejected by a filter, lost to a better route, or the outgoing label was never programmed.
What to do instead
Adopt a two-step verification habit: check the RIB/LIB for the binding, then check the LFIB/FIB for the installed entry, and confirm the outgoing interface and next-hop MAC. Know that a label can exist in the LIB without an LFIB entry, and that 'show mpls ldp bindings' success does not imply forwarding.
Answering PHP questions by saying the penultimate router 'pops the label and forwards an unlabeled packet', without specifying the implicit-null behavior and the effect on the last hop's lookup.
Implicit null is signaled as label 3 and never appears on the wire, so candidates who only labbed explicit pops misdescribe what the egress router receives and why the egress advertises implicit null.
What to do instead
Memorize the three reserved values (0 IPv4 explicit null, 3 implicit null, 2 router alert) and their forwarding effect. Explain that with implicit null the penultimate router pops and sends a plain IP packet, so the egress does a normal IP lookup; with explicit null the label 0 is preserved so the egress retains EXP/QoS information. Note that PHP can be disabled per-prefix or globally, and that it is not used for IPv6 explicit null in the same way.
Mixing up route distinguishers and route targets, describing the RD as the thing that controls which VRFs import a route.
Both are 8-byte BGP extended communities carried in the same update, and both appear in 'show bgp vpnv4' output, so candidates conflate their roles.
What to do instead
State the roles as a memorized pair: the RD makes the customer prefix unique in the MP-BGP VPNv4/VPNv6 table (it is prepended to the IPv4 prefix to form the VPN prefix), while route targets are extended communities attached to the route that control import into and export from VRFs. A route can carry multiple RTs; the RD is not used for import decisions. Be able to trace a prefix from PE ingress VRF, through RD+RT+label, to PE egress VRF import match.
Assuming a VRF has a route to a remote site as soon as the MP-BGP session is up, ignoring the requirement for a matching import RT and a valid next-hop/label path.
Candidates focus on BGP session state and forget that VPN route installation is gated by RT import policy plus a resolvable next-hop and an incoming label, so 'BGP is Established but no route' confuses them.
What to do instead
Build a checklist for missing VPN routes: is the route in the VPNv4 table on the egress PE, is the export RT on the originating VRF matched by an import RT on the receiving VRF, is the next-hop reachable via an MPLS-enabled path, and is the label present? Verify with per-VRF routing table output and the VPNv4 table, and remember that a missing import RT produces a route that exists in BGP but never enters the VRF.
Configuring RSVP-TE but leaving the IGP unaware of TE, so the tunnel signals but the path is not what was intended, or the tunnel does not come up at all.
Candidates configure the tunnel interface and explicit path but skip the prerequisites: TE extensions in the IGP, MPLS TE enabled globally and on the relevant interfaces, and adequate bandwidth/reservations.
What to do instead
Memorize the RSVP-TE prerequisite chain: enable MPLS TE globally and on interfaces, enable IGP TE extensions so link attributes (bandwidth, affinity, admin weight) flood, ensure RSVP is enabled on the path interfaces, and confirm the headend has a path (dynamic or explicit) with available bandwidth. Verify with the TE topology database and the tunnel's actual path, not just the tunnel state.
Describing fast reroute as if the protected path is pre-signaled end-to-end, or as if a backup tunnel protects the whole LSP rather than a specific facility.
FRR concepts (link protection, node protection, facility backup, one-to-one backup) blur together, and candidates answer with 'the backup tunnel takes over' without saying where the protection is and when the PLR switches.
What to do instead
Be precise about scope: a bypass tunnel is a pre-established TE tunnel from the point of local repair that avoids a specific link or node, and it protects all LSPs traversing that facility; a detour is a per-LSP backup. Know that the PLR redirects traffic to the backup, that the merge point pops the backup label stack, and that the headend may then reoptimize. Distinguish link protection from node protection by which failure each survives.
Treating LDP and BGP-AD or BGP signaling for pseudowires as interchangeable, and choosing the wrong protocol for a VPLS or VPWS scenario.
All three can signal labels, so candidates pick based on familiarity rather than on what each protocol distributes and what autodiscovery it provides.
What to do instead
Anchor each protocol to its role: LDP distributes labels for IGP prefixes and can signal targeted LDP sessions for pseudowires (RFC 4447 FEC 128) between PEs; BGP-AD (RFC 6074) provides autodiscovery and signaling of pseudowires and VPLS membership via BGP; BGP can also signal VPLS labels. For a given question, first identify whether autodiscovery is required and whether the question is about a point-to-point pseudowire or a multipoint VPLS instance, then select the signaling accordingly.
Diagnosing an MPLS forwarding failure by checking only the IGP, without verifying label distribution, MTU, and the label stack depth at the point of failure.
Candidates default to routing troubleshooting habits and never look at the LDP session state, the LFIB, or the interface MTU, which is where many MPLS-specific failures actually live.
What to do instead
Use a layered troubleshooting order: IGP reachability, then LDP/RSVP session and binding state, then LFIB installation, then data-plane checks including MTU and label stack size. Remember that an MPLS packet is larger than the IP packet by 4 bytes per label, so an under-sized MTU on a core link drops large packets that pass a ping test; check interface MTU and adjust or enable fragmentation behavior as appropriate.
Assuming Segment Routing requires LDP to be disabled everywhere, or that SR-MPLS and LDP cannot coexist, and misdescribing how SR labels are derived.
Migration stories and lab guides often show 'disable LDP' as a step, so candidates overgeneralize it into an architectural rule and lose track of how SRGB and prefix-SIDs produce the label.
What to do instead
Explain SR-MPLS as a source-routed model where the headend imposes an ordered list of segments (prefix-SIDs, adjacency-SIDs) and no per-prefix signaling protocol is needed; the label for a prefix-SID is SRGB base plus the SID index. Know that LDP and SR can coexist during migration and that SR can be used for traffic engineering without RSVP-TE, with TI-LFA providing fast reroute. Verify with the SRGB, the prefix-SID advertisement, and the MPLS forwarding entry for the SID.