Strange BGP announcement.

Martin, Christian CMartin at mercury.balink.com
Thu Aug 6 19:19:13 UTC 1998


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 at quadrunner.com]
Sent: Thursday, August 06, 1998 2:05 PM
To: Brett Frankenberger; nanog at 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



More information about the NANOG mailing list