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
