A port authority wants library branches, the main port HQ, and a remote annex to reach each other any-to-any inside one managed MPLS L3VPN. Which route-target design best supports that full-mesh reachability?
Select an answer to reveal the explanation.
Short Explanation
Any-to-any is like every library branch sharing the same club membership stamp. Export and import that shared RT set and everybody learns everybody else’s routes.
Full Explanation
For a port-authority any-to-any MPLS L3VPN among library branches, HQ, and a remote annex, every PE VRF must both export and import a shared route-target set so each site’s VPN prefixes are advertised into MP-BGP and then installed into every other site’s VRF. That common RT membership is the control-plane pattern that yields full-mesh VPN reachability without forcing every CE to peer with every other CE. Route distinguishers still uniquify overlapping prefixes in the BGP table, but RTs—not RDs—decide which VRFs import which VPN routes.
Exporting a unique RT per site and never importing any RT leaves each PE with no remote VPN routes, so branches cannot learn each other. Importing only a hub RT at branches while the hub exports nothing describes a broken or incomplete hub-and-spoke pattern, not full mesh, and still fails any-to-any among branches. Using identical RD values everywhere and omitting route targets entirely confuses RD with RT: identical RDs can even cause collisions in the VPNv4 table, and without RTs there is no selective VPN membership policy for any-to-any import.
Exam caveat: full-mesh RT design is not the same as hub-and-spoke RT patterning; exam stems that say “any-to-any” expect shared import/export, not spoke-only hub imports. Operational check at the port authority: on each PE VRF confirm route-target export and route-target import share the intended community set, verify VPNv4 prefixes appear in show bgp vpnv4 unicast vrf, and validate CE reachability between branches with ping/traceroute in the correct VRF rather than the global table.