DMVPN Hub Primary/Secondary

[ronit]

So we use a Cisco DMVPN setup with 2 Hubs and multiple Spokes. We use OSPF for routing over the tunnels. 

Currently, everything is working well. However, I notice that each Spoke is load-sharing traffic to the Hubs via both Hub routers. 

There's a noticeable latency difference between both Hubs so I would not like to load-share traffic, rather have the spokes prefer one hub over the other. I tried setting OSPF costs on the Hub Tunnel interfaces, but it doesn't seem to change the cost for the routes received on the spokes.

What is the easiest way for me to use the Hubs as Primary/Secondary instead of load-sharing?

[Rob Ingram]

@ronit to make the DMVPN primary/secondary you can configure the tunnel interface on the spoke to maximum 1 connection. A tunnel will be established to the first hub, if that fails only then will the tunnel to the secondary hub be established.

interface Tunnel0
 ip nhrp nhs cluster 1 max-connections 1

https://integratingit.wordpress.com/2016/10/12/configuring-dmvpn-phase-3-dual-hub/

[ronit]

Thanks, I was just testing this and it does seem to accomplish what I want, however, the failover seems to be very slow (around 25 seconds), I reduced the OSPF times to 1/3 seconds, but it still takes too long for the tunnel to be torn down and re-established.

Is there a way I can do this by influencing OSPF costs? I tried both bandwidth and cost on the tunnel interface and none of them seems to change the actual OSPF route metrics.

[Rob Ingram]

@ronit create 2 tunnels on the spoke, specify a higher metric for the hub router you wish to be the backup. On the DC end ensure you prioritise the return traffic via the primary Hub.

[ronit]

I tried this. No matter what OSPF Cost or Interface bandwidth I use on the hub site, the metric for the routes received via the 2 separate Tunnel interfaces is the same and hence it keeps load sharing.

[Rob Ingram]

@ronit depends on where (which interfaces on which device) you place the cost to influence the routing. Provide more information on your design.

If you want to investigate the max connection option, then this relies on the DPD keepalives (which you already have configured). The keeaplives will clear the IPSec SA once the primary tunnel is down. This will be slower than using routing to failover, as 10 seconds is the minimum keepalive timeout you can configure then you will either have get use to a 25-30 second outage during failover or provide more clarity around your design.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dplane/configuration/xe-16/sec-ipsec-data-plane-xe-16-book/sec-ipsec-dead-peer.html

[MHM Cisco World]

since you use one DMVPN cloud the max connection is better solution, 
for delay you missing one thing the IPSec, the IPSec can delay the failover sometime, what you need additional is config KEEP ALIFE for IPSec.
try this and check delay 

[ronit]

Thanks. Can you look at my config and see where the keepalive for IPSEC is, or tell me the commands? I will try it out.

I can see this line in my config "crypto isakmp keepalive 10 periodic" but this cannot be configured below 10 seconds.

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/content-networking/keepalives/118390-technote-keepalive-00.html

check the IPsec Keepalive 

[ronit]

Unfortunately this cannot go below 10 seconds.

[MHM Cisco World]

last timeout effect DMVPN failover 

NHRP Registration

NHRP registrations are sent from NHCs to their configured NHSs every one-third of the NHRP holdtime (configured by the ip nhrp holdtime value command), unless the ip nhrp registration timeout value command is configured, in which case registrations are sent out according to the configured timeout value. If an NHRP registration reply is not received for an NHRP registration request, the NHRP registration request is retransmitted at timeouts of 1, 2, 4, 8, 16, 32, and 64 seconds, then the sequence starts over again at 1.

The NHS is declared down if an NHRP registration reply is not received after three retransmission (7 seconds), and an NHRP resolution packets will no longer be sent to or by way of that NHS. NHRP registrations will continue to be sent at 1-, 2-, 4-, 8-, 16-, 32-, and 64-second intervals, probing the NHS until an NHRP registration reply is received. As soon as an NHRP registration reply is received the NHS is immediately declared up, the NHRP registration requests revert to being sent every one-third of NHRP holdtime or the value configured in the ip nhrp registration timeoutcommand, and the NHS can again be sent NHRP resolution requests. The show ip nhrp nhs detail command can be used to check the state of the NHRP NHSs.

[ronit]

Thanks. This is actually helpful. Let me try playing around with the "ip nhrp registration timeout value" command then.