A regional bank connects branch LANs with eBGP to a core switch in VPN 20 and must advertise those LAN prefixes into the SD-WAN overlay. Templates are mandatory, and the WAN Edge must still form OMP peerings over both transports. Which BGP and overlay advertisement design using feature templates should the engineer deploy for service-side BGP?
Select an answer to reveal the explanation.
Short Explanation
You’re keeping branch routing in the service VPN, where it belongs. BGP learns the LAN prefixes, and redistribution sends them into OMP for the overlay while OMP peerings stay up over both transports.
Full Explanation
Configure BGP in VPN 20 with a service-side BGP feature template for the LAN neighbor, then redistribute BGP into OMP so the WAN Edge advertises the learned LAN prefixes into the SD-WAN overlay. This keeps service routing in its intended VPN and leaves OMP peerings over both transports intact. A transport-side BGP template with the LAN neighbor and LAN networks under the OMP address family fails because VPN 0 is for transport connectivity and locators, not service-side LAN routing; it does not provide the required service-prefix injection. Redistributing OMP into BGP reverses the required direction: it brings overlay routes into the local BGP domain rather than sending LAN routes from BGP into OMP. A CLI add-on that enables BGP globally and relies on network statements is not the required feature-template design, and network statements alone do not redistribute BGP routes into OMP. Exam caveat: the required action is BGP-to-OMP redistribution on the WAN Edge, not OMP-to-BGP redistribution or transport-side advertisement. Practical check: in SD-WAN Manager, verify that the branch prefixes appear as OMP routes originated by the local system IP.