A civic data center designs single-hub DMVPN for township offices that use DHCP public addresses from local ISPs. How should NBMA addressing typically be planned for the hub versus the spokes?
Select an answer to reveal the explanation.
Short Explanation
HQ needs a stable public doorbell—a static NBMA address—that every spoke can dial as NHS. Spokes can live on DHCP ISP addresses and register their current number via NHRP. Flip that model and registration gets ugly fast.
Full Explanation
For a civic data center’s single-hub DMVPN serving township offices on DHCP public addresses, NBMA planning should place the hub on a stable/static public address that every spoke can target as its NHS, while spokes may use dynamic ISP addresses and register their current NBMA bindings via NHRP. The hub is the well-known rendezvous point; spokes are ephemeral from an addressing perspective. Flipping that model breaks registration because spokes cannot reliably find a moving NHS.
Giving every spoke a permanent static public IP while putting the hub on a changing DHCP address inverts stability requirements and makes NHS targeting fragile. Requiring identical public addresses on hub and all spokes so NHRP is unnecessary is impossible across sites and misunderstands NBMA uniqueness. Hiding the hub behind CGNAT with no inbound reachability while still expecting spoke registration fails underlay reachability to the NHS.
Exam caveat: spoke dynamic addressing still needs outbound reachability to the hub and working NAT-T/IPsec if NATed; static hub NBMA does not remove crypto/NAT considerations. Operational check: confirm hub public address stability and DNS/IP used in spoke NHS configs, bring up a DHCP-addressed spoke, verify NHRP registration shows the spoke’s current NBMA on the hub, and re-test after spoke DHCP renew to ensure remapping works.