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: santi...@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."
