An IOS XE router has a working IPsec tunnel and an Established BGP session to an AWS virtual private gateway, but AWS never learns the campus prefix 10.8.0.0/16. The router uses a network statement for that prefix and has no route to it in the routing table. What is the cause?
Select an answer to reveal the explanation.
Short Explanation
BGP will not advertise a prefix it cannot already see, any more than you would vouch for a package that never arrived at your desk. Put 10.8.0.0/16 in the routing table, matching the network statement, and the advertisement can go. IKE is already done.
Full Explanation
On Cisco IOS XE, a BGP network statement advertises a prefix only when the routing table already holds that exact prefix and mask. Here the session is Established, so the TCP session inside the tunnel works, but 10.8.0.0/16 is absent from the routing table. AWS therefore never receives the advertisement. Install the prefix with a static route to Null0, or redistribute the source that owns it, and the network statement can match. The IKE lifetime is not blocking the UPDATE. IKE and the BGP session are both up. OSPF to the virtual private gateway is not available. AWS Site-to-Site VPN learns customer prefixes by BGP or by static configuration on the VPN connection, not by an OSPF adjacency. Raising the tunnel MTU above 1500 bytes is not a requirement for a BGP advertisement, and a standard internet path will not carry an MTU above 1500 without fragmentation trouble of its own. Exam caveat: the mask on the network statement must match the routing-table entry. A shorter connected route will not satisfy a longer network statement. Operational check: show ip route 10.8.0.0 255.255.0.0 should be present, then show ip bgp neighbors advertised-routes should list that prefix toward the AWS neighbor.