[nsp] BGP sessions drop during DOS and general DOS protections.

[Danny McPherson]

On 7/22/03 7:26 AM, "Robert E. Seastrom" <rs at seastrom.com> wrote:

> I have no idea whether Cisco's implementation rigorously enforces
> this, builds in slop, agrees to whatever the other side requests, or
> does something else; it may be possible to make your connection less
> stable instead of more stable (even ignoring the tradeoff Rob
> mentioned) by mucking with timers without a firm idea of what's going
> on under the hood.

Yes, Cisco (and other noteworthy vendors) conform to this (i.e., the lesser
of the two Hold Time values is used for the session, and most by default set
the keepalive interval to {Hold Time/3}).  Note that J-vendor uses a
different default Hold Time value than Cisco, so if you've got a
multi-vendor BGP network you're likely using J's Hold Time (If you haven't
mucked with things).

The good news is that even if both sides don't set the same Hold Time value
to some non-default-presumably-optimized-value the keepalive frequency is a
local function.  As such, you can always increase the frequency of
keepalives within a given Hold Time, thereby statistically increasing the
chances that a keepalive will find it's way across the Transport connection
to the BGP process on the remote BGP speaker (Also note that some
implementations don't provide a knob to explicitly set the keepalive
interval to something other than {Hold Time/3}, which may prove annoying to
some).

Of course, given that updates also serve as implicit keepalives, any
Internet-connected BGP speaker with full routing views will likely never
employ explicit keepalives for session liveness (although many
implementation do still transmit them needlessly) because of the constant
churn in the global BGP system.

-danny