Issues with DMVPN Single Cloud Failover

[ERIK S]

Our network is having issue when we attempt to do a failover situation in between our two Hubs. 

The primary tunnel is configured as follows.

!
interface Tunnel1
description ***DMVPN TUNNEL -VPLS TRANSPORT***
bandwidth 250000
ip address 192.168.101.1 255.255.255.0
ip mtu 1410
no ip split-horizon eigrp 100
ip nhrp authentication ***
ip nhrp map multicast dynamic
ip nhrp network-id 192
ip nhrp shortcut
ip nhrp redirect
no ip split-horizon
ip tcp adjust-mss 1350
delay 500
tunnel source Port-channel1.2002
tunnel mode gre multipoint
tunnel key 100
tunnel vrf VPLS
end

The secondary hub is configured as follows:

interface Tunnel1
description ***DMVPN TUNNEL -VPLS TRANSPORT***
bandwidth 250000
ip address 192.168.101.2 255.255.255.0
ip mtu 1410
no ip split-horizon eigrp 100
ip nhrp authentication ***
ip nhrp map multicast dynamic
ip nhrp map 192.168.101.1 10.200.0.1
ip nhrp map multicast 10.200.0.1
ip nhrp network-id 192
ip nhrp nhs 192.168.101.1
ip nhrp shortcut
ip nhrp redirect
no ip split-horizon
ip tcp adjust-mss 1350
delay 550
tunnel source Port-channel1.2002
tunnel mode gre multipoint
tunnel key 100
tunnel vrf VPLS
end

They also have a Point-to-Point over the public Internet. 

The issue we see is that once the primary tunnel go down and once we bring it back up the Secondary Hub's subnets are learned over the point-to-point instead of the DMVPN tunnel. This is happening until we shut the Secondary Tunnel's DMVPN tunnel Interface and bring it back up.

Any thought on this?

Primary Hub's NHRP Table after shutting it down and bringing it back up.

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 UNKNOWN 192.168.101.2 NHRP never IX
1 10.200.0.3 192.168.101.3 UP 00:07:56 D
1 10.200.0.4 192.168.101.4 UP 00:08:01 D
1 10.200.0.5 192.168.101.5 UP 00:04:43 D
1 10.200.0.7 192.168.101.7 UP 00:07:25 D
1 10.200.0.9 192.168.101.8 UP 00:07:53 D
1 10.200.0.10 192.168.101.9 UP 00:00:06 D

[MikeO5422]

Please post a topology with relevant routing information if you can.

Initial thought:

Does the second hub prefer the P2P over the DMVPN under normal operation? NHRP entries will not be released unless the router who hosts them thinks its best path to the destination has changed. In my experience this is a common problem with a P2P between two DMVPN hubs.

In your recovery scenario, your backup's router's best path may not have changed from its perspective. However, when you shut that P2P down, its best path changes and NHRP entries are purged.

[ERIK S]

Under normal operation both Hubs prefer using the DMVPN tunnel over the P2P.

Have you encountered any other solutions than just shutting down the P2P?

[MikeO5422]

If NHRP entries are not being released after a recovery scenario then my thought would still be that basic routing path selection is messed up. Can you post a quick diagram of your topology that includes some example subnets, spokes, neighboring, and hub info?

Also a quick note - You mentioned they were both hubs but only one points to the other as an NHS server with a mapped address. I do not know enough about DMVPN to tell you if this is an issue, but may be worth checking on.

[a.alekseev]

Show configuration of the p2p tunnels

Also hub1#sh ip route x.x.x.x before, after shutdown and after no shutdown, where x.x.x.x is one of the nets behind second hub.