A university runs staff in VPN 10 and research instruments in VPN 20 on the same fabric, and a shared printer subnet in VPN 20 must be reachable from VPN 10 without merging the full tables. Security requires explicit controlled leaking only for that subnet. Which route-leaking approach between VPNs with policy enforces this selective shared-service requirement?
Select an answer to reveal the explanation.
Short Explanation
You need one printer shared across VPNs without tearing down the walls everywhere else. A control policy with export-to copies just that prefix into the other VPN while everything else stays isolated.
Full Explanation
Selective inter-VPN route leaking in Catalyst SD-WAN is done with a centralized control policy. A route sequence matches the printer prefix (prefix list) in VPN 20 for the right sites and uses the export-to action with a VPN list containing VPN 10, which copies that route from VPN 20 into VPN 10 on the SD-WAN Controller, so staff edges learn only the printer subnet and all other tables stay separate. Return traffic needs the staff prefixes leaked back in the opposite direction with its own policy sequence. Export-to works only on service VPNs, not VPN 0 or VPN 512. A data policy with a route-leak action fails by plane: data policy matches and acts on packets at the edge and has no mechanism to copy routes between VPN routing tables. Exporting all VPN 20 routes fails by scope because it breaks the requirement to leak only the printer subnet and exposes the research instruments. Exporting the printer prefix from VPN 10 into VPN 20 fails by direction because it moves a route the wrong way and leaves VPN 10 with no path to the printer. In practice, confirm in show omp routes and the VPN 10 routing table that only the printer prefix appears, and test reachability to other VPN 20 hosts to confirm they remain unreachable.