Re: [Idr] Debugging accepted routes from BGP speakers

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 19 November 2019 18:29 UTC

Return-Path: <jheitz@cisco.com>
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 509911201DE for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 10:29:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WhRGJ3ye; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jxOk7rK3
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 289PKtMct48h for <idr@ietfa.amsl.com>; Tue, 19 Nov 2019 10:29:43 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA941200D7 for <idr@ietf.org>; Tue, 19 Nov 2019 10:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22740; q=dns/txt; s=iport; t=1574188183; x=1575397783; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rgvW3ascOPbCpPNIua8ahCPYvfxpCEXb8RvLC9uiCk0=; b=WhRGJ3yedmkIgKP+cenIegoSi3OB6mTYaScO7cInSi7oSJqt3B3mfBPF PFwx8XboJCOWu5nRTw7p7LinHo8vHJKGhndyPw0kpICukjhtwpWDwrj0b r8OctzmHAw4yeJrsR3P8A0lRSWdd1FhAUE3yprScTzt+FMWx/JKgFthJc 4=;
IronPort-PHdr: 9a23:umTFABdAhIzzcpx5CFD99EVSlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwKYD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/bSw3HdhQfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAAAxM9Rd/4oNJK1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFrBAEBAQELAYEbL1AFbFggBAsqCoQgg0YDinWCXn+SH4RigS6BJANUCQEBAQwBARgBCgoCAQGEQAIXgg4kNQgOAgMNAQEEAQEBAgEFBG2FNwyFUQEBAQECAQEBEBEKEwEBJQcLAQQHBAIBCBEEAQEBJwMCAgIlCxQJCAIEDgUIDAcHgwGBeU0DDiABDqYrAoE4iGB1gTKCfgEBBYUIGIIXAwaBNgGMFBiBQD+BEUaCFwcuPoJiAQECAYEaLhgrCYJaMoIskBOFR4lGjw0KgiuHGoVbiHWCPowiizGXAI1wg2ACBAIEBQIOAQEFgVQDNIFYcBU7gmxQERSRGgwXg1CFFIU+AXQBAYEmi1MrgQQBgQ4BAQ
X-IronPort-AV: E=Sophos;i="5.69,218,1571702400"; d="scan'208,217";a="661423837"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2019 18:29:42 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id xAJITgOV002633 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Nov 2019 18:29:42 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 12:29:41 -0600
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 12:29:40 -0600
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Nov 2019 13:29:40 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2MzFF0Lv3BxpGdGBQZVahwrhAF645lW2NOBHyjFvJ5rTXNyqOv3qU/hJlaLu5+IXEfKK3daSXRt8ioPL5HiRkWoNmYDGAPgIskR0HVOfRtB+bsAbjg0e41PcruXw+6YxT3Du6UhPrpPAa7/WKG9gnWPANP5+Y3ZcKZVIDH7UdyChJNQ266562J/8+TExza88JOLfZ+UMTxW+/luAganBnhJRP9yYgh3fzE/XD/l8+jM5zeh3kXyf6Z2yiXAXalekhGa01aRZ7337UE8CpIyPTjErj+lGHEy21o6DNT3BUzjSqlafHiy4pOncerippC/27bUY8vY8GO3BV3O/oeFcQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rgvW3ascOPbCpPNIua8ahCPYvfxpCEXb8RvLC9uiCk0=; b=oSxTdUbmzmd2g/OctPuzN2/MCiH7VL3dgpK66FFYAqzzkrNWfzOT0IHaPEqxpgf4usvuwcAfU98h3nRyyLKXDEkcuGko0+LW/M6D/glThvVEkAcpH8aAcZJaHNFGmcZivZw88Ws3pRcefg2ZMPRLL2R3Wuww5urRNL8gINEQfuYX8V59eHw6JBNtVkKZpx047MhwZjbVlCBwBX7Jqor+vCyVoem3tF/BnpCjvIdihm1XqJRdw+WycT3pnAVzAomIa4igY5Gbza0vInQ8kbw56aFJwVhcYFRQFfj8pASU1eNMfjb2SNAOjYM2M0hbqHIOYderzl224okcUNbaKgpz4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rgvW3ascOPbCpPNIua8ahCPYvfxpCEXb8RvLC9uiCk0=; b=jxOk7rK3EIe9niHNRK6sV/EiQSAHo/NQokDfbUUMY3XCDFSFcg5vVXNRAVktdJe1cJqfWQVqOJHWsVJeZ2qKvDRb9fDllGI/HpTpYIpSsQIrO2/h2/k329JzvU4RQp0MlFo4xdnkK1+6c/X+naVRrUz0pah/BS/wdo7jvPWIBco=
Received: from MWHPR11MB1807.namprd11.prod.outlook.com (10.175.55.20) by MWHPR11MB1440.namprd11.prod.outlook.com (10.172.51.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Tue, 19 Nov 2019 18:29:39 +0000
Received: from MWHPR11MB1807.namprd11.prod.outlook.com ([fe80::25d5:4add:6529:e045]) by MWHPR11MB1807.namprd11.prod.outlook.com ([fe80::25d5:4add:6529:e045%9]) with mapi id 15.20.2451.031; Tue, 19 Nov 2019 18:29:39 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: Job Snijders <job@instituut.net>, IDR <idr@ietf.org>
Thread-Topic: [Idr] Debugging accepted routes from BGP speakers
Thread-Index: AQHVne379bMcnHYhXU2mTv1VngxCUKeQqTKAgAADHQCAAAMHAIAAE4uAgAEtxeCAAEgOgIAAliWg
Date: Tue, 19 Nov 2019 18:29:39 +0000
Message-ID: <MWHPR11MB1807746910ACB5CE536014CCC04C0@MWHPR11MB1807.namprd11.prod.outlook.com>
References: <157406668522.14183.13795160095173591028.idtracker@ietfa.amsl.com> <EC0AF47A-D6F3-4903-A597-C0F18520A8B0@puck.nether.net> <CAOj+MMGOT4jyAaaiQ6PngdNFSGx3BrmS6wU+-Pg1Oow16wRYZA@mail.gmail.com> <CACWOCC8yD+fWaSeTkHd+UubzfnxgBbbFXCeuRuzVcmK6VQqKew@mail.gmail.com> <CAOj+MMETtqBw5cRLna=eSVa5ezXeR=NjeT_q5JQVhAyVruziTw@mail.gmail.com> <CACWOCC-8yPsr8qXMD2cUTjkKEc1cnTG+6vA1tfQtQ6n248rrJA@mail.gmail.com> <MWHPR11MB18075F3AD772326EE90E39A0C04C0@MWHPR11MB1807.namprd11.prod.outlook.com> <CAOj+MMGFW63-ks04fiL2gQLuajM0oicveCabH5=D-z1Gqy0XmQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGFW63-ks04fiL2gQLuajM0oicveCabH5=D-z1Gqy0XmQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com;
x-originating-ip: [128.107.241.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bc77813f-7015-49f1-1e6a-08d76d1e7061
x-ms-traffictypediagnostic: MWHPR11MB1440:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MWHPR11MB144079D7A016D7FD52C2707BC04C0@MWHPR11MB1440.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(346002)(396003)(39860400002)(199004)(189003)(13464003)(64756008)(52536014)(256004)(7696005)(86362001)(14444005)(236005)(54896002)(76176011)(74316002)(7736002)(54906003)(316002)(9686003)(6306002)(71200400001)(71190400001)(55016002)(476003)(6916009)(76116006)(4326008)(99286004)(66574012)(486006)(25786009)(5660300002)(606006)(11346002)(6116002)(3846002)(790700001)(446003)(478600001)(6246003)(14454004)(966005)(102836004)(33656002)(81156014)(81166006)(6436002)(26005)(8676002)(66066001)(186003)(53546011)(66946007)(66476007)(8936002)(66556008)(2906002)(229853002)(66446008)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1440; H:MWHPR11MB1807.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 2+jYM71Ca7vEOVm08Gme9zR+5sl86Q/bL3iVwfdwjBMEkvbggj8v5O7Ppy9SNCwpwDKu//GhOzLM9y/sD2rS8jcMmOcyZg7xx7hUckdEnhBZKK3JOvFuxLYeWV0a6O1aS6BEuA5EzZVs7gfxJ3OTg2g8rbSz2v0/emVRTVaYxnsDAgR5HaUcpEmDliRXOLGPgRG9hu2s/y+j488X789mqrCnc2A+d88OYDgHFdi4QiftvodLS5/nctZA3OCtSwePKjlyxGchcQ0Avl1AzGujgohFDVsEiVnEMKdFnkNkMbnHkxgqDyTDJ3WqgUxbV1lDQMKWOzs3Fm0Ue2uygrY80qngw6VJGbUI1QQm6Y0Ah9mJwWIQ/CrsSOG+sDJMWSgZwhDDaYt5gktgcST42q68XHnUIcoEzm4UFOxMhGIZLRnk605o0aM4/aLRX4BV/daVkzwwiKW0SE0t4PuIajDVaYMikhbejih3c5izFKwfvdY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1807746910ACB5CE536014CCC04C0MWHPR11MB1807namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bc77813f-7015-49f1-1e6a-08d76d1e7061
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 18:29:39.6044 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: we5L8NfBnzcKpjiYzOBEZDBEJvZRDjRnja6xcVUTd7OlOEbZ4+q97PH9DKkWZOEPgYpYva3y7Jk37hq5VHgixQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1440
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Aql1UdhUUQTB66zFpnvM1O6JtxQ>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers
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: Tue, 19 Nov 2019 18:29:46 -0000

Robert,

You are right about the echoed path being a different path.
I forgot that ebgp does next-hop-self, so the receiver of the
echo cannot be sure it is his own echo.

Easy fixed. Do next-hop-unchanged on an echo path.

Another fix would be to add a community.
However, that would be harder to implement.
Ease of implementation is important if you want your
feature implemented.

The draft mentions nothing about backup.
I do remember some years ago, Ignas asked for this kind of feedback,
so he could know whether he should install a backup on the sender end.
Suppose R1 sends a route to R2. If R2 accepts the route,
R1 would like to install a backup in its FIB. Since FIB space
is precious, R1 does not want to install a backup if R2 does not
use R1's route.

Regards,
Jakob.

From: Robert Raszuk <robert@raszuk.net>
Sent: Tuesday, November 19, 2019 1:18 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Job Snijders <job@instituut.net>; IDR <idr@ietf.org>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers

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 topic.

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,
R.

On Tue, Nov 19, 2019 at 6:19 AM Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:
In https://tools.ietf.org/html/rfc4271#section-9.1.2
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 <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Job Snijders
Sent: Monday, November 18, 2019 3:00 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: IDR <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] Debugging accepted routes from BGP speakers

On Mon, Nov 18, 2019 at 9:50 AM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> 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
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr