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."