On Tue, Jun 26, 2001 at 09:32:10PM -0700, Sean Donelan wrote:

I would prefer we try to maintain the BGP sessions. But if you think your peer's protocol implementation is flawed, cycling the BGP session is unlikely to fix the software. It just makes things worse as you announce and withdrawl sections of the route table repeatedly. Shutdown the session (and keep it down) and wait for human intervention.

Well not to play Dr. Obvious, but to quote a spec people claim to be following: If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry. So if you want to see it used, get on your vendor about it... Also, RFC1771 is pretty out of date, the "least incorrect" reference currently available is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)