Thanks Gert. This was already my plan but I was looking for anyone with
experience of an alternative to timer tweaking, since I couldn't find one
that worked effectively.
Netherless, its fantastic to get feedback from others who have used the
timers to this effect with success. Just to clarify for anyone else reading
the thread:
Timers (holdtime) can be adjusted from the default 180 seconds to any 32bit
integer other than 0, and it is recommended that the keepalives are
readjusted in keeping to be 1/6 of the holdtime.
Interestingly, I now have values for keepalive bandwidth and processing
overhead, for anyone who wants to take this road (I still don't have a
viable alternative):
The KEEPALIVE messages are quite short (19 octets), so we can use the
formula 19*8/k, where k is keepalive frequency; hence 5 second keepalives
and and 30 second holdtimer gives only 30bps i/o per neighbor. Processing,
according to Cisco, is negligible.
Damon.
> -----Original Message-----
> From: Gert Doering [mailto:gert@greenie.muc.de]
> Sent: 03 July 2001 15:13
> To: Pegg Damon
> Cc: 'cisco-nsp@puck.nether.net'
> Subject: Re: Nasty iBGP design issue...
>
>
> Hi,
>
> On Tue, Jul 03, 2001 at 02:20:25PM +0100, Pegg Damon wrote:
> > I have a serious problem with failover speeds within iBGP
> for dual-homed
> > customers, from a carrier's perspective. [..]
>
> Depending on *what* fails, you can speed it up significantly
> by setting
> the BGP keepalive timers to a lower value in your neigbour
> configuration
> - something like "neigh 1.2.3.4 timers 1 5" (from memory, can't check
> from here), meaning "send a keepalive request every second, fail after
> 5 seconds without reply".
>
> I use this on a BGP setup between to partner companies, no connection
> to the Internet, "stability and robustness in the face of 100K routes"
> is a non-issue here, but "fast fail-over" *is*. So use with care.
>
> Also, you can decrease the default 60 seconds update interval between
> neighbours to something like 5 seconds or so. I forgot what
> the command
> was, but it works nicely. USE WITH CARE, don't do this on a router
> with weak CPU and many routes!
>
> [..]
> > router connected as described above. Now, suppose my
> router A fails.
>
> For router failurers, lowering the timers will work fine (see above).
>
> It's prone to lead to flapping if some infrastructure in between is
> unavaible for a few seconds, so the default is very
> defensive, and this
> is a Good Thing (because long-term stability in the overall Internet
> is such an important goal).
>
> gert
> --
> Gert Doering
> Mobile communications ... right now writing from *ICE to Frankfurt*
> ... mobile phone: +49 177 2160221 ... or mail me: gert@greenie.muc.de
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:43 EDT