[bird-users] Optional attribute error peering BGP with FRR

[Ondrej Zajicek]

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