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).
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.
Chris
http://search.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-01.txt
would seem to be towards the correct direction.
BR
On Fri, Sep 18, 1998 at 05:14:28PM -0400, Chris Morrell had most eloquently written:
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).
actually, i think the bug relates to Capabilities Negotiation, which is a
draft RFC at this point. there is great irony in capabilities negotiation
causing a BGP session to reset because it was created specifically to
avoid connection resets from unknown Optional Parameters in an OPEN message.
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
the real bug is not that cisco implemented capability negotiation incorrectly,
but that it is on by default long before anyone else has implemented it.
If you want more details and the actual Cisco Bug ID, I can find that for
you.Chris
ben
On Fri, Sep 18, 1998 at 05:14:28PM -0400, Chris Morrell had most eloquently written:
>
> 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).
>actually, i think the bug relates to Capabilities Negotiation, which is a
draft RFC at this point. there is great irony in capabilities negotiation
causing a BGP session to reset because it was created specifically to
avoid connection resets from unknown Optional Parameters in an OPEN message.
Yes, this is correct. The Cisco attempts to negotiate MBGP.
The Cisco sends an OPEN message with an option parameter value of 4. That
value is not defined in the most current BGP RFC. (can't remember the
number)
The only valid option paramater is a value of 1 which if I remember
correctly is for authentication.
> 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
>the real bug is not that cisco implemented capability negotiation incorrectly,
but that it is on by default long before anyone else has implemented it.
Yes, that's right. I think Cisco meant to try and negotiate the MBGP
option, but then fall back to no options. The bug is that the code
doesn't fall back.
I've documented this whole problem and left everything at my office in
Toronto. I'm working in the Montreal office until the middle of next
week so I apologize if my data seems a little vague.
The Cisco BUGID is CSCdk30915.
If any Cisco personel are listening in and spot something that isn't
right, please correct me. I hate propogating incorrect info.
Chris
==>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
> actually, i think the bug relates to Capabilities Negotiation, which is a
> draft RFC at this point. there is great irony in capabilities negotiation
> causing a BGP session to reset because it was created specifically to
> avoid connection resets from unknown Optional Parameters in an OPEN message.Yes, this is correct. The Cisco attempts to negotiate MBGP.
The Cisco sends an OPEN message with an option parameter value of 4. That
value is not defined in the most current BGP RFC. (can't remember the
number)
Please check
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-*
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-*
It's not uncommon for document status to lag behind running code.
Currently, I'm aware of 3 implementations of multiprotocol BGP.
The only valid option paramater is a value of 1 which if I remember
correctly is for authentication.
Yes, this is correct.
> the real bug is not that cisco implemented capability negotiation incorrectly,
> but that it is on by default long before anyone else has implemented it.Yes, that's right. I think Cisco meant to try and negotiate the MBGP
option, but then fall back to no options. The bug is that the code
doesn't fall back.I've documented this whole problem and left everything at my office in
Toronto. I'm working in the Montreal office until the middle of next
week so I apologize if my data seems a little vague.The Cisco BUGID is CSCdk30915.
If any Cisco personel are listening in and spot something that isn't
right, please correct me. I hate propogating incorrect info.
Above is substantially correct. Above bug never backed off to plain
vanilla BGP4 after failing to do capability negotiation. 11.1(20.2)CC
and beyond releases have this bug fixed.
-dorian