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

[Sebastian Hahn]

> On 23. Apr 2020, at 04:35, Ondrej Zajicek <santiago at crfreenet.org> wrote:
> On Wed, Apr 22, 2020 at 10:53:12PM +0200, Sebastian Hahn wrote:
>> 
>> so I have an update here. My peer is now using an updated FRR, version 7.3-1~deb10u1 (installed from https://deb.frrouting.org), yet it still isn't working (in a normal bird 2.0.7, not using above patch). It seems to be FRR is advertising its link-local address twice as next-hop:
>> 
>>     /* GW_DIRECT -> single_hop -> p->neigh != NULL */
>> -    if (ipa_nonzero(gw))
>> +    if (ipa_nonzero(gw)) {
>> +      log(L_ERR "looking for neigh %I ll %I", gw, ll);
>>       nbr = neigh_find(&p->p, gw, NULL, 0);
>> +    }
>>     else if (ipa_nonzero(ll))
>> 
>> This small patch causes fe80::1 (my peer's link local address) to be logged for both gw and ll address. This seems like a problem with FRR/the peer's configuration to me, yes?
>> 
>> Nevertheless, I wonder if bird's behaviour is correct here. It seems to
>> me from reading the pointed out RFC that in the face of two nexthop
>> addresses, bird should attempt the connection using the specified
>> link-local address, not the global address (basicall, replacing the order
>> of the if ... else if above), while passing on the global address to its
>> peers. My first attempt at a patch seems pretty wrong to me from a look
>> at the RFC.
> 
> Well, the RFC 2545 is a bit vague and AFAIK nobody standardized
> link-local only sessions. Our position is that the first address is
> always global (as that is necessary for next hop resolving) and the
> second (optional) is link-local, therefore in cases where no global
> address is available the proper format of next hop should be (:: ll).
> 
> Unfortunately, there are other implementations that use in such cases
> (ll) or (ll ll), we should handle that in bgp_decode_next_hop_ip(), but
> the second case is not handled there. Will send you a patch.

Hi Ondrej,

thanks for the explanations! In the meantime I have found this bugreport
from the FRR project, https://github.com/FRRouting/frr/issues/6259 - it
appears they also want to change the behaviour on their side.

Thanks
Sebastian