Another one: Since killing bird is now safe-ish, I added one more bird3 to the party. Then I tried killing the first bird again. This caused the new bird3 to get stuck with BGP into Flush: BGP_IPv4 BGP --- flush 2024-12-19 16:35:08 Flush Socket: Connection reset by peer BGP_IPv6 BGP --- flush 2024-12-19 16:35:06 Flush Socket: Connection reset by peer No errors are logged on this second bird after the "Connection reset by peer" stuff, the first bird is retrying to connect, I see that with tcpdump. birdc restart BGP_IPvx does nothing birdc [dis|en]able BGP_IPvx also changes nothing Some more info about this new bird: - it is a RR so iBGP - has MD5 enabled for the sessions - import/export tables on - extended messages on - add paths on Tried it with killing multiple bird2s instead of bird3-bird3: - the ones with low number of routes (in my case <10k) do not get stuck Flushing - the ones with one (or more) full tables get stuck Flushing on the RR Killing birds looks like a theme since I have to kill the Flushing bird3 to get it to reconnect those sessions. The template from the Flushing bird RR (looks the same for v6): template bgp BGP_v4_t { debug { events }; disabled off; local as ASN; enable extended messages on; igp metric off; prefer older on; rr client; rr cluster id 0.0.0.1; ipv4 { add paths on; import limit 3000000 action warn; import filter BGP_IN4; export filter BGP_OUT4; import table on; export table on; }; } Cheers, Radu