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