Re: [Idr] Debugging accepted routes from BGP speakers
Robert Raszuk <robert@raszuk.net> Mon, 18 November 2019 09:28 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 CF0891201DB for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 U-5hg7z37Dek for <idr@ietfa.amsl.com>; Mon, 18 Nov 2019 01:28:37 -0800 (PST)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 CB02E12004F for <idr@ietf.org>; Mon, 18 Nov 2019 01:28:36 -0800 (PST)
Received: by mail-qk1-x72c.google.com with SMTP id m16so13754472qki.11 for <idr@ietf.org>; Mon, 18 Nov 2019 01:28: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=zMJ4wKFcAHguRV3EfboaDKdC+GsMp+d6lGV8xh+OMKU=; b=bvRbEH/Rdki1nLCSUF+HYSwVSPTA5rlOEDlR3xKX7JMH5sxoOwrMZpDxbECW0WHpCQ 4h50/2WWfs/95cMWUrT/498ILSMNMdQ5ihgZ9FeP4V7EKWxyUbFirIlrYRncSbAmLkj4 GJsT0hIHnhcOjs2D3Tp13b7cTWak28FaRvtJPnFWiU6DUirZ0ZiXsNf8Uwmfbs8JVzMJ /vySTFLML+QyUZDEOlQi73yl4Qo9m1saHEdYC9f0ef6vB+2VOixQUXtGGzPzdZHrCdfr nIsiY7iS+NG65xqgoe+Bca4386i3VuI9cVJM+ZRAWulVcojgQIogzMK/UREmDfKPoU/t YAmg==
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=zMJ4wKFcAHguRV3EfboaDKdC+GsMp+d6lGV8xh+OMKU=; b=RaqepA7lCJPrwiEuAaBJ004prTpgy4bEE/TfPWX1ZU+0hw+A/N+cX91CMA/qOLe6C5 VCETrUgcjhgn1UohvAO3iTq6ah46C6B/jMaqh190L5g7aZ9gXah0sZ7fnrdmoNxbn9aD 4kwNByF3H9pN8x/ht2R4lywBk+KJwfb+QyyUwvcII2rKBQxEb1XjnXem/KJSF43+yaai Y/G70JTddUa8ldOa26KPvp5+8cQM/RveRtLsM6tO5dVrClH95QCU1BfOW6iMtLUhk/+T WX39k1wGbBa1POwkj8/eFCtKY1ZHWZnL+214TuWJ1bsy9OjMq/aB/Euk+cn3qbYHUWHn nM9A==
X-Gm-Message-State: APjAAAVfsHNKEFUfI0Ee9mcIMt6M0m4BOHSgDyQ0eG14O3TQrjgyhklo 80AENrI2v3dIC1V1fKvlDIqw04Yx+x7lQU8xBUL5TA==
X-Google-Smtp-Source: APXvYqwnxg6QXTc5+r/zNYUWMqmYEWWD0f2dWhc8J/xQJw3pJQ2ckLsYLKmuEKfLEKDh8wh5aRZYHuBCnTkdq9CKrR0=
X-Received: by 2002:a05:620a:628:: with SMTP id 8mr23193735qkv.465.1574069314960; Mon, 18 Nov 2019 01:28:34 -0800 (PST)
MIME-Version: 1.0
References: <157406668522.14183.13795160095173591028.idtracker@ietfa.amsl.com> <EC0AF47A-D6F3-4903-A597-C0F18520A8B0@puck.nether.net>
In-Reply-To: <EC0AF47A-D6F3-4903-A597-C0F18520A8B0@puck.nether.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 18 Nov 2019 10:28:25 +0100
Message-ID: <CAOj+MMGOT4jyAaaiQ6PngdNFSGx3BrmS6wU+-Pg1Oow16wRYZA@mail.gmail.com>
To: Jared Mauch <jared@puck.nether.net>
Cc: IDR <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ed3bb05979b9275"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/87R7BUtJzqSwnUP1kAEuXfKJbTg>
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: Mon, 18 Nov 2019 09:28:39 -0000
Hi Jared, As you know what you are asking for has been covered by previous work and even IDR WG document: https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 So as you are defining new BGP message anyway I take there are two options: *A* You think that what we specified in operational message is too much *B* You think that we will never need more information to be exchanged in an informational manner between eBGP peers If *A* would you think that clearly making all of those "additional information" as optional would fix the problem and we could proceed with the IDR WG draft in terms of asking for implementation ? As to your document - few questions/observations: * new message likely will require new capability. * "Unknown IANA Considerations" is a new one :) * How much does it help to know that peer's ASBR accepted your prefix but it got filtered on egress of peering AS ? * What is the definition of rejected ? Dropped by policy ? Not eligible for best path ? Not inserted into RIB as better AD is there ? Marked badly by origin validation ? Thx, Robert. On Mon, Nov 18, 2019 at 9:54 AM Jared Mauch <jared@puck.nether.net> wrote: > Greetings, > > As a network operator we often don’t know if our ISPs are accepting the > routes we send to them. This makes it difficult at times for operators to > debug things. This is a first stab at a draft to try and propose a method > to have the remote device echo back some route counts (and possibly NLRI) > that were both accepted and rejected by the remote speaker. > > It’s got a few things that I know need to be fixed at minimum, but I > wanted to share this more broadly now. > > I’m interested in feedback and ready to accept your arrows. > > - Jared > > > URL: > https://www.ietf.org/internet-drafts/draft-mauch-bgp-accepted-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-mauch-bgp-accepted/ > > Htmlized: https://tools.ietf.org/html/draft-mauch-bgp-accepted-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mauch-bgp-accepted > > > > Abstract: > > This document defines a method to receive accepted and rejected NLRI > > over a BGP peering session. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >
- [Idr] Debugging accepted routes from BGP speakers Jared Mauch
- Re: [Idr] Debugging accepted routes from BGP spea… Robert Raszuk
- Re: [Idr] Debugging accepted routes from BGP spea… Job Snijders
- Re: [Idr] Debugging accepted routes from BGP spea… Jared Mauch
- Re: [Idr] Debugging accepted routes from BGP spea… Robert Raszuk
- Re: [Idr] Debugging accepted routes from BGP spea… Jared Mauch
- Re: [Idr] Debugging accepted routes from BGP spea… Job Snijders
- Re: [Idr] Debugging accepted routes from BGP spea… Jakob Heitz (jheitz)
- Re: [Idr] Debugging accepted routes from BGP spea… Jeff Tantsura
- Re: [Idr] Debugging accepted routes from BGP spea… Zhuangshunwan
- Re: [Idr] Debugging accepted routes from BGP spea… Robert Raszuk
- Re: [Idr] Debugging accepted routes from BGP spea… Jakob Heitz (jheitz)
- Re: [Idr] Debugging accepted routes from BGP spea… Robert Raszuk
- Re: [Idr] Debugging accepted routes from BGP spea… Jeffrey Haas