A regional retailer has a hub router in Chicago with 180 EIGRP spokes across slow DSL links. Route flaps at one store cause SIA events and CPU spikes at the hub, and the design must keep spoke routing tables small while allowing spokes to reach headquarters only. Which EIGRP query-scoping design best contains queries and meets summarization needs?
Select an answer to reveal the explanation.
Short Explanation
You win here by stopping questions before they snowball down slow links. Stub spokes tell the hub not to bother them with queries, and summarization shrinks tables like zip codes for neighborhoods. Small tables, calm hub, happy stores.
Full Explanation
EIGRP stub routers advertise their stub status so the hub does not send queries for lost routes to them, which bounds the query domain and prevents SIA on slow or large spoke topologies while summarization at aggregation points reduces topology size and further limits query range for summarized components. Deploying full mesh peering with only core summarization fails by concept because every spoke remains an active query target and retains full topology exposure, preserving SIA risk. Enabling stub with connected plus summary redistribution at every spoke misunderstands redistribution because spokes do not need to redistribute; stub advertisement plus central summarization is the scaling mechanism, and misplaced redistribution can leak detail. Configuring all routers as non-stub with filtering at spokes fails by concept because filtering controls advertisement, not query propagation, so queries still flood spokes and SIA remains possible. Exam caveat: stub is a spoke-side advertisement that limits queries, not just a filter. Practical check: verify stub status in EIGRP neighbors and confirm only summaries appear in spoke tables.