North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Persistent BGP peer flapping - do you care?
Chris: Thanks for the input. This is the revisit the specification time. Just to confirm your answer, I'll paraphrase it and let you know what happened. the persistent bgp peer flapping happens when you (one of the paths) 1) Error causes stop (bad prefix --> drop connection) 2) BGP peer goes to IDLE state 3) Automatic restart happens (cisco doesn't utilize the backoff) 4) Open sent 5) active 6) error due to bad prefix still being sent 7) Idle Hold time (time delay here) --> go back to #1 Specification says to slow down the cycle of the establishing by increase the time delay in step #7. I think we are describing the same problem. Could you please confirm? At 03:10 PM 1/17/2002 -0500, Christopher A. Woodfield wrote:
This has been bandied about before, but one should note that the "drop the
Do the peering sessions drop once or repeatedly until the bad prefix gets cleared out?
I guess the main question is what is considered an "error" - if the peer starts obviously misbehaving, then yet, drop the peer. But don't drop the peer due to an invalid prefix that most likely did not ori0ginate on that router - it would be much better for the 'net as a whole to
The algorithms for what constitutes a "drop" can be an implementation detail or be specified as an optional portion of the next version of the BGP specification.
In short, the "drop the session when you get a bad prefix" only works its intended
The specification says "recommended" (should) now and as we noted with cisco, not all vendors implement it. We are documenting existing practice so recommended/should will remain. If you think it is a very serious operational issue, you can always input to the idr mailing list that the "should" needs to be "must" due to an operational issues. Thanks again for answering the cry for help! Sue