A distribution site connects to an eBGP peer AS 65020 in VPN 20 and must advertise its three local aggregates (172.16.0.0/16, 172.17.0.0/16 and 172.18.0.0/16) to remote branches via the overlay while preventing a 192.168.99.0/24 management prefix from leaving the site. BGP is established but all routes appear remotely. Which BGP and overlay advertisement control meets this site requirement?

The site requirement is satisfied at the source WAN Edge where eBGP routes exist in service VPN 20, because OMP carries site prefixes to remote branches over the overlay and learned BGP prefixes do not enter OMP until BGP-to-OMP redistribution is enabled, so a localized route policy permitting only the three local aggregates provides required branch reachability while the implicit deny stops 192.168.99.0/24 from being originated, which explains why all routes currently appear remotely. Permitting aggregates plus management prefix through the same BGP-to-OMP redistribution is commonly used for full site visibility but fails isolation by concept because the management prefix is still originated into OMP and propagated overlay-wide. Reversing direction to redistribute OMP into BGP is standard for sharing overlay routes with an external domain, but it controls what AS 65020 learns from the site rather than what remote branches learn through OMP, leaving the reported overlay leakage unchanged. Applying an outbound BGP neighbor policy toward AS 65020 is standard eBGP filtering hygiene, yet it governs only that peering adjacency and does not control redistribution into OMP, so the management prefix would still be advertised remotely. For exams, carefully distinguish redistribution direction and policy point, whether the task limits overlay advertisement or peering advertisement and whether control belongs on the WAN Edge service VPN or controller. In practice, verify with show bgp routes vpn 20 and show omp routes locally and on a remote branch to confirm only the permitted aggregates are originated and received.