Incorrect kernel route installed with unnumbered BGP

[clintoncampbell]

In order to support the unnumbered transit links, FRR is configuring APIPA addresses in the kernel routing table as placeholders for the next route. While routes are being distributed and these placeholders are set up in the ARP tables, I haven't been able to route traffic unless I number at least one side of the link.

After some captures and review of ARP tables, I discovered that packets are hitting the transit link and being dropped due to an invalid link layer address. Manually modifying the APIPA entry (on both sides) to match the MAC of the remote router allows routing to proceed.

Of note in this scenario, both devices are running Debian 9 on a 32 bit ARM architecture

• Linux titan 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l GNU/Linux

I've included output from ip neigh. The unnumbered link is on eth1 and 169.254.0.1 is the placeholder address. The correct link layer address for the target is shown in the third entry, i.e., 00:0e:c6:cb:7b:66.

169.254.0.1 dev eth1 lladdr 3e:26:fc:fc:77:92 PERMANENT
172.19.0.70 dev eth0 lladdr 58:ef:68:13:eb:79 STALE
fe80::3c26:fcbb:b4fc:7792 dev eth1 lladdr 00:0e:c6:cb:7b:66 router REACHABLE
fe80::1c38:be66:89a7:e29a dev eth0 lladdr 58:ef:68:13:eb:79 REACHABLE

[clintoncampbell]

After stepping back from the problem for lunch, I realized that the FRR installed MAC address is being generated from the IPv6 address. Since SLAAC is configured to create private addresses rather than h/w-based addresses, this results in an invalid ARP entry.

This gives me a short-term fix, but I'm still left wondering why FRR is leveraging the IPv6 address rather than grabbing the actual Ethernet header? If this functionality is intentional, additional documentation would be welcome.

[clintoncampbell]

@qlyoung @donaldsharp Based on my initial readings of RFC 5549, I'm not convinced that this is a documentation issue. The RFC does not specify which IPv6 address encoding except to say that IPv4-mapped addresses may be used in some scenarios. Is there a separate RFC or a technical rationale that justifies assuming that the link local address is EUI-64 encoded?

[eqvinox]

It is indeed incorrect and a bug to derive the APIPA MAC from the IPv6 address. That said, I can tell you why this is currently implemented this way: it's impossible to get the ethernet header for received IPv6 packets without bypassing the entire IPv6 stack.

The better/correct alternative would be to retrieve the MAC address from the IPv6 neighbor entry, i.e. read it from the neigh table.

[eqvinox]

code reference: https://github.com/FRRouting/frr/blob/6e6b03c0dc272a2ca7337f5f9970052ee3709e2b/zebra/interface.c#L818 ipv6_ll_address_to_mac() needs to be incinerated

[jllorente]

@eqvinox , is this still an issue with FRR 6.0.2 ? I read in the release notes that some changes had been made to unnumbered BGP, but nothing in detail.

[eqvinox]

Unfortunately, this is still a problem in master :disappointed: (I was asked on IRC to update this)

@donaldsharp can someone on your end throw this on their TODO list? I think we have more neigh infrastructure now, can we do an IPv6 => MAC lookup in the kernel neigh table to properly get the MAC rather than trying to guess it from the LL address?

[YutaroHayakawa]

Probably, it is already considered, but let me ask for the recording.

Below commit added the handling of Source Link Layer Address option of RA. It's an optional, so it doesn't work always, but IIUC we can rely on this option to get MAC address in non-EUI64 case.

https://github.com/FRRouting/frr/commit/71974bf5612447abbb14971752217e2cf7ee7934

However, the problem is it works only when the source address is not link local address.

What's the background behind this implementation? I couldn't figure out it from commit message. It uses the word "trust", but what do you mean by trust in this case? @donaldsharp