A city IT team needs the control-plane mechanism that carries VPNv4 prefixes between PE routers for multi-site agency L3VPNs. Which technology fills that role?
Select an answer to reveal the explanation.
Short Explanation
You’re looking for MP-BGP, the PE-to-PE control-plane channel that carries VPNv4 prefixes so each PE can learn which customer routes belong in its VRFs. The P core typically forwards labeled packets without taking part in that VPN-route exchange.
Full Explanation
For multi-site agency L3VPNs, MP-BGP is the control-plane mechanism that carries VPNv4 prefixes between PE routers. PEs exchange VPN-IPv4 (VPNv4) NLRI—customer prefixes prepended with route distinguishers—plus route targets, allowing each PE to determine which remote VPN routes to import into which VRFs. The P core typically forwards labeled packets and does not need those VPNv4 routes in a global table. Classic RIP v1 flooded between P routers with automatic VRF awareness is not this exchange mechanism: RIPv1 lacks modern VPN address-family capability, and P routers are not where VPNv4 routes are flooded for tenancy. NHRP redirect messages that install VPNv4 prefixes into the global table confuse DMVPN NHRP redirects with MPLS VPN control-plane operation; placing VPN routes in the global table that way would undermine isolation. Syslog templates that push VRF routes whenever a CE interface flaps are operational messaging, not a routing protocol for PE-to-PE VPNv4 exchange. Exam caveat: MP-BGP may use VPNv4 and VPNv6 address families, and route reflectors often scale PE-to-PE meshes; CE-to-PE routing is separate from PE-to-PE MP-BGP. Operational check: on PEs, use show bgp vpnv4 unicast all or the platform equivalent to inspect agency prefixes and RDs, confirm MP-BGP sessions with PEs or route reflectors are Established, verify P routers lack those VPNv4 entries, and check route-target imports inside each VRF.