A campus WAN Edge runs OSPF to the LAN in VPN 10 and eBGP to a data-center peer in VPN 20, but remote sites receive every LAN prefix including test subnets. The engineer must limit overlay advertisements to production prefixes. Which OMP redistribution control advertises only intended prefixes into the overlay?
Select an answer to reveal the explanation.
Short Explanation
You tame the flood by filtering at the source. A redistribute policy with prefix lists lets only production LANs ride OMP to remote sites.
Full Explanation
The correct control works because OSPF routes in VPN 10 do not enter the SD-WAN overlay until OSPF-to-OMP redistribution occurs on the WAN Edge, so an OMP redistribute route policy with permit prefix-lists for production prefixes and implicit deny for test subnets enforces the intent at the origination point for all remote peers at once. An outbound OSPF policy toward campus LAN neighbors fails by direction and protocol scope because it governs what the edge advertises back into OSPF rather than what OSPF contributes to OMP, leaving test subnets in the local RIB to be redistributed and received overlay-wide. An inbound OMP policy on remote sites fails by control point because it only filters installation into each remote RIB after flooding has already occurred and must be maintained everywhere, so it does not limit overlay advertisements as required. An outbound eBGP policy in VPN 20 fails by VPN and source-protocol scope because it governs the separate data-center peering and cannot filter OSPF-originated VPN 10 prefixes entering OMP. Exam caveat is to match protocol, VPN, and policy application point together rather than selecting any familiar prefix-list filtering statement alone. Practical check is to verify the redistribute policy sequence and prefix-list matches on the originating WAN Edge, then verify with show omp routes and advertised-route output that only production prefixes are originated while test subnets remain present in OSPF but absent from OMP.