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

Brian Dickson <> Wed, 16 December 2020 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8543A3A0B2D for <>; Wed, 16 Dec 2020 11:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5EWcmDj5vqVQ for <>; Wed, 16 Dec 2020 11:17:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC0333A0C4F for <>; Wed, 16 Dec 2020 11:17:49 -0800 (PST)
Received: by with SMTP id d68so5960834vka.2 for <>; Wed, 16 Dec 2020 11:17:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Sn1D6hRnRA3DCcH8uBqF8egngBZS4X7t1Xw9244p1Do=; b=frqryb3hfkTAygKYJZyzRNc9MXgAKn63A50JuP73sRgkS7vYqg28F7f+FcaLLI8jR5 Dj+VFF3s2878Gjss2myblH0jfwhsHrygU8hvEgiiZDj1f9NUc4gS5+WlTrm9hLGpW5xF k+yDsIDta37pZ4z+LVXk6BV7A5sqePV9j4En9FFFdOxDzKuY9B25fEt+PhRu92uP9Eay F4AoGEIMzof0kZz1CTG5rdv1hzbaYpXjgFfZ2mepca3aZIhOc25oRdl1Hd7vk7SzeUog BQqUWL8LQ9layHTCYXaCTTBcHs3bJyZ5JpTVNAooRjuV9rzAreG3D2H66G5hieIIA1JG TRkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Sn1D6hRnRA3DCcH8uBqF8egngBZS4X7t1Xw9244p1Do=; b=ODZCoJTKSnIK1WZVns1is/KeEDt57Dn1X+mUO9ZBemvUAz5/h2lBn2hlzBJmquVE7Z QNQq80f1A5HFxYLmJgoLUFLPJ8TNSMafBVUjyicy1oCgxQ3IHQtOuo828I3KcxzzGfvg sf2ZUJYJDz1ueE9auzPlBW+5a05WZ4OhacH7D6HEgqWxfXbSVmXxJcLLq2/GJg06T+X0 H4H8YI/5hsLhKbwIafKVenxvpieiS+UbIrNVjCXKfVkr4S97JkCx4CEbs3ZMJTdEXato UfJeVWzvJPv/OaoaU47vZScCe+szJyDLKxrI0Dvyqrru7SE2sGNK6nkPlf3hBEDOt2Pz A7lA==
X-Gm-Message-State: AOAM532LO3ZAXGt/9kV9zeHIDH7KkmkB2XXol5ii6Il82nhaH08hf6Uh c2aIOIhvKjPF0cBEsVJmXniCWKvuZQ7arVUxlGle8Wa0GrU=
X-Google-Smtp-Source: ABdhPJwvyQd3Yxrma5KhoqASaT0MW7AuhpMGH/Yb7qfaOlmxDxTJg9CqdRB69XSQZDJy46/Z2qkadjPy3qivii/EUgQ=
X-Received: by 2002:a1f:1105:: with SMTP id 5mr18879066vkr.17.1608146268753; Wed, 16 Dec 2020 11:17:48 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 16 Dec 2020 11:17:37 -0800
Message-ID: <>
To: "Jakob Heitz (jheitz)" <>
Cc: Claudio Jeker <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000018934405b699bb01"
Archived-At: <>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Dec 2020 19:17:52 -0000

On Wed, Dec 16, 2020 at 10:51 AM Jakob Heitz (jheitz) <jheitz=> wrote:

> The restarting speaker in this case did not actually restart.
> It just restarted this one session. There is no reason for it
> to delete any forwarding state. There is no evidence of any
> problem with its received routes, only with the routes it sent
> to the stuck peer. It may still set the (F) bit to force the
> stuck peer to WITHDRAW.

The transitive nature of bgp pretty much requires the safest choice should
be taken.

Which is to say, there is EVERY reason to delete forwarding state.
If a peer's router is so messed up that it is not accepting any TCP
packets, the only safe assumption is that the problem is AS-wide for that
In which case, the only data point available (the TCP session) indicates
the problem is very likely affecting other routing announcements towards
that ASN.
And the only SAFE behavior is to tear down the session completely,
including removing received routes from the IN-RIB, update the RIB and FIB,
and go on with life.

The incident that I believe lead to this proposal was super nasty, and only
a fix like this could handle that.
There is no reason to believe this can't/won't happen again in future.
As Jared notes, there are likely other implementations that would fare as
poorly if they encountered the triggering situation.

While this is my opinion on the best way to handle it, the underlying facts
aren't arguable.
An AS-wide situation (stuck receivers with no TCP progress) would never
result in the AS sending withdrawals.
The current handling of that is demonstrably broken.
The assumption that the BGP state machine can be fully relied upon is no
longer sound.

It probably never was a completely safe assumption.
IFF the state machine is working correctly, this corner case would never
It has occured and can occur, ergo it needs to be handled outside of the
state machine proper.