Re: [Idr] Debugging accepted routes from BGP speakers

Zhuangshunwan <> Tue, 19 November 2019 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 929A712080F for <>; Mon, 18 Nov 2019 21:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f-9U0RioGgcJ for <>; Mon, 18 Nov 2019 21:58:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A34C4120046 for <>; Mon, 18 Nov 2019 21:58:08 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 94F115C1FEA5047242B2 for <>; Tue, 19 Nov 2019 05:58:04 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Nov 2019 05:58:04 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 19 Nov 2019 05:58:04 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 19 Nov 2019 05:58:03 +0000
Received: from ([fe80::a54a:89d2:c471:ff]) by ([]) with mapi id 14.03.0439.000; Tue, 19 Nov 2019 13:57:51 +0800
From: Zhuangshunwan <>
To: "Jakob Heitz (jheitz)" <>, Job Snijders <>, Robert Raszuk <>
CC: IDR <>
Thread-Topic: [Idr] Debugging accepted routes from BGP speakers
Date: Tue, 19 Nov 2019 05:57:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers
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: Tue, 19 Nov 2019 05:58:16 -0000

[inline] with [Shunwan].


-----Original Message-----
From: Idr [] On Behalf Of Jakob Heitz (jheitz)
Sent: Tuesday, November 19, 2019 1:19 PM
To: Job Snijders <>et>; Robert Raszuk <>
Cc: IDR <>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers

the AS loop is broken at the receiver.
Nowhere does it say that the sender must break the AS loop.
Split horizon filtering is a common practice, but nowhere is it mandated. At least I could not find it.
[Shunwan] When we figure out how to Enhanced AS Loop Detection for BGP (, we also notice the different behaviors between different Network OSes and cannot find which rfc has documented it.

If the receiver of your route were to send you back its best path, even if it's your route, then you have your information.

We could invent an address-family specific capability to indicate that you wish your route to be echoed back.
[Shunwan] I think this is a good idea.


-----Original Message-----
From: Idr <> On Behalf Of Job Snijders
Sent: Monday, November 18, 2019 3:00 AM
To: Robert Raszuk <>
Cc: IDR <>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers

On Mon, Nov 18, 2019 at 9:50 AM Robert Raszuk <> wrote:
> > The latter one is oftentimes easily validated by Internet-wide 
> > looking glasses
> Hmmmm I must say that IMHO both latter and former could be addressed by looking-glass. In fact when I read this draft that was my first question - why not to just look at peer's looking glass ?

Many networks unfortunately do not make BGP Looking Glasses available, nor is there any standardized interface/method/design/approach for BGP Looking Glasses. So solely relying on Looking Glasses for this functionality has proven to be insufficient.

> So perhaps we should simply issue a BCP to say that each AS should run 
> a looking glass server holding all paths and declare victory ? And 
> that could be all GROW WG thing too :)

That is an interesting idea, but in my mind not the exclusive viable solution.

> I already see a bunch of new things we could accomplish in the Internet if we would have those in place consistently everywhere - at least for each transit AS.

Agreed - it would be a nicer world. Through the MANRS initiative I've pitched the idea to provide more encouragement for networks to provide looking glasses to the public, but arguably their availability is not ubiquitous.

Another observation is that in the "IP Transit Carrier" segment of the market we see BGP Looking Glasses from time to time, but we rarely see similar functionality offered by Cloud/CDN providers. Perhaps the latter category is not interested in running & maintaining looking glasses, or perhaps there are other constraints that prevent them from exposing this information via suchs tools. My hope is that by creating a feedback mechanism in BGP we create more opportunity to share debugging information specific to EBGP sessions between different orgs.

Kind regards,


Idr mailing list

Idr mailing list