A regional planning commission wants clinic spoke sites to reach only a central hub VRF, not each other, over an MPLS L3VPN. How should route-target import and export be arranged?
Select an answer to reveal the explanation.
Short Explanation
Hub-and-spoke is like a star-shaped mail room: clinics drop mail tagged for the hub, and only the hub’s tag gets into clinic inboxes. Matching export/import RTs that way blocks clinic-to-clinic shortcuts. One shared RT for everyone is full mesh — the opposite of what you want.
Full Explanation
VPN topology is shaped by which route targets each VRF exports and imports. For a regional planning commission’s hub-and-spoke clinics, spokes export a spoke RT that only the hub imports, and the hub exports a hub RT that only the spokes import—spokes do not import each other’s RT, so clinic-to-clinic shortcuts via the VPN control plane do not form.
Every site exporting and importing one shared RT yields full mesh, the opposite of hub-and-spoke. Spokes exporting nothing while the hub wild-card imports every VPNv4 route over-accepts and breaks the intended graph. P routers rewriting RTs hop-by-hop is not how MPLS L3VPN topology works; RT policy lives on PEs/VRF context.
Exam caveat: hub-and-spoke is an RT import/export pattern—memorize the asymmetric RT relationships, not a single mutual RT.
Operational check: configure spoke and hub RT sets as designed, show that spokes learn hub prefixes but not other spokes, and test clinic traffic hairpins correctly through the hub VRF. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.