City public-works users on an L3VPN report loss of connectivity. Which troubleshooting order best separates underlay from overlay problems?
Select an answer to reveal the explanation.
Short Explanation
Fix the road, then the address book, then the driveway — underlay LSP, MP-BGP VPNv4, then PE-CE. Jumping straight into CE debugs when labels are broken wastes a public-works afternoon. Layer the checks so each layer earns the next.
Full Explanation
Methodical MPLS L3VPN troubleshooting for city public-works outages separates planes: verify underlay LSP reachability between PEs first, then MP-BGP VPNv4 route exchange and RT import, then the PE-CE routing protocol and VRF forwarding. That order prevents wasting time on CE debugs when labels or VPNv4 membership are already broken.
Rewriting all RTs first, then rebooting every CE, then checking whether the IGP is up reverses foundational order. Beginning with PE-CE protocol debugs only, assuming transport LSPs and VPNv4 must already be fine, skips the usual root causes. Disabling PHP globally before inspecting VRF CEF or LDP bindings is not a first isolation step.
Exam caveat: underlay → VPNv4/RT → PE-CE is the disciplined civic VPN triage sequence.
Operational check: MPLS OAM between PEs, then check VPNv4 and RT import on the public-works VRFs, then validate PE-CE adjacency and prefixes, documenting which layer failed. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services.