A county courts network team adds a new remote courthouse spoke to an existing single-hub DMVPN. What operational benefit does dynamic neighbor registration provide versus static per-spoke GRE tunnels on the hub?
Select an answer to reveal the explanation.
Short Explanation
New courthouse? Configure the spoke and point it at the NHS—the hub's mGRE door is already open, so you are not carving a brand-new static tunnel for every building.
Full Explanation
Adding a new remote courthouse spoke to an existing single-hub DMVPN benefits from dynamic neighbor registration: operators configure the spoke’s tunnel, NHRP NHS, and crypto locally while the hub’s mGRE interface accepts registration without carving a dedicated per-spoke static tunnel interface. That is the operational win versus classic static GRE meshes on county hubs—faster site adds and less hub config churn as courts expand to new buildings.
Requiring the hub to configure a unique static tunnel for every new spoke before NHRP can start recreates the static provisioning burden DMVPN avoids. Dynamic neighbors do not eliminate underlay IP addressing on spokes; NBMA reachability to the Internet or provider cloud is still required. Claiming spokes can register only if the hub disables mGRE and uses one point-to-point GRE per county building contradicts the mGRE dynamic model that ENARSI emphasizes.
Exam caveat: dynamic registration is the differentiator versus static per-peer GRE. Operational check: add the courthouse spoke config only on the spoke (plus shared crypto and NHRP parameters), confirm registration in show dmvpn on the hub without a new hub tunnel interface, and validate overlay routing to that courthouse prefix end to end.