A community college district wants spoke routers to keep small routing tables while still reaching other campuses across DMVPN. What hub routing pattern best supports that goal?
Select an answer to reveal the explanation.
Short Explanation
Hubs can hand spokes a short street directory—big summary blocks and maybe a default—instead of a phone book of every remote subnet. Smaller RIBs, happier branch routers.
Full Explanation
Summarization at DMVPN hubs reduces spoke RIB/FIB scale by replacing numerous remote specifics with aggregates or a default toward the hub. A community college district that wants small spoke tables while still reaching other campuses should advertise summarized prefixes—and often a default—from hubs toward spokes instead of flooding every remote specific route.
Redistributing every spoke /32 host route into BGP on each spoke with no filters explodes tables. Disabling routing on hubs and bridging all sites into one giant VLAN over GRE collapses L3 design. Running iBGP route reflectors on every spoke so hubs never advertise prefixes inverts scalable hub-and-spoke routing.
Exam caveat: hubs summarize; spokes stay lean—host-route floods are a common anti-pattern.
Operational check: summarize campus blocks at hubs, verify spoke RIB size drops, confirm reachability to remote campuses via aggregates/default, and filter accidental host-route redistribution. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.