[bird-users] Optional attribute error peering BGP with FRR

[Hansen, Christoffer]

Derrick,

Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)

> From the pcap this looks like FRR is sending an empty NLRI and
> according to RFC 2858:
> 
>    An UPDATE message that carries no NLRI, other than the one encoded in
>    the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
>    If such a message contains the NEXT_HOP attribute, the BGP speaker
>    that receives the message should ignore this attribute.
> 
> So the enclosed pcap looks correct too me as that we are sending a
> default route to our peer to be pointed back at us.

[0]: https://tools.ietf.org/html/rfc4760

Ondrej: Possible bird is checking for an NEXT_HOP field to be present in 
the mentioned BGP Update Message?

Hansen, Christoffer wrote on 11/07/2019 15:34:
> Derrick,
> 
> Possible a missing next-hop attribute can be the case?
> 
>  From [0]:
>          attribute           EBGP                    IBGP
>           ORIGIN             mandatory               mandatory
>           AS_PATH            mandatory               mandatory
>           NEXT_HOP           mandatory               mandatory
> 
> ORIGIN and AS_PATH is attached as attributes to the BGP Update Message. 
> No NEXT_HOP, thou.
> 
> Christoffer
> 
> [0]: https://tools.ietf.org/html/rfc4271#section-5 (p. 25)
> 
> On 11/07/2019 13:41, Derrick Lim wrote:
>> Hello everyone,
>>
>> I’m having an issue with FRR running on Cumulus (4.0+cl3u10), which is
>> peering BGP to BIRD (2.0.2, also tried 1.6.3).
>>
>> When certain routes from FRR are advertised to BIRD (I configured them
>> through vrf leaking on FRR, but not sure if that matters, or its just
>> something with the routes), BIRD terminates the BGP session with an
>> `Optional attribute error` (on BIRD 2.0.2, different error on 1.6.3)
>> when receiving the BGP UPDATE message.
>>
>> I’m not sure if this an FRR or BIRD issue, so I'm hoping someone here
>> could take a look if the UPDATE message from FRR could possibly be
>> malformed, or is BIRD handling this in an odd way.
>>
>> I've attached the tcpdump as well as error logs from BIRD, along with
>> the bird.conf, as well a portion of the FRR config.
>>
>> 100.91.38.1 is the host running BIRD.
>> 100.91.38.61 is the host running FRR.
>>
>> Regards,
>> Derrick
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190711/c29971c6/attachment.sig>