Re: BGP Timers and Slow Convergence 101

Hi Darby,

I think that I can understand setting the timer relatively high
(flapping) or low to speed up the discovery of an unreachable peer.

I guess I was just wondering in what scenario "best practices" would
mean to configure "0 0"?

-Rich

On Fri, Jun 3, 2011 at 7:01 PM, Darby Weaver <darby.weaver_at_gmail.com> wrote:
> 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
Received on Wed Jun 08 2011 - 16:57:29 ART