Re: [Idr] Questions regarding BGP capabilities (RFC5492)

[Donatas Abraitis <[e-mail]>]

Hi,

>Are there still BGP implementations out there that do not support
capabilities (RFC5492)?

Most likely some random parsers/scripts don't care about capabilities, but
I think this is not a big deal.

>I checked some other opensource BGP implementations and noticed that
both FRR and bird send this suberr 7 NOTIFICATION without any data!

Speaking of FRR: what is the configuration of FRR? It SHOULD send
NOTIFICATION(7) only when there is a strict capability requirement
(neighbor ... strict-capability-match), or the AFI/SAFI is not enabled at
all when MP is used.

>The Data field in the NOTIFICATION
   message MUST list the set of capabilities that causes the speaker to
   send the message.

I double-checked this, and FRR sends capability(-ies) that are not in
compliance with what is expected. At least wireshark/tcpdump shows it
correctly.

Donatas.

On Thu, Apr 18, 2024 at 1:33 PM Claudio Jeker <[e-mail]>
wrote:

> Hi all,
>
> I have a few questions about BGP capabilities since we want to enforce
> some capabilities long term in OpenBGPD.
>
> As a first step we want to remove an old fallback to start over with no
> capabilities in case of a NOTIFICATION with error code 2 (OPEN) and
> suberr 4 (Unsupported Optional Parameter).
>
> Are there still BGP implementations out there that do not support
> capabilities (RFC5492)?
>
>
>
> On top of this I have a question about NOTIFICATION error code 2 (OPEN)
> suberr 7 (Unsupported Capability). From the RFC5492:
>
> 5.  Extensions to Error Handling
>
>    This document defines a new Error Subcode, Unsupported Capability.
>    The value of this Subcode is 7.  The Data field in the NOTIFICATION
>    message MUST list the set of capabilities that causes the speaker to
>    send the message.  Each such capability is encoded in the same way as
>    it would be encoded in the OPEN message.
>
>    As explained in the "Overview of Operations" section, the Unsupported
>    Capability NOTIFICATION is a way for a BGP speaker to complain that
>    its peer does not support a required capability without which the
>    peering cannot proceed.  It MUST NOT be used when a BGP speaker
>    receives a capability that it does not understand; such capabilities
>    MUST be ignored.
>
> I have an issue with "Each such capability is encoded in the same way
> as it would be encoded in the OPEN message".  The thing is for some
> capabilities the system may not really know the exact encoding of the
> missing capability. For example graceful restart could include some
> AFI/SAFI pairs but those are optional.
>
> For OpenBGPD when parsing notifications only the first byte of data is
> looked at so that we can log which capability code caused the problem.
> When sending such a notification we build a capability with valid code and
> length fields but apart from capa 1 the payload of the capability is 0.
> For capa 1 we do send the AFI/SAFI pair that is missing.
>
> How do other implementations handle this?
>
> I checked some other opensource BGP implementations and noticed that
> both FRR and bird send this suberr 7 NOTIFICATION without any data!
> I can not really check the behaviour of other propretary implementations.
>
> Also FRR seems to send suberr 7 NOTIFICATIONs for unknown or superfluous
> capabilities. Which violates the last sentence of Section 5.
> Again, do other implementations do the same?
>
> --
> :wq Claudio
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>


-- 
Donatas