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

Hi,

        This is because the platform(3845) with EIGRP cannot scale to that
number of EIGRP peers. The "Goodbyes" are received NOT because the hello's
where not received by the spokes; if the spokes do not receive hellos from
the HUB, the spokes will torn down the neighborship by a "retry limit
exceeded" message; sice you receive "Goodbye" messages this has to do with
the updates which are multicast in the first place and need to be
ackonowledged; the platform is anyway not scalable to tat number of spokes
with EIGRP as I said, but did you try modifying the BW on the tunnel so
EIGRP can eat up more BW?
I hope you didn't leave it the default which is 9Kb.

Regards,
Cristian.

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
sheherezada_at_gmail.com
Sent: Saturday, September 19, 2009 1:59 AM
To: Dale Shaw
Cc: Cisco certification
Subject: Re: OT: DMVPN, aggressive EIGRP hello/hold-time timers for fast
convergence

Hi,

One of my customers had EIGRP for something about 250 spokes and
complained of hub receiving goodbyes from tens of random spokes at
random times. The more spokes they added, the more goodbyes showed
up. EIGRP was tuned for something slower than the default, in order
to allow for more hellos, but they wanted more aggressive timings. I
guess that the "goodbye" behavior was because of EIGRP trying to to
send hellos to all the spokes at the same time, which made the hub run
out of interface buffer resources.

What I did was switching to RIP passive mode with IP SLA monitor on
the spoke side. This was primarily because they also had to jump from
250 spokes to 400 spokes on a 3845 hub (not too much aggregate
traffic, just too many spokes). The big advantage here is that RIP is
stateless and the hub does not have to send updates any more. For the
SLA part, you can tune the tracking object to wait for a couple of
missing packets with the "delay down" statement (you have to keep it
the same as the flush interval). You might lose some packets when
switching over, but we feel comfortable with "timers basic 6 18 18
20". Did not try something more aggressive, but it might work.

You may want to search through the Networkers presentations on the
subject - they are pretty useful (in particular and in general).

HTH,

Mihai

CCIE2 #16616

On Fri, Sep 18, 2009 at 5:45 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Sep 19 2009 - 10:35:35 ART