A logistics firm needs VPN 30 as hub-and-spoke via Chicago and VPN 40 as full mesh between warehouses, both over the same physical overlay. Application teams demand no cross-VPN leakage. Which segmentation approach correctly delivers different topologies per VPN with control policy?
Select an answer to reveal the explanation.
Short Explanation
You're running two different bus maps on the same roads. Control policy decides who learns whose routes per VPN.
Full Explanation
Centralized control policy on the SD-WAN Controller (formerly vSmart) controls OMP route and TLOC advertisement per VPN, supporting topology types such as hub-and-spoke, mesh and custom, so VPN 30 can restrict spokes to learn only hub routes while VPN 40 allows all-to-all advertisement over the identical transport. Using localized data policy on edges fails because data policy polices forwarding, QoS or service chaining after routes are learned and cannot restrict OMP topology advertisement fabric-wide. Merging both segments into VPN 0 fails because VPN 0 is the transport VPN and collapsing service VRFs destroys end-to-end segmentation and leaks traffic. Using App-Route policy fails because App-Route selects path, SLA and backup based on application probes, not which OMP prefixes are advertised to create hub-spoke versus mesh reachability. Exam caveat: control policy direction, site lists and VPN lists must align, otherwise the wrong VPN gets the wrong topology. Practical check: verify with show omp routes vpn 30 versus vpn 40 on spokes to confirm hub-only versus full peer prefixes before traffic testing.