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/rfc4760Ondrej: 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 mandatoryORIGIN 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
signature.asc
Description: OpenPGP digital signature
