This capability negotiation is only seen on the CC train. Thus, if you have CEF, you have the problem. Ironically, a colleague of mine mentioned this problem last night during a maintenance session. A foreshadowing??? -Chris- -----Original Message----- From: Craig A. Huegen [mailto:chuegen@quadrunner.com] Sent: Thursday, August 06, 1998 2:05 PM To: Brett Frankenberger; nanog@merit.edu Subject: Re: Strange BGP announcement. Egads. I suppose I should have had more coffee, then read the update. =) The problem I mentioned is a separate case. Never mind me. /cah On Thu, Aug 06, 1998 at 09:39:50AM -0700, Craig A. Huegen wrote: ==>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