Re: [Idr] Debugging accepted routes from BGP speakers

Robert Raszuk <> Tue, 19 November 2019 09:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D95E1208D8 for <>; Tue, 19 Nov 2019 01:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KjQrg6M5j048 for <>; Tue, 19 Nov 2019 01:18:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B5F91200C1 for <>; Tue, 19 Nov 2019 01:18:29 -0800 (PST)
Received: by with SMTP id o3so23799336qtj.8 for <>; Tue, 19 Nov 2019 01:18:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mYhnQm1hFBdBDQVtg/OCrpwqpUdo4UHZRquDDDITOWs=; b=VkDlVAqjv8kkVWlTvNwGMhLh80MlBh7OgJdBpyEhe/vBP78j7Q1FYIwIA9t50s4g2Q HmllAyQW3X/fM36nyArbfPLAc/vWtR9p7qYSQQK+ht8Uhg1/ssO04Nw2lK+DrW+oiKVr Zp3dubqvcxQc3zbUL1gAFc72d0OfnMGAWZNalNhX6i2C7U0D0/pWuwRNv3AKBrKD0z8I 1HvonrviCGNW5VKHQdjYGXxPPQfCgfKbtR0Saqiq7uFiDClzul+qP33S+E8ThiIAJODS JXT+wu0pdSHI419RaLwvseMQtcjk/jgGUDqm9wE+BXfCTqn1VVpNejUPQvyi9dETtK+S Lg1Q==
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=mYhnQm1hFBdBDQVtg/OCrpwqpUdo4UHZRquDDDITOWs=; b=f+ZzRZgiGMfLid0qoq7ifgg7ni6iYnlqiP9VSaodwEY8xZ8kO9G3WHs+7kPLfuXXcQ uyA4UDqhttK/40itg0Yvqb2dQu0p3mDm+fWhIX1C+QBsBYQQ/5DRgKvKq8wVZTu+k/NN BZbsGnMtjHvhxPjmfZ3+fvACFDQ12nJuyM3sYqIuZoeNV4tlfNsMWg5IvFqUF5VTcqnq bOBYwLIeVIOfjM1K7N+1UjJHOf+xdtZch99JFNK3+KNRKdAqO9IS23jjDNRAW9T+Vje1 Jy9J0rRxPWleT+wV6Uyj3hN6hQCULt6Nixvhf1/DKDSr5QRhhCRy3Y11vbIEDBQ60HuU Ch/g==
X-Gm-Message-State: APjAAAXcMhHpIlzKSHwvwvWk8Tk9gQDXi+VIgWLhiF0PrOGk7cxuCtdZ /RbGYHrql7io7xUWDkwc2bl+h7gAT5bojs0ttVGe5g==
X-Google-Smtp-Source: APXvYqy9ZSw8qyD4mqnCRnf1QQGn9k2Pj2O6c5i41uChlGCAJj/xflDOzOWVh2S9n/Pfd4q5EUEmK6GmBy9CzhoW6Ok=
X-Received: by 2002:ac8:721a:: with SMTP id a26mr31449187qtp.208.1574155108263; Tue, 19 Nov 2019 01:18:28 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Tue, 19 Nov 2019 10:18:19 +0100
Message-ID: <>
To: "Jakob Heitz (jheitz)" <>
Cc: Job Snijders <>, IDR <>
Content-Type: multipart/alternative; boundary="0000000000000cbccf0597af8c20"
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 09:18:35 -0000

Hey Jakob,

But this is not what is being asked here.

There is need to validated if routes received on *specific* eBGP session
were accepted by bgp inbound policy.

What you suggesting is also quite useful but IMO 100% orthogonal to the

Reason being that in your scenario router would advertise the best path to
a peer back which may not be local eBGP route. Worse I may have N eBGP
session to a given peer's ASBR and I would like to make sure all of my
paths has passed his policy.

Moreover as Jared said he is not so much concern of overall
reachability validation. He is concerned when his most preferred path goes
down does his peer has backup path(s) to him.

Kind regards,

On Tue, Nov 19, 2019 at 6:19 AM Jakob Heitz (jheitz) <>

> In
> 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.
> 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.
> Regards,
> Jakob.
> -----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,
> Job
> _______________________________________________
> Idr mailing list