Dear group, I'd like to draw your attention to an excellent article on an intricate interaction between BGP and TCP which can result in 'zombie routes' in the BGP Default-Free Zone. https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window My current running theory on the root cause of some mishaps in the global routing system is that certain BGP implementations can end up in a broken state where such systems will still generate and send out KEEPALIVE messages, but are unable to process other BGP messages (and such a system instructs all its peers to not send new data by signalling a zero TCP receive window). This is "Problem #1". "Problem #2" is that almost all BGP implementations are unable to robustly deal with systems suffering from Problem #1. Allmost all BGP implementations assume that when KEEPALIVE messages don't make it across the wire, the remote system will initiate the session tear down. But of course, if the remote system is in such a broken state that it can't issue session tear downs ... the combined system state is perpetually broken. The Security Section of https://datatracker.ietf.org/doc/html/draft-spaghetti-idr-bgp-sendholdtimer elaborates on three detrimental facets of the above situation. It is quite rare for systems to end up in the "Problem #1" state, but when it happens, all systems connected to the broken node probably are better off disconnecting from such a system than perpetually forwarding (and potentially blackholing) Internet traffic into the broken system. Kind regards, Job