Two Cisco IOS XE routers, campus and cloud, peer eBGP using loopback addresses across an IPsec tunnel. The loopbacks are reachable with ping. The session stays down and eBGP multihop is not configured. What is missing?
Select an answer to reveal the explanation.
Short Explanation
You’ve confirmed the loopbacks are reachable, but Cisco IOS XE eBGP expects a neighbor to be directly connected and uses a TTL of 1 by default. Configure eBGP multihop to allow the loopback peering across the tunnel; a static route may enable the ping, but it doesn’t replace multihop.
Full Explanation
Cisco IOS XE eBGP assumes the neighbor is directly connected and uses a TTL of 1. Loopback addresses reached across a tunnel require more than one hop, so the session can remain down even when ping to the loopback succeeds; configure eBGP multihop to raise the permitted TTL. A route to the loopback is necessary for reachability, but not sufficient to permit this eBGP peering. A lower OSPF cost does not gate eBGP, and the routers can peer with BGP without OSPF. IKEv1 is not required: eBGP loopback peering is not negotiated inside IKE. A static route at distance 1 may provide the route that makes the cloud loopback pingable, but it does not tell eBGP to accept a neighbor that is not directly connected. Exam caveat: if the routers peer using the tunnel’s directly connected inside addresses rather than loopbacks, multihop is not required; it is needed for this loopback setup, not every cloud BGP session. Practical check: after configuring eBGP multihop and ensuring each loopback has a route, run show ip bgp summary and confirm the session reaches Established.