thomas-mangin
commented
1 year ago TLDR; I can not help with the information provided.
Thank you for this issue, but you are not explaining what you did, your problem, and/or what you expected to see.
Trying to guess: there is a TCP window trick (introduced by Alcatel-Lucent, now Nokia) to slow down UPDATE processing when the CPU was overloaded. It is well presented here https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window The blog links to a draft RFC https://datatracker.ietf.org/doc/html/draft-spaghetti-idr-bgp-sendholdtimer-08 about the issue.
Now, if the TCP window is filled due to a problem in ExaBGP's async engine, this is a different discussion than an issue caused by a peer closing their TCP window.
The code was updated a long time ago and should not block in these cases, causing the TCP connection to fail after HOLDTIME seconds
I do not even know what version of ExaBGP you are using. Please test on master and provide the FULL information requested if you still want help.
OS: CentOS 7.6 start command: env exabgp.log.level=DEBUG exabgp /etc/exabgp/exabgp.conf program output:
tcpdump packet capture:
exabgp.env [exabgp.api] ack = true chunk = 1 cli = true compact = false encoder = json pipename = 'exabgp' respawn = true terminate = false
[exabgp.bgp] openwait = 60
[exabgp.cache] attributes = true nexthops = true
[exabgp.daemon] daemonize = false drop = true pid = '' umask = '0137' user = 'nobody'
[exabgp.log] all = false configuration = true daemon = true destination = 'stdout' enable = true level = INFO message = false network = true packets = false parser = false processes = true reactor = true rib = false routes = false short = false timers = false
[exabgp.pdb] enable = false
[exabgp.profile] enable = false file = ''
[exabgp.reactor] speed = 1.0
[exabgp.tcp] acl = false bind = '' delay = 0 once = false port = 179
exabgp socket is block?