Optional attribute error peering BGP with FRR
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
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
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
On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
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?
Hi BIRD is generally doing revised error handling per RFC 7606, so most attribute errors are treated by handled by treat-as-withdraw policy instead of optional attribute error. By quick view i found only a few case that could generate optional attribute error: MP_REACH_NLRI / MP_UNREACH_NLRI of invalid (too small) length and NEXT_HOP (or next-hop part of MP_REACH_NLRI) of unrecognized length. Is any of this in the pcap file? Could you send me a pcap file? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, Jul 11, 2019 at 04:23:18PM +0200, Ondrej Zajicek wrote:
On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
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?
Hi
BIRD is generally doing revised error handling per RFC 7606, so most attribute errors are treated by handled by treat-as-withdraw policy instead of optional attribute error.
By quick view i found only a few case that could generate optional attribute error: MP_REACH_NLRI / MP_UNREACH_NLRI of invalid (too small) length and NEXT_HOP (or next-hop part of MP_REACH_NLRI) of unrecognized length.
Is any of this in the pcap file? Could you send me a pcap file?
Sorry for confusion, i just checked the pcap file and it is definitely the NEXT_HOP attribute missing with regular NLRI present. While in BIRD 2.0.4 this is handled by treat-as-withdraw, in BIRD 2.0.2 it was still handled by Optional attribute error notification. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Since my last email bounced. At this point I believe FRR is sending data that is not properly formatted at this point in time. This problem is actively being worked at this point in time. donald On Thu, Jul 11, 2019 at 10:58 AM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Thu, Jul 11, 2019 at 04:23:18PM +0200, Ondrej Zajicek wrote:
On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
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?
Hi
BIRD is generally doing revised error handling per RFC 7606, so most attribute errors are treated by handled by treat-as-withdraw policy instead of optional attribute error.
By quick view i found only a few case that could generate optional attribute error: MP_REACH_NLRI / MP_UNREACH_NLRI of invalid (too small) length and NEXT_HOP (or next-hop part of MP_REACH_NLRI) of unrecognized length.
Is any of this in the pcap file? Could you send me a pcap file?
Sorry for confusion, i just checked the pcap file and it is definitely the NEXT_HOP attribute missing with regular NLRI present.
While in BIRD 2.0.4 this is handled by treat-as-withdraw, in BIRD 2.0.2 it was still handled by Optional attribute error notification.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (4)
-
Derrick Lim -
Donald Sharp -
Hansen, Christoffer -
Ondrej Zajicek