Re: BGP noise tonight? (fwd)
So who do you blame...the RFC or the vendor that ignores it? Dropping the session seems to break the "be conservative in what you send and liberal in what you accept" suggestion. If you know someone else will ignore the rules (there's always someone) breaking due to their error kind of sucks. -- ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ ---------- Forwarded message ---------- Return-Path: <if@sil.at> Received: from mailhost.mmaero.com (mailhost.mmaero.com [208.152.224.3]) by redhat1.mmaero.com (8.11.6/8.9.3) with ESMTP id f984S0Z24869 for <jlewis@redhat1.mmaero.com>; Mon, 8 Oct 2001 00:28:00 -0400 Received: from waste.silverserver.co.at (waste.silverserver.co.at [194.152.178.7]) by mailhost.mmaero.com (8.11.2/8.11.2) with ESMTP id f984Rxp20147 for <jlewis@lewis.org>; Mon, 8 Oct 2001 00:28:00 -0400 Received: from ikarus (ikarus.sil.at [194.152.178.41]) by waste.silverserver.co.at (8.11.6/8.11.6) with ESMTP id f984Roi31471 for <jlewis@lewis.org>; Mon, 8 Oct 2001 06:27:50 +0200 Date: Mon, 8 Oct 2001 06:27:51 +0200 (MEST) From: Ingo Flaschberger <if@sil.at> X-Sender: chaoztc@ikarus To: jlewis@lewis.org Subject: Re: BGP noise tonight? In-Reply-To: <Pine.LNX.4.30.0110080010050.1854-100000@redhat1.mmaero.com> Message-ID: <Pine.SOL.4.21.0110080627120.15412-100000@ikarus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi i could not post to nanog directly.. perhaps you could do it for me? our 2 uplinks, ebone and carrier1 went down (flapping routes at the borders). the problem was a malformed as-path (with a private confederation in it), which was distributed from netherland over the network... (over routers VendorX). rfc-compliant routers dropped the peering session after receiving this malformed route ebone has contaced the provider and he has already fixed this announcement. thnx & bye, Ingo -- "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin
So who do you blame...the RFC or the vendor that ignores it? Dropping the session seems to break the "be conservative in what you send and liberal in what you accept" suggestion. If you know someone else will ignore the rules (there's always someone) breaking due to their error kind of sucks.
is there a proof of termination of this path?
All prefixes originating from AS2008 dissapeared from our feeds at approx. 9:30pm EDT. About an hour later, I noticed that the prefixes were back, but no longer carrying the malformed path. -Chris On Mon, Oct 08, 2001 at 12:52:18AM -0700, Randy Bush wrote:
So who do you blame...the RFC or the vendor that ignores it? Dropping the session seems to break the "be conservative in what you send and liberal in what you accept" suggestion. If you know someone else will ignore the rules (there's always someone) breaking due to their error kind of sucks.
is there a proof of termination of this path?
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
Did a lot of folks get affected by this? Any news on what caused the bogus path? Anyone have contacts at 2008? (transit ASes deleted) ?3?64603? 2008 -abha ;) (an inquiring mind who wants to know... *grin*) On Mon, 8 Oct 2001, Christopher A. Woodfield wrote:
All prefixes originating from AS2008 dissapeared from our feeds at approx. 9:30pm EDT. About an hour later, I noticed that the prefixes were back, but no longer carrying the malformed path.
-Chris
On Mon, Oct 08, 2001 at 12:52:18AM -0700, Randy Bush wrote:
So who do you blame...the RFC or the vendor that ignores it? Dropping the session seems to break the "be conservative in what you send and liberal in what you accept" suggestion. If you know someone else will ignore the rules (there's always someone) breaking due to their error kind of sucks.
is there a proof of termination of this path?
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com
PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On Mon, 8 Oct 2001, abha wrote:
Did a lot of folks get affected by this? Any news on what caused the bogus path?
Anyone have contacts at 2008?
(transit ASes deleted) ?3?64603? 2008
-abha ;) (an inquiring mind who wants to know... *grin*)
AS3 is MIT what is the relevance to this problem ? AS64603 is in "reserved"(private) AS space ( 64512 - 65535 ) IMHO could be an internal confederation leaking - any better ideas ? - Rafi
the problem path was not 3, it was '3300 (64603) 2008'. I'm presuming that the leaking conferation was within AS3300's network. aut-num: AS3300 as-name: AUCS descr: AUCS Communications Services v.o.f. descr: aka Infonet-Europe descr: The Netherlands -Chris On Tue, Oct 09, 2001 at 06:02:26PM +0200, Rafi Sadowsky wrote:
On Mon, 8 Oct 2001, abha wrote:
Did a lot of folks get affected by this? Any news on what caused the bogus path?
Anyone have contacts at 2008?
(transit ASes deleted) ?3?64603? 2008
-abha ;) (an inquiring mind who wants to know... *grin*)
AS3 is MIT what is the relevance to this problem ?
AS64603 is in "reserved"(private) AS space ( 64512 - 65535 ) IMHO could be an internal confederation leaking - any better ideas ?
- Rafi
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
As it turns out, both 2008 and 3300 are Infonet, US and Europe. So this was their foo. The problem is obviously that the RFC-proscribed behavior with bad prefixes works on paper, as it serves to isolate the network originating the problem prefix. However, that is totally dependent on /every/ router doing so, thus preventing the problem from spreading, which as we discovered, does not happen. The ideal alternative behavior is to drop the bad prefix--not dropping the peer, but not passing the bad prefix along either. I've been told that there are recent Cisco IOS revs that do this instead of passing it along, but they have other unresolved bugs that prevent their widespread use. Should someone think about possibly updating the RFC? -Chris On Tue, Oct 09, 2001 at 12:12:24PM -0400, Christopher A. Woodfield wrote:
the problem path was not 3, it was '3300 (64603) 2008'. I'm presuming that the leaking conferation was within AS3300's network.
aut-num: AS3300 as-name: AUCS descr: AUCS Communications Services v.o.f. descr: aka Infonet-Europe descr: The Netherlands
-Chris
On Tue, Oct 09, 2001 at 06:02:26PM +0200, Rafi Sadowsky wrote:
On Mon, 8 Oct 2001, abha wrote:
Did a lot of folks get affected by this? Any news on what caused the bogus path?
Anyone have contacts at 2008?
(transit ASes deleted) ?3?64603? 2008
-abha ;) (an inquiring mind who wants to know... *grin*)
AS3 is MIT what is the relevance to this problem ?
AS64603 is in "reserved"(private) AS space ( 64512 - 65535 ) IMHO could be an internal confederation leaking - any better ideas ?
- Rafi
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com
PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
On Tue, Oct 09, 2001 at 12:27:55PM -0400, Christopher A. Woodfield wrote:
As it turns out, both 2008 and 3300 are Infonet, US and Europe. So this was their foo.
The problem is obviously that the RFC-proscribed behavior with bad prefixes works on paper, as it serves to isolate the network originating the problem prefix. However, that is totally dependent on /every/ router doing so, thus preventing the problem from spreading, which as we discovered, does not happen.
The ideal alternative behavior is to drop the bad prefix--not dropping the peer, but not passing the bad prefix along either. I've been told that there are recent Cisco IOS revs that do this instead of passing it along, but they have other unresolved bugs that prevent their widespread use.
Should someone think about possibly updating the RFC?
you are stuck in the situation that operators are faced in deciding what software to run on their network. if the internet-draft is updated you still need vendors to change their behavior and people to upgrade. - jared
On Tue, 9 Oct 2001, Jared Mauch wrote:
Should someone think about possibly updating the RFC?
you are stuck in the situation that operators are faced in deciding what software to run on their network. if the internet-draft is updated you still need vendors to change their behavior and people to upgrade.
I agree, it is only one step on a long road. But you have to take the first step, if nothing else, so when a "new" vendor releases a product it won't include the old behavior. Or at least, an officially revised RFC gives customers another stick to beat their vendor.
Exactly - if the RFC is updated, there's no ambiguity re: how to design new BGP software. At this point, the RFC says to do what was at one time considered to be the right thing, which was demonstrated most recently on Sunday night to be exactly the wrong thing. Thus, the RFC should be updated to account for what has been determined the "new" right way of handling malformed prefixes. As a precedent, refer to the change in attitudes in the RFCs towards open SMTP relaying - five years ago it was SOP, today it'll get you blackholed. -Chris On Tue, Oct 09, 2001 at 01:30:34PM -0400, Sean Donelan wrote:
On Tue, 9 Oct 2001, Jared Mauch wrote:
Should someone think about possibly updating the RFC?
you are stuck in the situation that operators are faced in deciding what software to run on their network. if the internet-draft is updated you still need vendors to change their behavior and people to upgrade.
I agree, it is only one step on a long road. But you have to take the first step, if nothing else, so when a "new" vendor releases a product it won't include the old behavior. Or at least, an officially revised RFC gives customers another stick to beat their vendor.
-- --------------------------- Christopher A. Woodfield rekoil@semihuman.com PGP Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB887618B
I agree, it is only one step on a long road. But you have to take the first step, if nothing else, so when a "new" vendor releases a product it won't include the old behavior. Or at least, an officially revised RFC gives customers another stick to beat their vendor.
but we have the stick now. unfortunately, we also have a vendor who ignores sticks. so adding different or more sticks may not be the way to go. randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have found our stick was effective with our vendor, given enough beatings. Regards, Matt - -- Matt Levine @Home: matt@deliver3.com @Work: matt@eldosales.com ICQ : 17080004 PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." - -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Randy Bush Sent: Tuesday, October 09, 2001 11:47 AM To: Sean Donelan Cc: nanog@merit.edu Subject: Re: BGP noise tonight? (fwd)
I agree, it is only one step on a long road. But you have to take the first step, if nothing else, so when a "new" vendor releases a product it won't include the old behavior. Or at least, an officially revised RFC gives customers another stick to beat their vendor.
but we have the stick now. unfortunately, we also have a vendor who ignores sticks. so adding different or more sticks may not be the way to go. randy -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBO8NHrcp0j1NsDQTPEQJLDwCfQBus6S0ZrGFM77NnpyzbxrmBuHQAoMnx Fu0t89wOWFNODHlgDo2vi4fA =Mqmb -----END PGP SIGNATURE-----
At 11:55 AM 10/9/2001 -0700, Matt Levine wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have found our stick was effective with our vendor, given enough beatings.
Regards, Matt - -- Matt Levine @Home: matt@deliver3.com @Work: matt@eldosales.com ICQ : 17080004 PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was."
Matt, I LOVE your sig. Is that your quote? or did someone else say it first? "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "It is never too late to be what you might have been." -George Eliot
I am an idiot. Sorry for cc'ing the list. My fingers were faster than my brain (and eyes). -Robert At 06:38 PM 10/9/2001 -0400, Robert Boyle wrote:
At 11:55 AM 10/9/2001 -0700, Matt Levine wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
We have found our stick was effective with our vendor, given enough beatings.
Regards, Matt - -- Matt Levine @Home: matt@deliver3.com @Work: matt@eldosales.com ICQ : 17080004 PGP : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was."
Matt,
I LOVE your sig. Is that your quote? or did someone else say it first?
"The Trouble with doing anything right the first time is that nobody appreciates how difficult it was."
-Robert
Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "It is never too late to be what you might have been." -George Eliot
On Tue, Oct 09, 2001 at 12:27:55PM -0400, Christopher A. Woodfield wrote:
As it turns out, both 2008 and 3300 are Infonet, US and Europe. So this was their foo.
The problem is obviously that the RFC-proscribed behavior with bad prefixes works on paper, as it serves to isolate the network originating the problem prefix. However, that is totally dependent on /every/ router doing so, thus preventing the problem from spreading, which as we discovered, does not happen.
The ideal alternative behavior is to drop the bad prefix--not dropping the peer, but not passing the bad prefix along either. I've been told that there are recent Cisco IOS revs that do this instead of passing it along, but they have other unresolved bugs that prevent their widespread use.
Should someone think about possibly updating the RFC?
It's already written. However, the general impression a month and a half ago was that it wasn't likely to go anywhere. Since I'm not really up to trying to make headway in the relevant groups, anyone who *does* feel like it and wants to see the proposal should feel welcome to contact me off-list about it. It's really a fairly obvious set of extensions (and can, in fact, be done with only extensions). -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
participants (10)
-
abha -
Christopher A. Woodfield -
Jared Mauch -
jlewis＠lewis.org -
Joel Baker -
Matt Levine -
Rafi Sadowsky -
Randy Bush -
Robert Boyle -
Sean Donelan