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