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 <santi...@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 <gr...@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: santi...@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."
