North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Strange BGP announcement.

  • From: Craig A. Huegen
  • Date: Thu Aug 06 12:58:05 1998

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.