A campus router and a cloud IOS XE router never establish BGP. The neighbor statement on the campus names a different ASN than the ASN configured on the cloud router. The IPsec SA is up. What must match?
Select an answer to reveal the explanation.
Short Explanation
The tunnel is up and you asked for a neighbor that does not exist. You make the ASN in the neighbor statement the ASN the cloud router actually uses. IKE is already fine, and the tunnel numbers do not have to match before BGP can start.
Full Explanation
An eBGP or iBGP session opens only with the ASN the peer is configured to use. This neighbor statement names a different ASN than the one on the cloud router, so the session never establishes even though the IPsec SA is up and the peer address may be reachable. Correct the neighbor ASN, or correct the cloud router, so the two sides agree. The IKE version is not the failure. The SA is up, and a BGP ASN mismatch does not tear it down. OSPF areas are not substituted for a BGP ASN. Tunnel interface numbers are local. They do not have to be equal, and BGP does not wait on them. Exam caveat: if this peering is meant to be eBGP, the two ASNs should match what each side configured and should still be different from each other. Making them accidentally identical turns the session into iBGP. Operational check: show ip bgp summary should move to Established after the ASNs agree, with the cloud prefixes installed.