[45158] in North American Network Operators' Group
Re: Persistent BGP peer flapping - do you care?
daemon@ATHENA.MIT.EDU (Susan Hares)
Fri Jan 18 21:40:02 2002
Message-Id: <5.0.0.25.0.20020118213754.02c8dc40@mail.nexthop.com>
Date: Fri, 18 Jan 2002 21:39:10 -0500
To: Vijay Gill <vijay@umbc.edu>
From: Susan Hares <skh@nexthop.com>
Cc: Dave Israel <davei@biohazard.demon.digex.net>, <nanog@merit.edu>
In-Reply-To: <Pine.SGI.4.31L.02.0201171737240.1517674-100000@irix2.gl.um
bc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Errors-To: owner-nanog-outgoing@merit.edu
vijay:
What else causes repeative peer bounces other than the broken prefix?
sue
PS - I'm away from work from now until Monday morning..
At 05:42 PM 1/17/2002 -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.
>
>/vijay
