A wastewater treatment plant adds new fire-station spokes to an existing single-hub DMVPN without provisioning a unique static tunnel destination on the hub for each station. What DMVPN capability enables that?
Select an answer to reveal the explanation.
Short Explanation
When a new fire station joins, point it at the hub NHS and let NHRP introduce it. You should not carve a brand-new static tunnel destination on HQ for every station. Dynamic neighbors are the operational win of single-hub DMVPN.
Full Explanation
When a wastewater plant adds fire-station spokes to an existing single-hub DMVPN without provisioning a unique static tunnel destination on the hub for each station, the enabling capability is dynamic NHRP-based neighbor formation. Each spoke is configured with the hub as NHS, registers its NBMA address, and the multipoint tunnel comes up without hub-side per-spoke static tunnel endpoints or per-peer tunnel interfaces. That dynamic onboarding is a primary operational advantage of DMVPN for growing civic spoke populations.
Per-spoke crypto map peer statements permanently hardcoded on the hub recreate static peer sprawl and fight the dynamic model. Provider PE VRF route distinguishers for each fire station belong to MPLS L3VPN provisioning, not DMVPN spoke addition. Mandatory dual-hub configuration before any spoke can register is false; single-hub designs register spokes successfully, even though dual-hub is a redundancy option.
Exam caveat: the hub still needs stable reachability and correct mGRE/NHRP/IPsec configuration; “dynamic” does not mean zero hub config—it means no per-spoke static tunnel destination list. Operational check: add a spoke with hub NHS and tunnel protection, confirm a new dynamic entry in hub show dmvpn without changing hub tunnel destination statements, then verify overlay routing and station reachability to plant HQ.