A cloud-hosted IOS XE router learns a VPC subnet as connected and advertises it by iBGP to the campus router. It does not set the next hop to itself. The campus router has no route to the advertised next hop. What should the cloud router do?
Select an answer to reveal the explanation.
Short Explanation
iBGP passed along a return address the campus cannot find. You tell the cloud router to set itself as the next hop when it advertises the VPC subnet, because the campus can reach the cloud router through the tunnel. It cannot reach the untouched next hop, and IKE identity will not fix that.
Full Explanation
iBGP does not rewrite the next hop by default the way eBGP does. The cloud router advertises the VPC subnet with a next hop the campus cannot resolve, so the campus keeps the prefix out of the routing table even though the BGP session is up. Setting next-hop-self on the advertisement toward the campus peer makes the next hop the cloud router, which the campus reaches through the tunnel. The AWS virtual private gateway is not the iBGP speaker here and does not run OSPF, so its dead interval is irrelevant. The IKE identity affects whether the tunnel authenticates. The tunnel is already carrying iBGP, so identity is not the missing route. Raising the tunnel MTU above 1500 does not make an unresolved next hop reachable, and an internet path will not usefully carry that MTU. Exam caveat: next-hop-self fixes this iBGP case. If the session were eBGP to a native gateway, the next hop would already be the gateway, and this command would be the wrong tool. Operational check: show ip bgp on the campus router should show the cloud router's tunnel address as the next hop, and the VPC prefix should then enter the routing table.