A municipal hospital campus needs a joint city-county CMDB application to reach a shared prefix that must remain in both the clinical VRF and the county-admin VRF without merging the rest of those tables. What MPLS L3VPN mechanism enables that controlled sharing?
Select an answer to reveal the explanation.
Short Explanation
Picture two locked file cabinets that need one shared drawer for the CMDB. Route targets are the keys you copy for just that drawer — not a master key that opens everything. Extranet-style RT import/export leaks only the agreed prefix between VRFs.
Full Explanation
MPLS L3VPN isolation is driven by route targets, not by forcing VRFs to share an RD or collapsing into the global table. For a municipal hospital’s joint city-county CMDB prefix, each VRF exports—and the peer imports—an RT that carries only that shared route, which is the classic extranet-style leak pattern. The rest of the clinical and county-admin tables stay private while the agreed CMDB prefix is reachable from both.
Assigning identical route distinguishers so MP-BGP treats prefixes as one global table defeats RD uniqueness and is the wrong tool for controlled sharing. Disabling VRF awareness on every P router so label switching “freely bridges” domains breaks the PE/P model and does not implement RT policy. Replacing both VRFs with one global table plus ACLs abandons scalable VPN isolation for a brittle shared table.
Exam caveat: RDs uniquify; RTs define topology and leaks—extranet sharing is an RT import/export design, not an RD merge.
Operational check: export/import only the CMDB prefix via matching RTs, verify no unintended prefixes leak between clinical and admin VRFs, and document the extranet RT set for auditors. 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.