A tax-assessor VPN complaint shows missing labels between PEs even though VPNv4 routes look present on the route reflector. What should operators verify first as the foundation for MPLS L3VPN forwarding?
Select an answer to reveal the explanation.
Short Explanation
No solid road, no delivery truck — VPNv4 routes on a reflector are just the address book. The underlay IGP plus LDP (or SR) has to build the labeled highway between PEs first. Fix that foundation before blaming BGP VPN exchange.
Full Explanation
MPLS L3VPN data-plane success requires a healthy underlay: IGP reachability to PE loopbacks and label distribution (commonly LDP or segment routing equivalents) that builds transport LSPs between those PEs. When a tax-assessor VPN complaint shows missing labels between PEs despite VPNv4 routes on a reflector, verify underlay IGP convergence and end-to-end transport LSPs first.
Whether every CE disabled split horizon on PE-CE eBGP does not create core LSPs. Forcing identical RDs so MP-BGP “merges faster” does not build labeled paths and harms uniqueness. Installing Internet defaults in every VRF before troubleshooting labels distracts from the underlay foundation.
Exam caveat: control-plane VPNv4 presence on an RR does not prove labeled forwarding works—underlay first.
Operational check: check IGP to PE loopbacks, confirm LDP/SR bindings, MPLS ping between PEs, then revisit VPNv4 and PE-CE only after the tax-assessor underlay LSP is proven. 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.