VPN tunnel recovery problem

[dwaynepeeters]

Hi  all,

I am having little problem concerning a site-to-site VPN tunnel and I am hoping someone could help me out.

In my network we have one HQ and one Branchoffice.

The HQ has got two routers, each connected to the internet and configured with VRRP for failover to the second internet connection

VRRP is setup so that it prefers one router, and tracks the WAN interface of that router so when it comes online again VRRP automatically switches back.

My branchoffice has got a DMVPN multipoint tunnel to both routers. (Dual hub single cloud)

When I kill the primary WAN connection of the HQ, VRRP almost immediately switches over to the secondary router (which is perfect).

And when I reconnect the primary WAN connection, it also switches back perfectly.

But..

When I disconnect the primary WAN and immediately reconnect it (like a flap), the tunnel doesn't work anymore.

It needs to wait until the ISAKMP keepalive timer expires, (which is like 20 seconds at minimum, can't tweak this any less) and then it works again.

After those 20 seconds the tunnel is buildup again, and the neighbourship restores and everything works nice and dandy.

But I wonder does it have wait for the keepalive?

Is there no way the let the tunnel automatically work again when I plug the cable back again?

Any help would be very much appreciated

Kind regards,

Dwayne Peeters

[Marcin Latosiewicz]

Dwayne,

If NEITHER of the sides of the tunnel detects that the other side is down there is no reason no to use previous SPIs and wait for IKE to do it's job.

Now what I THINK is the problem is the crypto socket which MIGHT get shut down when you flap the interface.

You can compare "show crypto socket" output before and after the flap if you're still interested in trying.

If you want full fledged investigation - I think it's better to open up a TAC case.

Also - does this problem persists if you source DMVPN tunnels from loopback?

M.

[david.tran]

You will NOT have this issue if you have DMVPN using loopback interface.  Loopback interface is "independent" of the WAN connection when you have redundant WAN connection. 

[dwaynepeeters]

Hi

Thank you both very much for your reply, I am still trying to solve this problem, but I don't quit understand your solution with using loopback interfaces.

Beneath is my config, but as you can see I use "tunnel source 192.168.3.2" which is the IP-adres given to the physical interface at which the tunnel terminates.

Could you please explain a little bit more about your proposed solution?

Again thank you very much for the effort.

interface Tunnel0

bandwidth 1000

ip address 10.1.1.3 255.255.255.0

no ip redirects

ip mtu 1400

no ip next-hop-self eigrp 1

ip nhrp map multicast 192.168.2.200

ip nhrp map 10.1.1.2 192.168.2.200

ip nhrp network-id 1

ip nhrp nhs 10.1.1.1

ip nhrp nhs 10.1.1.2

ip tcp adjust-mss 1360

no ip split-horizon eigrp 1

tunnel source 192.168.3.2

tunnel mode gre multipoint

tunnel protection ipsec profile MY_PROFILE

!

interface Ethernet0

ip address 192.168.3.2 255.255.255.0

no shutdown

[Marcin Latosiewicz]

Dwayne,

Sure thing.

Just remember - we have really few data to work with.

What we suspect is that tunne source going down is causing the GRE to go down temporarily, most likely closing the crypto socket with it (I indicated the outputs to check this out).

Now if you use loopback as tunnel source, it's a logical interface which is going to remain up/up regardless of state of physical interface - thus avoiding flaps.

M.

[dwaynepeeters]

Hi Marcin,

Thanks for the further explanation.

I'm going to look into this, it might be exactly what I'm looking for.

When I do a show crypto sockets, it reports that the socket is open.

Then I pull out the cable of the physical interface where the tunnel is sourced and run the command again, it still says open.

If I'd like to source the tunnel to a loopback interface.

I only need to do this on the Hub routers right?

Not on my spokes right

[Marcin Latosiewicz]

The principle should aplpy to all devices, actually.

But it makes more sense to account for this in case of hub.

[dwaynepeeters]

Hmm I find it quit hard to understand, but I keep trying

Just for my understanding (please do correct me if i'm wrong):

     - I have got one HQ and one Spoke;

     - The physical interface f0 of the Hub router is connected to the ISP router with IP-adres 192.168.1.100 (it's a lab so it's just a private IP)

     - The DMVPN cloud uses 10.10.10.0/24;

     - The LAN on the Hub uses 172.16.1.0/24;

     - But what kind of IP-adres should I configure on the loopback interface, that's what I'm not understanding.