On Fri, Sep 18, 1998 at 05:14:28PM -0400, Chris Morrell wrote: ==>The Cisco is probably running IOS 11.1(20)CC. This version has a bug in ==>it that assumes the other side will understand its request to negotiate ==>MBGP (which there is no RFC for and which seems to be Cisco proprietary at ==>this point). RFC 2283. It was out at the time. =) ==>The BGP session will come up with a Cisco which can't run MBGP, but it ==>doesn't seem to work for other routers. (notably routers using gated ==>derived code. ==> ==>Changing the IOS will fix the problem, but the better short term thing to ==>do is to have the Cisco side add the following line to their BGP ==>configuration for your connection: ==> ==>neighbor AA.BB.CC.DD dont-capability-negotiate ==> ==>If you want more details and the actual Cisco Bug ID, I can find that for ==>you. Here's what I posted to NANOG sometime in July: 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