A port authority builds Phase 3 DMVPN so branch spokes register to hub NHS addresses over the tunnel. What NHRP roles must the design assign for registration to succeed?
Select an answer to reveal the explanation.
Short Explanation
Think of the hub as the front desk where every branch checks in. Spokes are the clients (NHC) that register; hubs are the NHS servers that keep the mapping book. Flip those roles and nobody finds anybody on the overlay.
Full Explanation
In DMVPN, Next Hop Servers typically run on hub routers and accept NHRP Registration Requests from Next Hop Clients on the spokes. A port-authority Phase 3 design must configure hubs as NHS servers and spokes as NHC clients that register tunnel and NBMA addresses to those NHS addresses so mappings exist for hub and later spoke-to-spoke resolution.
Configuring every spoke as an NHS and leaving hubs as NHC clients that pull mappings reverses the usual registration model and breaks hub-centric mapping. Disabling NHRP on hubs and relying only on static GRE peers abandons dynamic DMVPN mapping. Multicast-only NHRP on spokes with unicast NHRP exclusively on the Internet underlay edge misstates how registration and resolution work on the overlay.
Exam caveat: hubs = NHS, spokes = NHC registering to NHS—role reversal is a common distractor.
Operational check: set NHS addresses on spokes, confirm registration replies on hubs, show NHRP databases populated, and then test Phase 3 resolution for branch-to-branch traffic. 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.