[129170] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Did your BGP crash today?

daemon@ATHENA.MIT.EDU (Florian Weimer)
Sat Aug 28 06:14:50 2010

From: Florian Weimer <fw@deneb.enyo.de>
To: Christopher Morrow <morrowc.lists@gmail.com>
Date: Sat, 28 Aug 2010 12:14:38 +0200
In-Reply-To: <AANLkTinbaTXkAWpeeOutHzrpOE+9Hrv-ZFDxkfQzoOpN@mail.gmail.com>
	(Christopher Morrow's message of "Fri, 27 Aug 2010 16:11:32 -0400")
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

* Christopher Morrow:

> (you are asking your vendors to run full bit sweeps of each protocol
> in a regimented manner checking for all possible edge cases and
> properly handling them, right?)

The real issue is that both spec and current practice say you need to
drop the session as soon as you encounter any unexpected data.  That's
just wrong---you can't really be sure that it's a temporary glitch
caused by your peer.  If it's not, you are unnecessarily taking
yourself off the net.

Of course, there is little you can do when the outer framing at the
internal BGP layer is wrong (resyncing is way too risky).  A tear-down
might be in order if you receive an unrecognized message type, too.
But a BGP update message which is malformed internally should just be
ignored.  From a theoretical point of view, it's no worse than the
operator configuring a prefix-list that filters out all the NLRI
entries.


home help back first fref pref prev next nref lref last post