Sebastian - I cannot speak towards bird's behavior here but I can say that FRR has fixed a couple of nexthop related issues with what we send to our peers since the 6.0 release. I would please consider upgrading to a much later version if you can, 7.2 or 7.3 should have the fixes.
thanks! donald On Sun, Apr 19, 2020 at 6:48 PM Sebastian Hahn <bird_us...@sebastianhahn.net> wrote: > > Hi, > > let me preface this that I very much do not know what I am doing here, and > have been somewhat unsuccessful in trying to understand what's going on by > searching online. I would love an explanation though! > > In a bird 2.0.7 setup, I was unable to import routes from one of my peers. It > is the only one using frr (version 6.02-2 on debian), most other peers use > bird1 or bird2. I noticed immediately after adding the peering that I > received "Invalid NEXT_HOP attribute" errors in the log. Unfortunately, no > more information than that was provided in the log, so I went on a little > hunt. Since the exact error is raised from many places, I added some logs to > identify the GW_DIRECT case in bgp_apply_next_hop() as the culprit. Here I > realized that both gw and ll are set, which means a neighbor is tried to be > found which doesn't involve the ll case. I then noticed that in > bgp_decode_next_hop_ip(), this can only happen if len == 32. This is where I > am absolutely clueless what it means for the nh len to be 32, and thus I > don't know if the patch I came up with is correct, even though it works for > my testing. Only this one peer using frr causes nh len to be set to 32, so I > suppose it might be ! a ! > rare configuration. > > I added this simple patch: > > --- bird2-2.0.7.orig/proto/bgp/packets.c > +++ bird2-2.0.7/proto/bgp/packets.c > @@ -1174,6 +1174,9 @@ bgp_decode_next_hop_ip(struct bgp_parse_ > > if (ipa_is_ip4(nh[0]) || !ip6_is_link_local(nh[1])) > nh[1] = IPA_NONE; > + > + if (ip6_is_link_local(nh[1])) > + nh[0] = IPA_NONE; > } > else > bgp_parse_error(s, 9); > ~ > > which worked for me to resolve the problem. > > Thanks for any consideration! > > Cheers > Sebastian
