Bug#844246: ignores Route Preference in received router advertisements

[Andreas Henriksson]

Control: tags -1 + unreproducible moreinfo

Hello Marc Haber.

I've taken the chance to look a bit at the networkd code with your issue
as a starting point for investigations.

While looking at the evolution of userspace handling of ndisc in
systemd-networkd it seems like the intention even from the incomplete
initial commit has been to handle route preference.

On Sun, Nov 13, 2016 at 07:20:05PM +0100, Marc Haber wrote:
> Package: systemd
> Version: 232-3
> Severity: important
> 
> Hi,
> 
> the systemd IPv6 code ignores the Route Preference that is in an
> incoming router advertisement.
> 
> Here is what tshark -V says about the packet:
> 
> Frame 53: 294 bytes on wire (2352 bits), 294 bytes captured (2352 bits) on interface 0
[...]
> Internet Control Message Protocol v6
>     Type: Router Advertisement (134)
[...]
>         ...0 0... = Prf (Default Router Preference): Medium (0)
[...]
>     ICMPv6 Option (Route Information : Low 2000::/3)
>         Type: Route Information (24)
>         Length: 3 (24 bytes)
>         Prefix Length: 3
>         Flag: 0x18
>             ...1 1... = Route Preference: Low (3)
>             000. .000 = Reserved: 0
>         Route Lifetime: 1800
>         Prefix: 2000::
[...]

I've set up my own test environment and can't reproduce your problem.
I'm also using as quoted above a RA with medium preference, including a
Route Information option with low preference. I've verified the package
contents using tcpdump and wireshark to make sure the package sent out
matches what you describe and what I expected.

Using networkd the route get set up with preference low here.

When *not* using networkd (ie. kernel ndisc handling) the route gets set
up with preference medium though. I looked at the kernel code and ended
up at http://lxr.free-electrons.com/source/net/ipv6/ndisc.c#L1238
which seems to explain why as I seem to (unintentionally) have:

$ cat /proc/sys/net/ipv6/conf/eth2/accept_ra_rtr_pref 
0

(In general the kernel implementation seems to have a bazillion different
knobs that all has to be set right to "just work".)

Is there any chance your route wasn't actually set up by systemd-networkd?

Maybe you could capture the rtnetlink traffic with rtmon to debug it?

Regards,
Andreas Henriksson