An emergency-management office reviews a managed MPLS L3VPN diagram and asks whether core P routers must hold each agency’s customer VRF routing tables. What is the describe-level answer?
Select an answer to reveal the explanation.
Short Explanation
P routers are the highway—labeled packets zoom by without the highway needing a filing cabinet for every driver’s address book. Customer VRF tables live on the PEs, not the P core. That’s what keeps the provider backbone scalable.
Full Explanation
In a managed MPLS L3VPN diagram for emergency management, core P routers typically do not hold each agency’s customer VRF routing tables. They forward labeled packets using the transport LSP (outer IGP/LDP or SR label), swapping labels hop by hop toward the egress PE. Customer VRF RIBs/FIBs and VPN label imposition/disposition live on PEs. Keeping P routers free of per-customer state is a primary scalability reason carriers use MPLS L3VPN for many civic tenants.
Claiming every P router maintains a full copy of each customer VRF FIB is the classic wrong mental model of an IP-only overlay core. Saying P routers run MP-BGP VPNv4 with every CE misplaces both sessions and roles: VPNv4 is PE-PE (or PE-RR), and CEs do not form VPNv4 with P cores. Answering “No” but asserting P routers only need CEF plus customer OSPF databases for each VRF is still wrong—customer OSPF belongs at PE-CE, not as a per-VRF requirement on P nodes.
Exam caveat: route reflectors and PE routers do carry VPN routes; do not extend that requirement to unlabeled assumptions about every P. Operational check: on a P router show the global MPLS forwarding table and confirm absence of customer VRFs (show vrf empty or no customer tables), while on PEs verify VRF routes and VPN labels; traceroute through the core should show labeled hops without P devices needing agency prefixes.