Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

[Jeffrey Haas <[e-mail]>]

Enke,

Indirectly you are pointing out that an application at the end of a socket is loosely coupled to the TCP state of a session, at best.

This loose coupling gets even messier when you're on a "real" router with staged host paths, NSR features, etc.

For daemons that are roughly Unix, the usual pattern is likely "if your socket is blocked for the requisite period of time, peek into the TCP state, then decide whether to abruptly hangup or not".

The scenarios we've discussed haven't even gotten into the esoteric problems such as SOME types of TCP/IP packets might get through, but not others.  Two ready examples from my career include bugs in TCP-MD5 where a specific bit of data was mis-signed and wedged the TCP window, and a particular network I dealt with that IP checksumming issues that caused long-lived TCP sessions to die in it.  Another many of us have seen is path MTU discovery hiccups that result in wedged sessions.  

Middleboxes of all sorts, including security THINGs, only make this stuff worse.

-- Jeff

> On Dec 16, 2020, at 9:40 PM, Enke Chen <[e-mail]> wrote:
> 
> Regarding the patch for openBGPD pointed out by Job, I do not think it would work. When the TCP rcv window from the remote is 0, the BGP keepalive can still be queued to the socket buffer. It can take a long time for the socket buffer to be filled up by BGP keepalives.
> 
> It seems that the TCP_USER_TIMEOUT option can be used for the persistent zero-size window issue.  The timeout value could be multiples of the holdtimer (with min and max adjustments), perhaps somewhere around 5 or 6 minutes.
> 
>