A city clerk’s office asks how a managed MPLS L3VPN separates control-plane signaling from packet forwarding for multi-site agency VRFs. Which description is accurate?
Select an answer to reveal the explanation.
Short Explanation
Control plane is the gossip (MP-BGP telling PEs about VPN routes); data plane is the courier using label stickers to move the actual packets. Different jobs, same VPN service.
Full Explanation
A city clerk’s managed MPLS L3VPN separates control plane from data plane clearly: MP-BGP advertises VPNv4/VPNv6 prefixes along with the VPN labels that identify customer VRFs between PEs, while the data plane forwards encapsulated customer packets across the P core using MPLS label stacks (VPN label plus transport/IGP label). P routers participate in the labeled transport path without carrying customer VRF RIBs. That split is the standard ENARSI description of how multi-site agency VRFs are signaled versus how packets actually move.
P routers flooding customer OSPF LSAs for every VRF while PE routers never run BGP inverts responsibilities: customer PE-CE OSPF stays at the PE edge (often redistributed into MP-BGP), and PEs—not P cores—run the VPNv4 BGP control plane. CEs exchanging VPN labels with each other over GRE while PEs only switch Ethernet frames describes neither classic L3VPN nor correct PE behavior. Claiming LDP alone carries all customer routes and that MP-BGP is unused ignores that LDP (or SR) provides transport labels, whereas customer VPN prefixes and VPN labels are distributed by MP-BGP.
Exam caveat: PE-CE routing protocol choice is independent of the PE-PE MP-BGP VPN control plane; do not assume OSPF between CEs replaces VPNv4. Operational check: verify MP-BGP VPNv4 sessions and advertised labels between PEs (show bgp vpnv4 unicast all summary), confirm LDP/SR transport bindings toward remote PEs, and capture or traceroute to show labeled forwarding in the P core without customer routes on P routers.