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

Hi Cristian,

Of course I did not leave the tunnel bandwidth at the default values.
Buffer tuning was also considered. Anyway, it was clear that EIGRP
was not the way to go with such a number of spokes on a lower-end
platform.

Mihai

On Saturday, September 19, 2009, Cristian Matei
<cristian.matei_at_datanets.ro> wrote:
> 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
>
> _______________________________________________________________________
> 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 - 14:20:44 ART