Lab Objective
Add a second hub to the existing DMVPN cloud, configure each spoke with both hubs as NHRP next-hop servers, verify spokes register with both simultaneously, and confirm traffic automatically continues via the secondary hub when the primary becomes unreachable.
Lab Purpose
The single-hub topology used throughout earlier DMVPN labs in this series has an obvious weakness: the hub is a single point of failure for the entire overlay. Configuring each spoke with multiple NHS entries allows genuine hub redundancy, an essential design consideration for any production DMVPN deployment.
Lab Topology
Hub1 ---- Tunnel0: 172.16.200.1/24 (primary)
Hub2 ---- Tunnel0: 172.16.200.4/24 (secondary)
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24
Both hubs advertise reachability to the
same spoke LAN subnets via a routing
protocol running over the tunnelTask 1: Configure Hub2 as a Second Hub
Configure Hub2's tunnel interface identically in structure to Hub1's, joining the same DMVPN cloud.
Task 2: Configure Each Spoke with Both Hubs as NHS
Add a second ip nhrp nhs statement on each spoke pointing to Hub2, alongside the existing statement for Hub1.
Task 3: Verify Both Spokes Register with Both Hubs
Confirm each hub's NHRP cache shows both spokes registered.
Task 4: Verify Normal Traffic Flow via the Primary Hub
Confirm spoke-to-spoke or spoke-to-hub traffic currently prefers Hub1 based on routing metrics.
Task 5: Simulate Hub1 Failure and Verify Failover to Hub2
Shut down Hub1's tunnel interface and confirm spokes continue operating via Hub2 without manual intervention.
Solution and Verification
Hub2(config)# interface tunnel0
Hub2(config-if)# ip address 172.16.200.4 255.255.255.0
Hub2(config-if)# tunnel source gigabitethernet0/1
Hub2(config-if)# tunnel mode gre multipoint
Hub2(config-if)# ip nhrp network-id 1
Hub2(config-if)# ip nhrp redirectSpoke1(config)# interface tunnel0
Spoke1(config-if)# ip nhrp nhs 172.16.200.4 nbma [Hub2's public IP]
Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip nhrp nhs 172.16.200.4 nbma [Hub2's public IP]
-- Each spoke now has two nhs statements --
-- one per hub -- and will register with
-- both independentlyHub1# show ip nhrp | include Tunnel0
172.16.200.2/32 via 172.16.200.2 ... Tunnel0
172.16.200.3/32 via 172.16.200.3 ... Tunnel0
Hub2# show ip nhrp | include Tunnel0
172.16.200.2/32 via 172.16.200.2 ... Tunnel0
172.16.200.3/32 via 172.16.200.3 ... Tunnel0
-- Both hubs independently show both spokes
-- registered, confirming dual registration
-- succeededSpoke1# show ip route 192.168.12.0
O 192.168.12.0/24 [110/65] via 172.16.200.1
-- Hub1 currently preferred based on the
-- routing protocol's metricHub1(config)# interface tunnel0
Hub1(config-if)# shutdownSpoke1# show ip route 192.168.12.0
O 192.168.12.0/24 [110/65] via 172.16.200.4
-- The routing protocol automatically
-- reconverged to prefer Hub2 once Hub1
-- became unreachable, requiring no manual
-- reconfiguration on any spokeSpoke1-LAN-PC> ping 192.168.12.10
!!!!!
Success rate is 100 percent (5/5)
-- Connectivity between spoke LANs remains
-- fully functional despite Hub1's failureKey Takeaway
Dual-hub DMVPN redundancy relies on two independent layers working together: NHRP registration to multiple NHS entries ensures every spoke maintains mapping information with both hubs simultaneously, while a dynamic routing protocol running over the tunnel handles the actual failover decision based on standard metric comparison — DMVPN itself does not choose which hub is "active," it simply provides the overlay connectivity that the routing protocol then uses to make that decision exactly as it would over any other set of redundant links.