A cloud IOS XE router has a connected 10.50.1.0/24 and advertises only that prefix by BGP. The rest of the VPC is 10.50.0.0/16. The campus can reach 10.50.1.0/24 and nothing else in the VPC. What was advertised too narrowly?
Select an answer to reveal the explanation.
Short Explanation
You told the campus about one room and called it the whole building. You advertised only 10.50.1.0/24, so that is the only VPC range the campus can reach. The rest of 10.50.0.0/16 was never in the BGP update.
Full Explanation
BGP advertises the prefixes you actually offer. The cloud router owns 10.50.1.0/24 as connected and advertises that exact prefix. The campus installs 10.50.1.0/24 and has no route for the rest of 10.50.0.0/16. Advertise the aggregate, with a matching route in the cloud router's table such as a summary to Null0 or the more-specific connected networks that cover it, if the design is supposed to hand the campus the whole VPC range. A default route was not what showed up. The campus learned a specific /24, which is the opposite of a default. The campus LAN prefix is the site's own network. Advertising it would not create VPC reachability, and it is not the prefix the campus is missing. The virtual private gateway is not the speaker in this design and does not originate an OSPF external for the VPC. Exam caveat: an aggregate must not be so broad that it covers ranges this router cannot reach. Summarizing 10.50.0.0/16 is right only if this router, or the VPC route table behind it, can forward the whole range. Operational check: show ip bgp neighbors advertised-routes should include 10.50.0.0/16, and a campus host should then reach an instance outside 10.50.1.0/24.