bgp keepalive & hold timers

[Serge G]

Hi,

Thank you for your reply.

I believe I understand the original problem and how to overcome it very
well. But my point is different.

In the original thread where you discussed this issue with Ondrej, there
was the following proposal:
> "For example bird can check that the hold timer proposed by a peer is at
least 2 times greater than the local keepalive timer as in the attached
patch"
> "I think that rejecting session when hold timer is smaller than local
keepalive (so it is clear misconfiguration), and just a warning when it is
smaller than 2*keepalive would be a good approach."
(https://bird.network.cz/pipermail/bird-users/2022-April/016070.html)
And my point regarding minimum-hold-timer addresses exactly this. IMHO, it
doesn't really make sense to compare local keepalive with remote holdtime
and then reject the session for some reason. If you want to limit the value
of holdtime that your router accepts, it makes more sense to set
minimum-hold-timer for that, not keepalive.

For example, you could configure:
    hold 30;
    keepalive 10;
    minimum-hold-timer 30;
And this won't let your peer set hold timer lower than 30. And this makes
the behavior pretty straightforward.

Otherwise, with approach like "hold timer proposed by a peer is at least 2
times greater than the local keepalive timer", you end up with some obscure
logic, so that people would have to go read the source code to understand
why the session is not establishing.


ср, 9 нояб. 2022 г. в 13:34, Alexander Zubkov <green at qrator.net>:

> Hi,
>
> I think this "knob" is somewhat orthogonal. Because this limits the
> possible values, but does not sets them. Currently you can set
> keepalive and hold timers and BGP peers choose the minimum hold timer
> among them. This setting is needed if you do not want you peer to set
> some low hold timer for you.
> But the original problem has other root. If you do not set keepalive
> timer - it is calculated from negotiated hold timer, but if you set it
> manually than it is fixed and if peer decides to use lower hold timer,
> that can break the mechanics silently. The easiest option to
> "workaround" it - is not setting keepalive timer by hand when you do
> not control the peer. Than it's value will always be lower than the
> hold timer (1/3 of it).
> Of course if you apply the patch, than you can use the keepalive timer
> to indirectly set the lower bound for the hold timer. But that looks
> weird. So if there is a demand for "minimum-hold-timer" option, it is
> useful by itself, IMHO.
>
> On Wed, Nov 9, 2022 at 11:25 AM Serge G via Bird-users
> <bird-users at trubka.network.cz> wrote:
> >
> > Hi,
> >
> > Not sure if it's still relevant, but I just wanted to propose another
> approach. Instead of comparing configured keepalive with the hold timer
> received from a peer, it might be more straightforward to add another knob,
> e.g. "minimum-hold-timer". (as on Juniper
> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/minimum-hold-time.html;
> Nokia also has similar knob)
> >
> > Reason for this is that (the following is just my opinion) 'keepalive'
> only configures an interval for keepalive messages. And if we start using
> the value of keepalive timer to enforce some restrictions on peer's hold
> timer, this may be confusing.
> >
> > In other words, "minimum-hold-timer" would more clearly indicate our
> restrictions on hold timers. If I see "minimum-hold-timer 30" in the
> configuration, I understand that this device has some limitations. If I see
> "keepalive 10", it doesn't tell me anything about restrictions, only that
> this device will send keepalives every 10 secs.
> >
> > P.S. I haven't dealt with mailing lists before, so forgive me if I reply
> to the wrong thread. This is the thread I;m replying to:
> https://bird.network.cz/pipermail/bird-users/2022-April/016071.html
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20221109/c814ed6d/attachment.htm>