A regional planning commission does not want DMVPN spokes to carry full Internet tables. How should hubs steer general Internet-bound traffic from those spokes?
Select an answer to reveal the explanation.
Short Explanation
Give the branches a simple ‘go this way for everything else’ default from the hub. They don’t need the whole Internet map—just a trustworthy exit sign into the overlay.
Full Explanation
Advertising a default from DMVPN hubs lets regional-planning spokes keep minimal tables while forwarding Internet or unknown enterprise destinations toward the hub for further routing. That pattern avoids placing full Internet tables on every branch while still giving spokes a trustworthy exit into the overlay.
Mandating that each spoke peer eBGP to both Tier-1 providers independently defeats the hub-steering model. Installing static /8s for every RIR block on each spoke null0 interface is operationally absurd at branch scale. Replacing IP routing with PBR that matches only HTTP to the underlay DHCP address is fragile and not the standard default-injection pattern.
Exam caveat: default from hub = scalable Internet steering for spokes without full tables.
Operational check: inject default from hubs, verify spokes install it via the overlay, traceroute Internet-bound flows through the hub, and ensure spokes do not learn full Internet tables. 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.