A municipal 911 PSAP needs a shared DNS prefix reachable from two VRF-Lite instances without merging the entire tables. What approach matches controlled leaking at VRF-Lite depth?
Select an answer to reveal the explanation.
Short Explanation
Think of a single shared library card usable in two locked rooms—you pass only that card through the door, not the whole filing cabinets.
Full Explanation
Controlled leaking for the municipal 911 PSAP shares only the required DNS (or similar) prefixes between VRF-Lite instances without merging entire tables. Operators use carefully filtered import/export, static VRF routes, or platform-appropriate route-target style controls so each VRF learns just the shared services while retaining isolation for everything else.
Deleting both VRFs and running only connected routes in the global table abandons isolation rather than implementing selective leak. EIGRP auto-summary collapsing both VRFs into one classful table is not a leak design and would destroy separation. CoPP copying DNS packets into every VRF forwarding engine confuses control-plane protection with routing-table leak and does not install DNS reachability in peer VRFs.
Exam caveat: leaked routes should be minimal and monitored—over-leaking reintroduces the overlap and policy problems VRFs were meant to solve. Syntax varies (static route vrf / next-hop vrf, BGP vpnv4 import on platforms that extend Lite, etc.); the concept is selective sharing.
Operational check: confirm the DNS prefix appears in both VRFs’ RIBs with the intended next hop, while SCADA-only and office-only prefixes remain confined. show ip route vrf on each side plus a DNS resolution test from both domains validates the leak without flattening tables.