Persistent BGP peer flapping - do you care?

Joel Baker lucifer at
Sun Jan 20 21:02:15 UTC 2002

On Thu, Jan 17, 2002 at 05:42:53PM -0500, Vijay Gill wrote:
> On Thu, 17 Jan 2002, Dave Israel wrote:
> > It's a question of robustness; if the new spec includes a way to be
> > tolerant of how the spec is (or can be) commonly abused, then the
> > followers of the spec will not be at the mercy of those who deviate.
> >
> > In this case, I think that having the option to keep a session that
> > gives bad routes up, and just dropping the route, is a good answer.
> > That would allow the user to determine which is preferable for a given
> > peer: possible corruption or certain disconnection.
> If you have a "bad route" how do you know the rest of the update is good?
> The nlri may have gotten corrupted on the wire or between the interface
> and the processor (parity error, or some sort of corruption on the bus).
> Given that case, in an update, I am not sure you can make a determination
> of what is good nlri and selectively propogate and process those. See also
> meltdowns circa nov 1998.

There was another notion that never made it off the drawing board (not even
into proposal) regarding "graceful error recovery", a way to assume that
your peer's *entire* table wasn't suspect, just the malformed part, and
notify the peer that there was a problem. Do this too many times, and you
drop the session, still, of course.

The not-even-a-formal-draft is still around somewhere.
Joel Baker                           System Administrator -
lucifer at    

More information about the NANOG mailing list