After a cutover, an IOS XE router has an established eBGP session to an Azure VPN gateway for 10.40.0.0/16, but packets still follow a static route for that prefix toward a tunnel that was removed. Why does the BGP route lose?
Select an answer to reveal the explanation.
Short Explanation
A sticky note on the counter beats the new sign on the door if you told the router to trust the note more. A static route at distance 1 still wins over eBGP at distance 20. You remove that static, or you raise its distance, and the Azure route can take over.
Full Explanation
Cisco IOS XE installs the route with the lowest administrative distance. A static route defaults to distance 1. An eBGP route defaults to distance 20. While the old static for 10.40.0.0/16 remains, the routing table keeps it and the eBGP route stays in BGP's table only. Packets follow the static next hop into the removed tunnel and blackhole, even though the BGP session to the Azure VPN gateway is established. An Established BGP session does not override a static route. The distances still decide, and distance 1 wins. OSPF external distance 110 is worse than both, and a native Azure VPN gateway does not redistribute this prefix into OSPF on the customer router by itself. An expired IKE lifetime would drop the tunnel and usually the BGP session with it. The session is established, so IKE is not the reason the BGP route is absent from the routing table. Exam caveat: a floating static with a distance above 20 is a valid backup. The defect is a static that is still better than eBGP, not the existence of any static. Operational check: show ip route 10.40.0.0 255.255.0.0 should show the eBGP next hop after the static is removed, and show ip bgp 10.40.0.0/16 should already list the Azure path.