[129138] in North American Network Operators' Group
Re: Did your BGP crash today?
daemon@ATHENA.MIT.EDU (Clay Fiske)
Fri Aug 27 16:43:57 2010
From: Clay Fiske <clay@bloomcounty.org>
In-Reply-To: <20100827191324.GJ1946@gerbil.cluepon.net>
Date: Fri, 27 Aug 2010 13:43:39 -0700
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Aug 27, 2010, at 12:13 PM, Richard A Steenbergen wrote:
>=20
> Just out of curiosity, at what point will we as operators rise up=20
> against the ivory tower protocol designers at the IETF and demand that=20=
> they add a mechanism to not bring down the entire BGP session because =
of=20
> a single malformed attribute? Did I miss the memo about the meeting?=20=
> I'll bring the punch and pie.
About the same time vendors' BGP implementations start to work =
correctly?
I agree such a knob would be useful, but seems to me that actually =
following the current standard would largely curb the issue by itself.
I recall one of the previous times something like this happened (and =
with a much wider impact), I believe it was $C that was accepting a bad =
attribute and passing it along. The effect was that other vendors ($F in =
particular, I think) would drop the session (per RFC), which made it =
look like they were the broken ones. Instead of saying "why was this =
accepted from its source?" the community reaction seemed more to me to =
be "hey, BGP is breaking the internet!"
If -everyone- dropped the session on a bad attribute, it likely wouldn't =
make it far enough into the wild to cause these problems in the first =
place.
-c
