bgp keepalive & hold timers

[Alexander Zubkov]

Yes, I just picked something more or least meaningful out of my head.
I agree that (keepalive < hold) is enough in strict sence.
Also, there probably should be some more complex check. because if
hold == 0, i.e. no timer, than at least keepalive == 0 should be also
allowed.

On Tue, Apr 19, 2022 at 4:32 PM Ondrej Zajicek <santiago at crfreenet.org> wrote:
>
> On Mon, Apr 18, 2022 at 04:43:32AM +0200, Alexander Zubkov wrote:
> > 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.
>
> Hi
>
> Thanks for the patch. You are right, it would be a good idea to check
> the hold time against the configured keepalive time. It is a question
> where to put the cutoff, as technically even longer keepalive intervals
> (than half of hold times) are viable, so in corner cases it may break
> some working setups. 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.
> Will look at that.
>
>
> > On Mon, Apr 11, 2022 at 1:12 PM Alexander Zubkov <green at qrator.net> wrote:
> > >
> > > Hi,
> > >
> > > Found interesting thing. If I set "keepalive time" for a BGP session,
> > > this values is not modified after the hold time negotiations and as a
> > > result I can get a BGP session with hold timer less than keepalive
> > > timer and it will die due to hold timer expired after some time.
> > > https://gitlab.nic.cz/labs/bird/-/blob/692055e3df6cc9f0d428d3b0dd8cdd8e825eb6f4/proto/bgp/packets.c#L908
> > > I think more correct bahivour would be to close the BGP session with
> > > unacceptable hold timer error in such case.
>
>
>
> --
> Elen sila lumenn' omentielvo
>
> Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
> OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> "To err is human -- to blame it on a computer is even more so."