BGP connect retry time
Hello, I am running bird's BGP on a slower link with accounted data. I would like to lower connection attempt frequency when the peer is down. I found only two parameters mentioning connection delays: 'connect delay time' and 'connect retry time'. From documentation, I understood to change the 'connect retry time' to slow down failed connection attempts, but the bird seems to use 'connect delay time' repeatedly if the connection fails (test: bird 1.6.6, peer's firewall drops all BGP packets). So, what is the 'connect retry time' used for? Also, if I increase the 'connect delay time' to lower BGP data throughput in case the peer is offline, I introduce also unwanted delay when everything works and only the BGP protocol is restarted... I understand bird 1.6.6 is rather old to ask for any help here. However, it is such a basic functionality I do not believe it to have changed recently. Also, I found no mention of these parameters in the NEWS file. Milan
On Sun, Mar 28, 2021 at 11:28:44PM +0200, dev@kou.li wrote:
Hello,
I am running bird's BGP on a slower link with accounted data. I would like to lower connection attempt frequency when the peer is down. I found only two parameters mentioning connection delays: 'connect delay time' and 'connect retry time'. From documentation, I understood to change the 'connect retry time' to slow down failed connection attempts, but the bird seems to use 'connect delay time' repeatedly if the connection fails (test: bird 1.6.6, peer's firewall drops all BGP packets). So, what is the 'connect retry time' used for?
Hi BIRD uses 'connect retry time' for repeated attempts where connection cannot be established, i.e. rather a maximum timeout for an attempt than limit between attempts. When connection attempt explicitly failed (e.g. received ICMP message about port closed), the protocol is restarted and therefore 'connect delay time' is used. (There is also 'error wait time', but that only happens when session falied after being established.) It is kind of counterintuitive oversight and we should add support for something like minimum connect retry time, it was not that important as overhead from unsuccessful connection attempt is usually negligible (compared to say session flapping). -- 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)
-
dev@kou.li -
Ondrej Zajicek