Re: BGP 4, auth error question.

[Dorian Kim <dorian () blackrose org>]

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