An airport authority wants branch fire-station sites to reach HQ services through a hub PE, not each other directly, in a managed MPLS L3VPN. Which RT patterning describes that hub-and-spoke VPN?
Select an answer to reveal the explanation.
Short Explanation
Hub-and-spoke VPN is the old phone-tree trick: branches talk to HQ’s number, not each other’s direct lines. RTs are set so spokes import the hub and the hub imports spokes—not spoke-to-spoke.
Full Explanation
In an airport-authority hub-and-spoke MPLS L3VPN, fire-station spokes must reach HQ services through the hub PE without learning each other’s prefixes directly. The RT pattern that enforces that topology is asymmetric: spokes export a spoke RT that only the hub imports, and the hub exports a hub RT that spokes import, while spokes deliberately do not import other spokes’ export RTs. MP-BGP still carries VPNv4 routes, but import policy shapes the VPN graph so spoke-to-spoke traffic must hairpin (or be intentionally blocked) via the hub VRF.
Having every spoke import every other spoke’s export RT while the hub exports nothing creates spoke mesh and removes the hub as the required intermediary—opposite of hub-and-spoke. Sharing one RT import/export pair across all sites is the any-to-any full-mesh design, which allows direct spoke-to-spoke VPN route installation. Relying on route distinguishers alone to block spoke-to-spoke traffic is incorrect: RDs uniquify prefixes in BGP; they do not implement VPN membership or topology policy. Without RT import filtering, spoke routes can still land in other spoke VRFs.
Exam caveat: hub-and-spoke is an RT-policy design choice, not an automatic side effect of using MPLS or unique RDs. Operational check for the airport: inspect each spoke VRF’s import RTs (hub only), confirm the hub imports spoke RTs, ensure spokes do not import peer spoke RTs, then verify with show bgp vpnv4 ... vrf that remote spoke prefixes are absent on spokes while HQ prefixes are present, and traceroute spoke-to-spoke paths via the hub.