GNOME Bugzilla – Bug 747814
IPv6 accept_ra disabled after initializing IPv4 in dual-stack IPv6+IPv4 installation
Last modified: 2020-11-12 14:26:05 UTC
Created attachment 301501 [details] Anaconda 19/CentOS 7 NetworkManager debug log When installing a CentOS 7 host that uses NetworkManager in a dual-stack IPv4+IPv6 configuration, I'm seeing an issue where the eth0 interface is initialized twice and the IPv6 gateway is lost due to the accept_ra and accept_ra_defrtr sysctls being disabled (set to '0') by NetworkManager the second time. This results in a host with working v4 (IPv4 addr on eth0 + default v4 gateway) and broken v6 connectivity (IPv6 addr on eth0, no default v6 gateway), and thus breaks our installations because it cannot continue on to contact our v6-only repos. Details: I am statically configuring both IPv4 and IPv6 addresses (no SLAAC or DHCP), with the expectation the host will get its v6 gateway via router advertisements. What I'm seeing in the logs is after NetworkManager takes over from anaconda, NM activates eth0 and both v4+v6 fully work as expected for a few seconds. NM logs then show eth0 transitions from connected->disconnected->connected. After this second initialization, all v6 routes are removed including ::/0, v4 address+gateway are brought up, v6 address is brought up but NM explicitly disables the accept_ra/accept_ra_defrtr sysctls. The system has a v6 address but can't learn a gateway from RAs, thus unreachable over the network via v6. NetworkManager shows it's changing v6-related sysctls several times throughout this. e.g. [1428974948.370873] [platform/nm-linux-platform.c:1578] _log_dbg_sysctl_set_impl(): sysctl: setting '/proc/sys/net/ipv6/conf/eth0/accept_ra' to '0' (current value is '1') ... [1428974948.372612] [platform/nm-platform.c:2289] log_ip6_route(): signal: route 6 removed: ::/0 via fe80::567f:eeff:fe6e:9041 dev eth0 metric 1024 mss 0 src unknown'1') In a pure IPv6 only configuration (e.g. --noipv4 in anaconda kickstart) I don't see this behavior; v6 address comes up, v6 gateway is learned from RAs, accept_ra is never turned off, and v6 keeps working. I'm puzzled and it leads me to two questions: - Why is the ethernet interface brought up/down twice? - Is there a setting to tell NetworkManager to continue accepting RAs or is this a bug? This is done in an Anaconda kickstart environment, so I'm not sure if that makes any difference. I'm attaching a copy of the NetworkManager debug and ifcfg.log logs, hopefully somebody can shed some light on this problem. The system in question has two interfaces, eth0 and eth1, but only eth0 is used. net.ifnames=0 is also specified on the kernel command line to disable the new consistent naming scheme. A really ugly workaround has been to put a "while 1 ; do sysctl ...accept_ra=1 ; sysctl ...accept_ra_defrtr=1 ; done" background loop in our kickstart %pre scripts to brute force accepting RAs, but obviously this is not desirable. :) Version information: CentOS 7.0.1406 NetworkManager 0.9.9.1-13.git20140326.4dba720.el7 Anaconda 19.31.79-1 Kernel 3.10.0-123.el7.x86_64 Anaconda network configuration snippet: network --ip=10.82.251.29 --hostname=webhost314.facebook.com --netmask=255.255.255.0 --bootproto=static --ipv6=2401:db00:10:d0fb:face:0:1:0 --device=eth0 --nameserver=[redacted],[redacted] --gateway=10.82.251.1 --activate
> I'm seeing an issue where the eth0 interface is initialized twice and the > IPv6 gateway is lost due to the accept_ra and accept_ra_defrtr sysctls being > disabled (set to '0') by NetworkManager the second time. Since 0.9.10, NetworkManager does SLAAC in userspace using libndp. It will set accept_ra=0, which does not necessarily mean that it doesn't do SLAAC. > I am statically configuring both IPv4 and IPv6 addresses (no SLAAC or DHCP), > with the expectation the host will get its v6 gateway via router > advertisements. What I'm seeing in the logs is after NetworkManager takes > over from anaconda, NM activates eth0 and both v4+v6 fully work as expected > for a few seconds. That is not implemented. You could configure method "auto" (SLAAC), and additionally configure static IP6 addresses. There are configuration options "ipv6.ignore-auto-dns" and "ipv6.ignore-auto-routes", but there is no configuration option "ipv6.ignore-auto-addresses". If you configure IP6 addresses manually, you already know your networking configuration. Why don't you configure the gateway statically as well? > I'm puzzled and it leads me to two questions: > - Why is the ethernet interface brought up/down twice? First, NetworkManager creates a new in-memory connection named "eth0". That one gets activated at: 01:28:55,215 INFO NetworkManager: <info> Activation (eth0) starting connection 'eth0' This in-memory connection gets created, because the interface is already up with an IP address configured when NetworkManager starts. In this case, NetworkManager thinks, that there is already some pre-existing configuration present, and tries to take over that configuration (non-destructively). Later, something externally (anaconda?) starts the connection "System eth0": 01:29:08,367 INFO NetworkManager: <info> (eth0): disconnecting for new activation request. This "System eth0" indeed has SLAAC disabled.
Because in IPv6 there is no reason to have to centerally manage your default routers anymore - the preference is to use LL over RA. We *do*, however, have to know the global IP addresses of our machines to be able to access them, they are statically assigned and in DNS. The routers then use LL addresses in RA and voila it works. Meanwhile we don't want to use SLAAC - we want traffic *from* our machines to also come from said address. This is a valid configuration - I know several shops that use it. What do we need to do to make this work?
(In reply to Phil DIbowitz from comment #2) > Because in IPv6 there is no reason to have to centerally manage your default > routers anymore - the preference is to use LL over RA. We *do*, however, > have to know the global IP addresses of our machines to be able to access > them, they are statically assigned and in DNS. The routers then use LL > addresses in RA and voila it works. Meanwhile we don't want to use SLAAC - > we want traffic *from* our machines to also come from said address. > > This is a valid configuration - I know several shops that use it. What do we > need to do to make this work? can you not just configure a static IPv6 address *in addition* to method=auto? What is the problem with that?
If we do that, outgoing traffic will not reliably come from the static address, it'll come from the SLAAC addresses, which we don't want.
One more question, is the router set to offer addresses? eg, is the "Autonomous" flag set in the advertisement, even though the hosts should ignore it? Do you provide DNS servers and search domains to the statically-addressed hosts? Also, do you use the MTU or hop limits from the advertisement? Just trying to get an idea of the scope of what your location uses from the RA, and what it doesn't. Thanks!
I'm not sure, but I believe so. Yes, we provide DNS servers and search domains statically to the hosts. Nope, all of our MTUs are the standard 1500. We only use the RAs our routers which are usually our default gateways.
Dan & Thomas, Follow-up question... you mentioned the possibility of both allowing auto *and* setting a v6 address. Remember the problem we have is inside the anaconda environment, so I'm not sure how to do that. According to the dracut docs at (http://man7.org/linux/man-pages/man7/dracut.cmdline.7.html) we should be able to pass this on the kernel command-line: ip=[2401:db00:10:d0fb:face:0:1:0]:::64:::auto6 But that doesn't actually work - we get no default route in this case as well, but also no SLAAC address. So even if that would work (and it may be a useful workaround for the anaconda stage), I don't see a way to actually make it happen... And on the original topic, does my explanation make sense? can we get the ability to use RA with static addresses? I'll be happy to test out any patches in our infra as well.
Oh. Additional data: we also tried "ip=auto6 ip=[2401:db00:10:d0fb:face:0:1:0]:::64:::none" since ip can be specified more than once. That also gives us static, no SLAAC, and no RA.
Ping? Any thoughts here?
The best solution here is probably to add an 'ignore-auto-addresses' parameter to NMSettingIPConfig. On the IPv6 side that would ignore the address that rdisc generated for the interface, and simply not add it to the composite IP6 config that gets applied to the device. But it would preserve the gateway, so any static addresses would then receive the RA gateway. However, it looks like there are currently some issues in git master with the ignore-auto-* stuff. They only get checked in nm_ip6_config_merge_setting(), which is only called from nm-device.c::ensure_con_ipx_config(). That in turn is only called from ip6_config_merge_and_apply() and is called *before* the AC/DHCP configs get merged. Thus I think we need to re-order some stuff to ensure that the NMConnection preferences for ignore-auto-* get applied after priv->ac_ip6_config, priv->dhcp6_ip6_config, and priv->vpn6_config, but *before* priv->ext_ip6_config. Thomas, does this look correct?
Thanks Dan. ignore-auto-address would work well, I think. I'm still not clear how we're supposed to pass this stuff in at install time though... there seems to be no way to specify a static address and still get RA - even if we're OK with SLAAC addresses. Is this a bug in NM option parsing, or is this a bug in dracut? Shouldn't "ip=[2401:db00:10:d0fb:face:0:1:0]:::64:::auto6" give us RA and a static address (and SLAAC)? At the moment we have a background'd shell loop in our kickstart config that just sets accept_ra_defrtr to 1 over and over and over during the install process which is a horrible hack. :(
see also bug 750412 to support specifying the gateway without static addresses.
Any thoughts on getting ignore-auto-address in and passing it in through dracut and friends?
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).