RE: DMVPN, aggressive EIGRP hello/hold-time timers for fast

>GRE keepalives aren't supported with DMVPN.

Due to multipoint gre to be specific

Actually it doesn't even fall to the Eigrp timers for switchover. I believe with a NHRP cache coordinated properly by DMVPN phase 3, your failover has to do with
NHRP cache resolution and fall back mechanisms there in.

Why?

I recently did a failover dmvpn hub test (a few months ago) with 2009 code. I think we dropped 1 ping when we pulled the power cable on the primary hub to drop it. Spoke continuous pings missed a ping and recovered- so it obviously didn't wait for eigrp.

Check out the IE Security blog on DMVPN- definitely can explain it more.

-Joe

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Dale Shaw
Sent: Thursday, September 17, 2009 10:46 PM
To: Cisco certification
Subject: OT: DMVPN, aggressive EIGRP hello/hold-time timers for fast convergence

Hi all,

Does anyone have any production experience with aggressively tuned
EIGRP timers in a DMVPN environment?

We have a requirement to detect loss of end-to-end connectivity over
DMVPN (multipoint GRE protected by IPSec) tunnels and re-route traffic
very quickly. This is due to a centralised VoIP implementation. We
need to detect loss of connectivity and converge inside 12 seconds.

Example using 3 second hellos and 9 second hold-time:

interface Tunnel0
 ip hello-interval eigrp 100 3
 ip hold-time eigrp 100 9

The DMVPN design guide doesn't delve into this very much, and uses a
35 second hold-time timer in all examples. GRE keepalives aren't
supported with DMVPN.

We have a dual cloud, single hub (per cloud) DMVPN design, and each
hub maintains ~35 EIGRP adjacencies. We have a mix of WAN access types
and speeds, from 4Mbps EoSHDSL to 200Mbps EoSDH. We provide end-to-end
QoS for control plane protocols so forwarding of EIGRP packets from CE
to CE should be handled appropriately through the provider MPLS core.

I have lab tested the above configs (as well as 2 sec/6 sec) and it
all works nicely, but I wasn't able to scale it up to accurately
represent the production network.

If you have 'been there, done that' and have some war stories, or,
better yet, success stories, please let me know.

Thanks,
Dale

Blogs and organic groups at http://www.ccie.net
Received on Fri Sep 18 2009 - 02:25:03 ART