Re: BGP Timers and Slow Convergence 101

Rich,

The reason we don't want to set the timers too low is that BGP is if the
link is flapping and can cause problems.

Use the command and it will indicate the lowest recommended values.

I use this command to speed the process up during the lab.

I use it in real life to make sure my phones don't skip a beat when my links
flip back and forth from the IGP and BGP.

Fun stuff.

It has its prupose.

Sure we can take it to extremes - I see some people do that a lot sometimes
- even at the risk of obscuring the use of a technique that otherwise might
be helpful to some.

Darby

http://www.darbyslogs.blogspot.com

On Fri, May 20, 2011 at 7:59 PM, Rich Collins <nilsi2002_at_gmail.com> wrote:

> So I guess you could configure the neighbors to each have "timers 0
> 0" and the bgp processes would not notice the peer being unreachable
> if the link were to go down.
> If the above is true, what would be a reason to set it that way?
>
> -Rich
>
> On Fri, May 20, 2011 at 2:17 PM, garry baker <baker.garry_at_gmail.com>
> wrote:
> > i guess if the workbooks you buy do not cover it you will have to go to
> the
> > RFC, to figure out it is the holdtime value that is negotiated and the
> > keepalives are based of this value:
> >
> > good stuff...
> >
> > http://tools.ietf.org/html/rfc4271
> >
> > Hold Time:
> >
> > This 2-octet unsigned integer indicates the number of seconds
> > the sender proposes for the value of the Hold Timer. Upon
> > receipt of an OPEN message, a BGP speaker MUST calculate the
> > value of the Hold Timer by using the smaller of its configured
> > Hold Time and the Hold Time received in the OPEN message. The
> > Hold Time MUST be either zero or at least three seconds. An
> > implementation MAY reject connections on the basis of the
> HoldTime.
> > The calculated value indicates the maximum number of
> > seconds that may elapse between the receipt of successive
> > KEEPALIVE and/or UPDATE messages from the sender.
> >
> > 4.4. KEEPALIVE Message Format
> >
> > BGP does not use any TCP-based, keep-alive mechanism to determine if
> > peers are reachable. Instead, KEEPALIVE messages are exchanged
> > between peers often enough not to cause the Hold Timer to expire. A
> > reasonable maximum time between KEEPALIVE messages would be one third
> > of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more
> > frequently than one per second. An implementation MAY adjust the
> > rate at which it sends KEEPALIVE messages as a function of the Hold
> > Time interval.
> >
> > If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
> > messages MUST NOT be sent.
> >
> >
> > --
> > Garry L. Baker
> >
> > "With sufficient thrust, pigs fly just fine..." - RFC 1925
> >
> >
>

-- 
Darby Weaver
Network Engineer
http://www.darbyslogs.blogspot.com
darbyweaver_at_yahoo.com
Blogs and organic groups at http://www.ccie.net