On Thu, Aug 06, 1998 at 10:48:53AM -0500, Brett Frankenberger wrote: ==>Bays don't crash (at least not in the general case ... for example, ==>mine stayed up this time and the last time this happened), but they do ==>send a NOTIFY and bring down the BGP session, as required by the RFC. ==>(I believe gated does this also.) ==> ==>The reason this issue causes problems is that Cisco violates the RFC ==>and passes the bad announcement around, so it eventually reaches most ==>non-Cisco routers who properly terminate the BGP connection. If Cisco ==>would do the NOTIFY upon receipt of the announcement, then the ==>information wouldn't spread, and only one router's worth of peerings ==>(i.e. the guy who "started" the bad annoucnement) would be lost. The "bad announcement" that you're talking about is capability negotiation for RFC 2283, multi-protocol extensions to BGP--used for MBGP. It's not a bad announcement, but an OPEN message intended to support multiple NLRI types. The intended behavior for 11.1(20)CC is that when it sees a NOTIFY of code 2, subcode 4 (unknown authentication parmeter), it backs off and uses the unicast IPv4 NLRI type only (and the OPEN format without the options). Unfortunately, there is a case where the Cisco will respond to the TCP session close by tearing down the peer before it ever sees the NOTIFY message. CSCdk30915 addresses this, and it will be fixed in an early interim of 11.1(20)CC. A temporary workaround is to enable "neighbor x.x.x.x dont-capability-negotiate" on the Cisco. /cah