A housing authority wants remote site routers to prefer simple summary or default routing via the DMVPN hub instead of carrying every remote prefix. What hub-side routing practice supports that scalability goal?
Select an answer to reveal the explanation.
Short Explanation
Let the hub hand out a summary or default—spokes stay skinny instead of memorizing every other housing site's prefixes.
Full Explanation
A housing authority that wants remote site routers to prefer simple summary or default routing via the DMVPN hub should originate summary or default routes at the hub. Spokes then forward unknown or remote-site destinations toward the hub without retaining a full mesh of every other property’s specifics, which shrinks RIB/FIB pressure and simplifies operations as more housing sites join the overlay.
Advertising every spoke /32 host route with a lower AD than the hub summary works against summarization by making specifics preferred everywhere. Disabling routing on the hub so spokes flood full tables to each other over NHRP alone removes the scalable hub routing role and misunderstands NHRP (mapping, not a full alternate IGP). Requiring each spoke to run a full Internet BGP table across the underlay before joining DMVPN is operationally absurd and unrelated to overlay scale.
Exam caveat: hub default/summary is a classic hub-and-spoke scalability practice; flooding specifics is the anti-pattern. Operational check: originate default or aggregates on the hub, confirm spokes install them with expected AD/metric, verify remote housing prefixes are reachable via the hub path, and ensure no accidental suppression of necessary locals.