Greetings. I am in the process of turning up bgp with a customer and have run into the following problem. The customer is using a Cisco router with ios 11.1.20. Im using a GRF400. The session wont establish and this is what the log is showing: Sep 18 15:50:59 Sep 18 15:50:59 BGP RECV 209.239.69.1+32617 -> 206.84.235.254+179 Sep 18 15:50:59 BGP RECV message type 1 (Open) length 37 Sep 18 15:50:59 BGP RECV version 4 as 11042 holdtime 180 id 209.239.64.254 authcode 8 Sep 18 15:50:59 BGP RECV Auth data (8 bytes): 02 06 01 04 00 01 00 01 Sep 18 15:50:59 Sep 18 15:50:59 bgp_get_open: peer 209.239.69.1+32617 (proto): unknown athentication code 8 used Sep 18 15:50:59 Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617 Sep 18 15:50:59 BGP SEND message type 1 (Open) length 29 Sep 18 15:50:59 BGP SEND version 4 as 4200 holdtime 180 id 206.84.235.254 authcode 0 Sep 18 15:50:59 Sep 18 15:50:59 Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617 Sep 18 15:50:59 BGP SEND message type 3 (Notification) length 21 Sep 18 15:50:59 BGP SEND Notification code 2 (Open Message Error) subcode 4 (unsupported authentication code) Sep 18 15:50:59 Sep 18 15:50:59 NOTIFICATION sent to 209.239.69.1+32617 (proto): code 2 (Open Message Error) subcode 4 (unsupported authentication code) data it appears that the cisco is sending us an authcode that we don't recognize. Is there a way to prevent the cisco from sending the authcode 8 or change the authcode to something more civilized, like authcode 0. The customer is willing to change their IOS version if necessary but it is not the preferred resolution. Any suggestions on how I could get this to work? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Senior Network Engineer 313-730-5151 * | noc@agis.net 313-730-1130 x-5649 | | harold@agis.net 24 hours a day, 7 days a week | | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
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 On Fri, 18 Sep 1998, Harold Willison wrote:
Greetings.
I am in the process of turning up bgp with a customer and have run into the following problem.
The customer is using a Cisco router with ios 11.1.20.
Im using a GRF400.
The session wont establish and this is what the log is showing:
Sep 18 15:50:59
Sep 18 15:50:59 BGP RECV 209.239.69.1+32617 -> 206.84.235.254+179
Sep 18 15:50:59 BGP RECV message type 1 (Open) length 37
Sep 18 15:50:59 BGP RECV version 4 as 11042 holdtime 180 id 209.239.64.254 authcode 8
Sep 18 15:50:59 BGP RECV Auth data (8 bytes): 02 06 01 04 00 01 00 01
Sep 18 15:50:59
Sep 18 15:50:59 bgp_get_open: peer 209.239.69.1+32617 (proto): unknown athentication code 8 used
Sep 18 15:50:59
Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617
Sep 18 15:50:59 BGP SEND message type 1 (Open) length 29
Sep 18 15:50:59 BGP SEND version 4 as 4200 holdtime 180 id 206.84.235.254 authcode 0
Sep 18 15:50:59
Sep 18 15:50:59
Sep 18 15:50:59 BGP SEND 206.84.235.254+179 -> 209.239.69.1+32617
Sep 18 15:50:59 BGP SEND message type 3 (Notification) length 21
Sep 18 15:50:59 BGP SEND Notification code 2 (Open Message Error) subcode 4 (unsupported authentication code)
Sep 18 15:50:59
Sep 18 15:50:59 NOTIFICATION sent to 209.239.69.1+32617 (proto): code 2 (Open Message Error) subcode 4 (unsupported authentication code) data
it appears that the cisco is sending us an authcode that we don't recognize.
Is there a way to prevent the cisco from sending the authcode 8 or change the authcode to something
more civilized, like authcode 0.
The customer is willing to change their IOS version if necessary but it is not the preferred resolution.
Any suggestions on how I could get this to work?
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| Harold Willison AGIS Network Engineering |
* Senior Network Engineer 313-730-5151 *
| noc@agis.net 313-730-1130 x-5649 |
| harold@agis.net 24 hours a day, 7 days a week |
| <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic>
</italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/
http://search.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-... would seem to be towards the correct direction. BR On Fri, 18 Sep 1998, 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).
On Fri, 18 Sep 1998 17:32:25 +0000 (GMT), brad@null0.qual.net writes:
http://search.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-... xt
would seem to be towards the correct direction.
BR
On Fri, 18 Sep 1998, 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).
The problem is that the Cisco is supposed to recognize that the other side doesn't support the option, and back off. In 11.1(20) it doesn't. This may be fixed in 11.1(21)CC but I have not tested it yet. -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netins.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.quadrunner.com/~jon * -------------------------------------------------------------------------
On Fri, Sep 18, 1998 at 05:35:55PM -0500, Jon Green wrote:
The problem is that the Cisco is supposed to recognize that the other side doesn't support the option, and back off. In 11.1(20) it doesn't. This may be fixed in 11.1(21)CC but I have not tested it yet.
Fixed in 11.1(21)CC. -dorian
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, 18 Sep 1998, Ben Black wrote:
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
On Fri, Sep 18, 1998 at 06:29:07PM -0400, Chris Morrell wrote:
On Fri, 18 Sep 1998, Ben Black wrote:
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
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
participants (7)
-
Ben Black -
Bradley Reynolds -
Chris Morrell -
Craig A. Huegen -
Dorian Kim -
Harold Willison -
Jon Green