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?
@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
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.
@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.
last timeout effect DMVPN failover
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.