Bug? / Patch for BGP next hop issue with frr peers

[Ondrej Zajicek]

On Mon, Apr 20, 2020 at 12:46:17AM +0200, Sebastian Hahn 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.

Hi

What is your BIRD config? It seems that most likely BIRD cannot resolve
the global next hop IP address (the on in gw). Because it is GW_DIRECT,
it is resolved only in local addresses.


> 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

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