An IOS XE router will run BGP across a route-based tunnel to Azure. An engineer sets the BGP router ID and the advertised peer address to the router's public WAN address. Azure will not accept that peer. Which address should be used instead?
Select an answer to reveal the explanation.
Short Explanation
Do not hand Azure the street address of your building and call it the desk inside the tunnel. Microsoft wants the on-premises BGP peer to be a tunnel inside address or a loopback, not the public WAN address that already identifies the VPN device. The public address is the IKE target, not the BGP speaker.
Full Explanation
Microsoft documents that the on-premises BGP peer IP must not be the same as the VPN device's public IP. Use an address that sits on the tunnel, or a loopback that is reachable across the tunnel and configured on the Azure local network gateway. The public WAN address remains the IKE destination. It is not the BGP endpoint. Using the Azure gateway's public IP as the on-premises router ID and peer reverses the two roles. That address belongs to Azure. The campus LAN default gateway is a next hop for local hosts. It is not automatically the BGP peer Azure should call, and it may not be reachable from the gateway across the tunnel. Azure does not require an OSPF router ID before BGP. The VPN gateway does not peer OSPF at all. Exam caveat: when BGP is enabled, Azure can derive the tunnel reachability for the peer. You still have to configure that peer address on the local network gateway and on the router. Operational check: the BGP neighbor address on the router and the BGP peer IP on the Azure local network gateway should match, and neither should be the router's public WAN address.