A library consortium connects simple CE routers to a provider PE for a managed MPLS L3VPN. What is typically true about MPLS awareness on those customer CE devices?
Select an answer to reveal the explanation.
Short Explanation
The library’s CE is just a regular IP neighbor talking to the PE—like a customer who never needs to know how the courier’s barcode system works inside the warehouse. CE stays IP-only; the PE does the VRF lookup and sticks on the labels. You don’t make every branch CE run LDP.
Full Explanation
In a library-consortium managed MPLS L3VPN, customer CE routers typically remain ordinary IP devices. They peer or route with the PE in the attached VRF using static routing, OSPF, BGP, or EIGRP at the PE-CE edge, but they do not run LDP into the provider core, do not store remote sites’ VPN labels, and are not MPLS-aware. The PE performs VRF lookup, attaches the VPN and transport labels, and removes labels on the return path so the CE continues to see IP. That separation is why agencies can consume a managed VPN without becoming LSRs.
Requiring each CE to run LDP and swap transport labels toward the P core incorrectly pushes provider core duties onto the customer edge. Expecting CE routers to store every other site’s VPN label bindings in MP-BGP mixes PE roles into the CE; VPNv4 sessions and VPN labels live between PEs, not on typical CEs. Saying CEs perform penultimate-hop popping for the provider’s IGP label is also a provider-core function (PHP on P or PE), not a CE responsibility in the managed L3VPN model.
Exam caveat: “CE not MPLS-aware” is the default managed-service model; enterprise self-managed Carrier Supporting Carrier or similar edge cases are out of scope for this stem. Operational check for the consortium: confirm CE interfaces show IP routing neighbors only toward the PE (show ip ospf neighbor / BGP summary in the customer VRF context on the PE), verify CEs lack MPLS LDP neighbors to the core, and prove remote-site reachability while the CE’s FIB remains unlabeled IP.