A tax assessor’s EIGRP domain grew by dozens of neighborhood prefixes, and query scope is becoming painful. How does summarization at distribution primarily help scalability here?
Select an answer to reveal the explanation.
Short Explanation
Summaries draw a big circle around the new neighborhoods so the rest of the county doesn’t sweat every driveway change. Fewer specifics in the wider topology means quieter queries when something flaps inside. It’s a scalability fence, not an Internet-table dump.
Full Explanation
EIGRP summarization at distribution or other logical boundaries hides more-specific prefixes, shrinking topology tables and limiting how far queries about those specifics propagate. When a tax assessor’s EIGRP domain grows by dozens of neighborhood prefixes and query scope becomes painful, summarization creates coarser reachability at the summary boundary, reducing topology and query chatter for more-specifics behind the summary. That improves scalability after rapid prefix growth without requiring every access router to know every neighborhood leaf.
Summarization does not force every access router to store the full Internet BGP table locally—an unrelated and harmful outcome. It does not convert EIGRP into link-state flooding identical to OSPF area 0. It does not disable authentication so neighbors converge faster during flaps; authentication remains an independent adjacency-hardening control.
Exam caveat: summaries can blackhole holes under the aggregate if components are missing; combine with Null0 anchors and addressing plans that match the summary. Operational check: summarize at distribution, confirm upstream topology shrinks, flap a more-specific behind the summary and observe query containment, and verify any critical exceptions still leak via leak-maps if required.