DMVPN provides two of forms of NHS redundancy. Although the IWAN prescriptive model supports only the NHRP clusterless model, the authors wanted to demonstrate both models to provide a better understanding.
The NHRP clusterless model places all NHS routers in the same cluster, assigns preference by priority, and restricts the maximum number of active connections to an NHS. This model presents a possible configuration where an NHS hub is not present at a specific site.
For example, assume that six hub routers are distributed equally across three data centers. The design states that an NHC maintains an active connection to only three NHS routers at a time, and that a connection is not made to two NHSs in the same data center. Increasing the priority for the second router at each data center is not enough.
Table A-1 provides the ideal state where there is a connection to R11, R21, and R31, so an active connection to an NHS in each data center is maintained. If R21 fails, it is possible for R12 to become the third active NHS router. But R12 is in the same data center as R11, which violates the design.
The NHRP clustered model provides additional granularity by placing each geographic grouping of NHS routers in the same cluster, thus preventing scenarios from the clusterless model from happening. The number of NHS cluster connections is reduced for all three clusters appropriately.
Table A-2 demonstrates the same scenario as before but deployed in a clustered model. When R21 fails, R22 changes to the up state. R12 and R32 are prohibited from becoming active because they are still restricted to one active session for their appropriate cluster group.
Now that the concept has been explained, let’s visit a simple four-router topology as shown in Figure 3-7. Routers R11 and R12 belong to the same data center (Data Center 1) and are placed in cluster 1. Routers R21 and R22 belong to the same data center (Data Center 2) and are placed in cluster 2. R11 and R21 are assigned a priority of 1, and R12 and R22 are assigned a priority of 2.
Example A-1 provides the configuration for R31. Notice the additional keywords that were added to the NHS mapping entry.
R31-Spoke
interface Tunnel100
bandwidth 4000
ip address 192.168.100.31 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp network-id 100
ip nhrp holdtime 600
ip nhrp nhs 192.168.100.11 nbma 172.16.11.1 multicast priority 1 cluster 1
ip nhrp nhs 192.168.100.12 nbma 172.16.12.1 multicast priority 2 cluster 1
ip nhrp nhs 192.168.100.21 nbma 172.16.21.1 multicast priority 1 cluster 2
ip nhrp nhs 192.168.100.22 nbma 172.16.22.1 multicast priority 2 cluster 2
ip nhrp nhs cluster 1 max-connections 1
ip nhrp nhs cluster 2 max-connections 1
ip nhrp shortcut
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
Example A-2 displays the current state of the DMVPN tunnels. Notice that the entries for R12 and R22 are no-socket entries in NHRP state and R11 and R22 are in an up state.
R31-Spoke# show dmvpn detail
! Output omitted for brevity
IPv4 NHS:
192.168.100.11 RE NBMA Address: 172.16.11.1 priority = 1 cluster = 1
192.168.100.12 W NBMA Address: 172.16.12.1 priority = 2 cluster = 1
192.168.100.21 RE NBMA Address: 172.16.21.1 priority = 1 cluster = 2
192.168.100.22 W NBMA Address: 172.16.22.1 priority = 2 cluster = 2
Type:Spoke, Total NBMA Peers (v4/v6): 4
# Ent Peer NBMA Peer Tunnel
Addr Add State UpDn Attrb Target Network
----- ---------- -------------- ----- ------ ----- -----------------
1 172.16.11.1 192.168.100.11 UP 6d07h S 192.168.100.11/32
1 172.16.12.1 192.168.100.12 NHRP 6d07h SX 192.168.100.12/32
1 172.16.21.1 192.168.100.21 UP 6d07h S 192.168.100.21/32
1 172.16.22.1 192.168.100.22 NHRP 6d07h SX 192.168.100.22/32
Example A-3 displays the NHS redundancy status. Notice that R31 is not expecting any responses from R12 and R22 but shows the queue in a waiting state instead. The number of maximum connections per NHS cluster is shown for each cluster group at the bottom of the output.
R31-Spoke# show ip nhrp nhs redundancy
Legend: E=Expecting replies, R=Responding, W=Waiting
No. Interface Clus NHS Prty Cur-State Cur-Queue Prev-State Prev-Queue
1 Tunnel100 1 192.168.100.11 1 RE Running E Running
2 Tunnel100 1 192.168.100.12 2 W Waiting RE Running
3 Tunnel100 2 192.168.100.21 1 RE Running E Running
4 Tunnel100 2 192.168.100.22 2 W Waiting RE Running
No. Interface Clus Status Max-Con Totl-NHS Register/UP Expecting Waiting Fallbk
1 Tunnel100 1 Enable 1 2 1 0 1 0
2 Tunnel100 2 Enable 1 2 1 0 1 0
From the output of Example A-4, one can conclude that R31 has established an EIGRP neighborship with two of the four hubs, R11 and R21.
R31-Spoke# show ip route eigrp
! Output omitted for brevity
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D 10.4.4.0/24 [90/52992000] via 192.168.100.11, 00:01:58, Tunnel100
[90/52992000] via 192.168.100.21, 00:01:58, Tunnel100
Cisco. Cisco IOS Software Configuration Guides. www.cisco.com.
Cisco. “DMVPN Tunnel Health Monitoring and Recovery.” www.cisco.com.