IETF Logo Mail Archive

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

Christoph Loibl <c@tix.at> Sat, 12 December 2020 13:58 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DEB3A110E for <idr@ietfa.amsl.com>; Sat, 12 Dec 2020 05:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tix.at
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHWdPmW08aRS for <idr@ietfa.amsl.com>; Sat, 12 Dec 2020 05:58:22 -0800 (PST)
Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E883A110A for <idr@ietf.org>; Sat, 12 Dec 2020 05:58:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XYA7UvFyimj4xG0M9/62bF/NQ0dDaDINgh5T3lMOTMk=; b=J5IiJVLn+yExOENCJakiyEzPco GjRK0v9f8G4Basa80q5p2SiYbpt2gNx38YpeB4N9qJm+EyCfMNRrAuL1z8RTmqJjEnJu1Zp8awq+O cMhncU0KYPIPFgaIs0OpsO+R2IRkYmyCt/amffbDtAbJv8I9OB3uU6Ij21WWGCsu0GVXafbbiNekn uE3qonw2o3ghFrsdsXdTzm3O9A23q+1PJQ5YyXH5IeGEQT2Ih8SSLpymFE9CUiYfYYMbBp/uH870y diq3xhRCN06Xa64xMmmWXma1+Z78Ri8HE58LBn8/qXxm6pFDnhdxbLGKYPCFRB5KrIyfgm3CZ7oSA dBkMBk3w==;
Received: from 80-110-96-202.cgn.dynamic.surfer.at ([80.110.96.202] helo=[192.168.66.207]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <c@tix.at>) id 1ko5Pb-0003Xu-N0; Sat, 12 Dec 2020 14:58:16 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <6F7C5906-51A8-43C2-8AEC-3DB74CB9941F@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_15A33AAB-C70B-4851-AA0E-75B6BE0A0F45"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Sat, 12 Dec 2020 14:58:13 +0100
In-Reply-To: <CAOj+MME4OHmoqJfzNQ4Tj6+wCd1kJVHPfJsDbk_+Xh8fh5G8Dg@mail.gmail.com>
Cc: Job Snijders <job@sobornost.net>, "idr@ietf. org" <idr@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
References: <X9PHRuGndvsFzQrG@bench.sobornost.net> <CAOj+MME4OHmoqJfzNQ4Tj6+wCd1kJVHPfJsDbk_+Xh8fh5G8Dg@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Sat, 12 Dec 2020 14:58:15 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/3qLwBLvtRmDlhyBe92822l_68jc>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Dec 2020 13:58:25 -0000

Hi,

Isn’t it save to assume that if a system cannot send any messages to its BGP-neighbor (for whatever reason) for HOLD TIME seconds, that the neighbor on the other side has by that time already declared the BGP session dead (is already “trying" to deliver a NOTIFICATION and has removed the routes from its RIB). If this is the case I see no point in trying to keep the session alive, because it will *always* sooner or later lead to a new session-setup + flapping routes. The BGP session (if the NOTIFICATION is queued) cannot recover from that state anymore (can it?) and is useless, even if there are chances that messages may get delivered later. 

Cheers Christoph

-- 
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 12.12.2020, at 10:22, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> I went back and reread the thread: 
> 
>    https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/ <https://mailarchive.ietf.org/arch/msg/idr/q0Sx5d3zZjfOmOQ4lO2OZAHh9Lc/> 
> 
> Shouldn't it be better if we first ask implementations to provide show command/api to list all peers and min-max durations of TCP Window being 0 without actually doing any automagic RST/NOTIFICATION/FIN ? 
> 
> This could allow to better understand which peers are getting behind in their control plane and perhaps also allow to set the RST timer under such conditions by operator? If he chooses this to be equal to HOLD TIME so be it but I am not sure this would be universally an optimal choice. 
> 
> Along the same lines we should perhaps also list per BGP peer number of DUPLICATE ACKS, RETRANSMISSIONS etc ... 
> 
> Are there implementations already deployed in DFZ allowing such data to be displayed per each BGP peer ?
> 
> Thx,
> Robert.
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email