Dual Hubs Single DMVPN Cloud

Hi,

 

I'm trying to understand the behavior of dual hubs single dmvpn cloud setup and here is the problem which I hope you could shed some suggestions.

 

There are 2 routers configured as the DMVPN hubs (R6,R7), likewise there are another 2 routers acting as the DMVPN spokes(R15,R16).

Here are the config

R6 (Hub1)

interface Tunnel2
 ip address 172.32.1.6 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp map multicast 169.254.70.1
 ip nhrp map 172.32.1.7 169.254.70.1
 ip nhrp network-id 2
 ip nhrp holdtime 3
 ip nhrp registration timeout 3
 ip ospf network broadcast
 ip ospf 1 area 2
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel key 2
end

 

R7 (Hub2)

interface Tunnel2
 ip address 172.32.1.7 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp map multicast dynamic
 ip nhrp map multicast 169.254.60.1
 ip nhrp map 172.32.1.6 169.254.60.1
 ip nhrp network-id 2
 ip nhrp holdtime 3
 ip nhrp registration timeout 3
 ip ospf network broadcast
 ip ospf 1 area 2
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel key 2
end

 

R15 (Spoke1)

interface Tunnel2
 ip address 172.32.1.15 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp network-id 2
 ip nhrp nhs 172.32.1.6 nbma 169.254.60.1 multicast
 ip nhrp nhs 172.32.1.7 nbma 169.254.70.1 multicast
 ip nhrp holdtime 3
 ip nhrp registration timeout 3
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 2
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel key 2
end

 

R16 (Spoke2)

interface Tunnel2
 ip address 172.32.1.16 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication DMVPN
 ip nhrp network-id 2
 ip nhrp nhs 172.32.1.7 nbma 169.254.70.1 multicast
 ip nhrp nhs 172.32.1.6 nbma 169.254.60.1 multicast
 ip nhrp holdtime 3
 ip nhrp registration timeout 3
 ip ospf network broadcast
 ip ospf priority 0
 ip ospf 1 area 2
 tunnel source FastEthernet0/1
 tunnel mode gre multipoint
 tunnel key 2
end

 

The problem I encountered is after I have shutdown the tunnel on Hub1 (R6), I expect the new NHRP registration should go to Hub2 (R7) from Spoke1 prespective but it does not seems to be immediate. Is there a way to speed up the convergence to the next available NHS?

Here are the steps I took:

1. On Spoke 1 (R15),

      clear ip nhrp

      trace 150.1.16.16 so lo0

      150.1.16.16 is the loopback interface configured on Spoke2 (R16) and is advertised via OSPF.

 

     R15# clear ip nhrp  

     R15# tr 150.1.16.16 so lo0
     Type escape sequence to abort.
     Tracing the route to 150.1.16.16
     VRF info: (vrf in name/id, vrf out name/id)
      1 172.32.1.6 28 msec 38 msec      <- Hub 1
         172.32.1.16 28 msec

     R15#tr 150.1.16.16 so lo0
     Type escape sequence to abort.
     Tracing the route to 150.1.16.16
     VRF info: (vrf in name/id, vrf out name/id)
      1 172.32.1.16 28 msec                  <- Direct Spoke 1 to Spoke 2 communication  

 

2.  Shutdown the DMVPN tunnel On Hub1 (R6),

        interface Tunnel2
          shutdown

 

3. Repeat the traceroute on Spoke 1 (R15),

    R15#clear ip nhrp
    R15#tr 150.1.16.16 so lo0
    Type escape sequence to abort.
    Tracing the route to 150.1.16.16
    VRF info: (vrf in name/id, vrf out name/id)
     1  *  *  *
     2  *  *  *
     3  *  *  *
     4  *
         172.32.1.16 60 msec * 

    Hub2 tunnel IP address (172.32.1.7) never appears in the traceroute output, even for subsequent traceroutes after clearing the NHRP cache. Any idea why is this the case?

    R15#clear ip nhrp        
    R15#tr 150.1.16.16 so lo0
    Type escape sequence to abort.
    Tracing the route to 150.1.16.16
    VRF info: (vrf in name/id, vrf out name/id)
     1  *
         172.32.1.16 144 msec *

 

   However I have run a debug on Hub2 and saw the NHRP registration request from Spoke1.

 

In addition, the ping result shows that after Hub1 tunnel interface is shutdown and the NHRP cache is cleared on Spoke1, it took around 20 seconds to switchover to Hub2. 20 seconds seems like a long time for today's network so is there other way to speed up the NHRP convergence in addition to running BFD for OSPF?

 

R15#clear ip nhrp

R15#ping 150.1.16.16 so lo0 rep 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 150.1.16.16, timeout is 2 seconds:
Packet sent with a source address of 150.1.15.15
..........!!!
*Jun  2 22:58:49.891: %OSPF-5-ADJCHG: Process 1, Nbr 150.2.6.6 on Tunnel2 from FULL to DOWN, Neighbor Down: Dead timer expired!!!!!!!!!!!!!!!!!!.
Success rate is 65 percent (21/32), round-trip min/avg/max = 13/20/25 ms

Comments

  • Hi,

       1. Your NHRP timers are too aggressive, but indeed NHRP will converge fast; your problem is that you left the routing/OSPF timers to their defaults, so your convergence time is given by the IGP.

      2. WIth your config, the spokes actively register to both hubs, look at clustering which will make the spokes register to the preferred hub and if that fails they wil register to the backup hub.

    What i would do is: use clustering with both hubs in the same cluster, tune the IGP timers or better use BFD if it's supported on mGRE in your IOS code, and tune NHRP to match on IGP timers. Being too aggressive with IGP and NHRP timers will add a lot of CPU overhead on the hubs, depending on the number of spokes.

     

     

  • Thanks Cristian. After changing the timers, everything works perfectly!

Sign In or Register to comment.