Strange BGP announcement.

Mailman List Mirror (Read Only)
1

:: Victor L. Belov writes ::

AS8263 encounted the same problem today. The problem is that cisco
handle this incorrect update normally, but it couses Bay Networks
routers to crash =() Seems to be another problem on the Internet.

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.

Neil J. McRae wrote:
>
> Aug 6 13:46:20 BGP RECV 207.45.199.225+179 -> 207.45.199.226+1935
> Aug 6 13:46:20 BGP RECV message type 2 (Update) length 71
> Aug 6 13:46:20 BGP RECV flags 0x40 code Origin(1): Incomplete
> Aug 6 13:46:20 BGP RECV flags 0x40 code ASPath(2): 6453 701 65525 ((65523)) 356
> 1 1691
> Aug 6 13:46:20 BGP RECV flags 0x40 code NextHop(3): 207.45.199.225
> Aug 6 13:46:20 BGP RECV 204.174.40/24, 204.239.26/24, 204.239.27/24, 204
> .239.147/24
> Aug 6 13:46:20
> Aug 6 13:46:20 bnp_path_attr_eer: peer 207.45.199.225 (External AS 6453) bad up
> date send NOTIFY flag 0 type 0 err_subcode 11, data 0
> Aug 6 13:46:20 NOTIFICATION sent to 207.45.199.225 (External AS 6453): code 3 (
> Update Message Error) subcode 11 (AS path attribute problem) data
> Aug 6 13:46:20
> Aug 6 13:46:20 BGP SEND 207.45.199.226+1935 -> 207.45.199.225+179
> Aug 6 13:46:20 BGP SEND message type 3 (Notification) length 21
> Aug 6 13:46:20 BGP SEND Notification code 3 (Update Message Error) subcode 11 (
> AS path attribute problem)
> Aug 6 13:46:20

          - Brett (brettf@netcom.com)

2

==>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

3

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