Re: Persistent BGP peer flapping - do you care?
On 1/17/2002 at 14:21:59 -0800, Jake Khuon said:
As for propogation of the bad prefix... well that soapbox has worn paint on top. If people aren't going to bother following specs in the first place I'm not sure a new spec will solve anything.
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. -Dave
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
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 - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Dave: The state machine + option in MIB can make this option workable via the specification. It is important to let user decide on a peer basis what is worse. Thank you very much for this input. Your input makes the next choices for the BGP spec easier. Thanks again!! Sue Hares At 05:34 PM 1/17/2002 -0500, Dave Israel wrote:
On 1/17/2002 at 14:21:59 -0800, Jake Khuon said:
As for propogation of the bad prefix... well that soapbox has worn paint on top. If people aren't going to bother following specs in the first place I'm not sure a new spec will solve anything.
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.
-Dave
participants (4)
-
Dave Israel -
Joel Baker -
Susan Hares -
Vijay Gill