bgp keepalive & hold timers
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/692055e3df6cc9f0d428d3b0dd8cdd8e825eb... I think more correct bahivour would be to close the BGP session with unacceptable hold timer error in such case.
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. On Mon, Apr 11, 2022 at 1:12 PM Alexander Zubkov <green@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/692055e3df6cc9f0d428d3b0dd8cdd8e825eb... I think more correct bahivour would be to close the BGP session with unacceptable hold timer error in such case.
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@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/692055e3df6cc9f0d428d3b0dd8cdd8e825eb... 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@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."
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@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@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/692055e3df6cc9f0d428d3b0dd8cdd8e825eb... 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@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."
participants (2)
-
Alexander Zubkov -
Ondrej Zajicek