An emergency-management office wants scalable spoke routing on DMVPN without flooding IGP queries across every site. Why is BGP often chosen as the overlay routing protocol?
Select an answer to reveal the explanation.
Short Explanation
IGPs love to chat; hundreds of emergency spokes make that chat expensive. BGP keeps the overlay address book scalable — advertise what you mean to advertise — without EIGRP query storms. NHRP still handles the tunnel mappings; BGP does not replace it.
Full Explanation
BGP is frequently preferred on large emergency-management DMVPN overlays because it scales prefix distribution with policy controls and avoids IGP query or full-topology flood characteristics across many spokes. Controlled advertisement keeps spoke RIBs manageable while hubs retain policy authority over what enters the overlay.
BGP does not replace NHRP; tunnel mapping and shortcuts remain NHRP’s job. BGP is not limited to Phase 1 because Phase 3 shortcuts “break TCP”—Phase 3 works with BGP overlays. Identical RDs on every spoke tunnel interface are an MPLS VPN idea, not a DMVPN BGP requirement.
Exam caveat: choose BGP for scale and policy; keep NHRP for mappings—do not claim BGP replaces NHRP.
Operational check: deploy BGP from hubs to emergency spokes with filters/summaries, confirm NHRP still registers, and compare query/flood behavior against a prior IGP design under spoke growth. 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. 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.