IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Wed, 16 December 2020 19:53 UTC

Return-Path: <robert@raszuk.net>
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 B73C93A0E93 for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 11:53:39 -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=raszuk.net
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 ZGd9NVYLleuu for <idr@ietfa.amsl.com>; Wed, 16 Dec 2020 11:53:37 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D823A0E9D for <idr@ietf.org>; Wed, 16 Dec 2020 11:53:37 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id o19so25802393lfo.1 for <idr@ietf.org>; Wed, 16 Dec 2020 11:53:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rf14VQanPy6QoOz2Rn1Dy8S+rccllHvQln10/s6DBDw=; b=WbjgVIic/LDd4t4LmH0qq1D/o11Amp+ZYKC4zuI7Df9K7S6rsqNE2dopLRz1bxX2cw fT61AggKx360QIE57+lTsP3aJZjp5CThmSabFjH62LKDkB8dCWVQNZ4cBw3BgLOnPlt6 XE80aX2Fc7rHN652xWZFyvByKgBmBn/oiCLrbIJbn9n4yVGx33lcw0AYbLX5b0YehYQe eMSlTMfm1n36hNt1O6sryolom91tW3uszzPagpBRsMe0ynGRnb9HJNKxVd4jzgOIAoWi XwHIFVhDjniesC+arWBg/knn76hfJ3S4ysx2DT8YFk/QfjQ76THPxJQII1yPqSaCJ83h mSPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rf14VQanPy6QoOz2Rn1Dy8S+rccllHvQln10/s6DBDw=; b=Go57DDsy8g7BGL9J0eLO2D7ZorQ0zw0vSLlR92XoPs4NHXWVbIPb+xOLEtUzoY0dfC akTDzF+IStP4UrdkXxQ18iBmzMnxWXAUn1Gp9xZ2edd4FCw2DAxdLmQ21Dk5cbbd3Evo R00IxvbuhE+m45t1eS47CtDZRKmIFGxPDij5FkH/r2djq9Rm8gpDr1koQww2HF3UbLuT Wr3Kh0nwC8lE1/DvSCvsdoG6BMV0d1GQfkRwq8klYNTwR5RX4DcNCXX5XoQOsUmTpSM6 SIvmIeuwfhDwnvu6rWAHWrUoRlbhr25XCGG9Gj9kShKUC3P8XqDnAS61z6AP1adlJ0Pp /NFQ==
X-Gm-Message-State: AOAM532yU6wtMzYmS2d8EG8SZ5semobgMRpKKeMimHSQcFl1vd0jo85b 2FyJoJq+p17yUswgM9vBG55A+xgdSyI+ZCNfEX0yAX5l4BA=
X-Google-Smtp-Source: ABdhPJy8Knr18NQ8ZdnWtFvUJVzyXXk//pj/OM0n2lGjRmYciGJwu51fSW/+qaX1H298Bz41yXYHdHcaTKQMeMKk7Qs=
X-Received: by 2002:a19:520e:: with SMTP id m14mr12225738lfb.591.1608148415360; Wed, 16 Dec 2020 11:53:35 -0800 (PST)
MIME-Version: 1.0
References: <22C381D0-2174-4828-A724-FD97B2FE0BCB@tix.at> <9D6268BD-C555-4B9A-A883-9B55EEB5D5DA@juniper.net> <91D9B9F7-0DBE-45E6-84D5-2E3D9F8C44A1@tix.at> <X9kweQ5EtTL7tOAM@bench.sobornost.net> <CAOj+MMFySPXpE8QxcO+7szKzQ78faQASYKnBUYg_h_aLd=P4Lg@mail.gmail.com> <BYAPR11MB3207412804697588E4AA3F03C0C60@BYAPR11MB3207.namprd11.prod.outlook.com> <20201216093614.GI68083@diehard.n-r-g.com> <4E9BEA12-998A-4AD1-B342-4F26AA6EBA69@cisco.com> <20201216174319.GM68083@diehard.n-r-g.com> <BYAPR11MB320759EE6ABC8AB863BC1838C0C50@BYAPR11MB3207.namprd11.prod.outlook.com> <X9phnLQWPIVrcjwo@bench.sobornost.net>
In-Reply-To: <X9phnLQWPIVrcjwo@bench.sobornost.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 16 Dec 2020 20:53:25 +0100
Message-ID: <CAOj+MMEpL9BBOL8K9k0W-x3qvOqk+KGXdnchR9zAL-93gs480A@mail.gmail.com>
To: Job Snijders <job@sobornost.net>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000b45e905b69a3b38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KPSaZEKwIgXFhHI6af_zlbwmdTs>
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: Wed, 16 Dec 2020 19:53:40 -0000

Job,

I think your observations may not always apply.

Imagine you are peering with a stub customer and he is only getting default
route from you while advertising few routes to your ASN.

The fact that you can not send to him for some time BGP UPDATES is normal
here. Queuing BGP KEEPALIVE messages could indicate some issue with the
peer's control plane, but his data plane may be running just fine.

So you want to cut his edge router off the Internet in this case ? I would
think we should be very careful not to break in any way data plane
especially when GR is in effect.

At min make before break (new session should be established - if possible)
before killing the old one.

/* I think while most implementations do not enforce the same BGP ID check
at eBGP OPEN there is something in the specs which at least originally
mandated it. */

Thx,
R.




On Wed, Dec 16, 2020 at 8:39 PM Job Snijders <job@sobornost.net> wrote:

> Jumping in to pick a nit about perceived asymmetry and practical
> reality.
>
> On Wed, Dec 16, 2020 at 06:50:51PM +0000, Jakob Heitz (jheitz) wrote:
> > There is no evidence of any problem with its received routes, only
> > with the routes it sent to the stuck peer.
>
> * The routes received from the stuck peer might block a healthier route
> from being used
>
> * The routes to be sent towards the stuck peer might contain routing
> information for healthier routes for destinations the stuck peer is
> advertising.
>
> Both the local node and the stuck peer are operating on stale routing
> information. Even though the signalling observably is stuck in 'only
> one' direction, the staleness applies to both directions because BGP
> nodes converge together: a problem in 1 direction is a problem for both
> directions, for both nodes.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email