[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH] network: allow accept_ra == 0 when enabling ipv6 forwarding

On Wed, Aug 12, 2020 at 07:21:14PM -0400, Laine Stump wrote:
> Yay! A user who follows up their conversation on the libvirt-users list with
> a patch! :-)

Heh, ipv6 in my work VM is my white whale, so, call me Ishmael :)

> Unfortunately, on my Fedora 32 machine that has NetworkManager enabled, not
> all the interfaces have accept_ra=0 by default. One of the bridge devices
> (created by NetworkManager in response to an ifcfg file in
> /etc/sysconfig/network-scripts) has accept_ra = 1. (there are several other
> interfaces that have accept_ra=1, but those interfaces are either not
> online, or they don't have an IPv6 address.

Interesting, from a cursory search the only place NetworkManager seems
to set accept_ra to 1 is [1] for ip tokens (TIL ...) and then that
seems to turn if off again when the interface is enabled.  But you
know, that's also 18,000+ lines of logic in there ... so ...

>From my memory of looking at the ifcfg-* files path it's a plugin for
NM that reads those files and basically passes them as config into NM
"core".  So it doesn't do anything particularly magic.

However I'm reminded of a bug that took us a very long time to
diagnose with "glean", a tool to configure interfaces from
config-drive data in OpenStack clouds.  Some clouds don't do DHCP, so
it is used to read the config-drive data set by the cloud and write
out the network config.  It had a long history, before systemd udev
activation was a thing, an was calling "ip link set dev <interface>
up" on the interface and then seeing if it had a carrier.  This would
enable accept_ra == 1 and the kernel would configure an IPv6 address;
however since the interface then looked configured, and NetworkManager
would ignore it, and thus not apply the IPv4 configuration we had
written out.  Hosts came up with an IPv6 but no IPv4; it was all very
confusing till we put it together.  My long winded point being that
*maybe* something else is getting in the way ...

> So this doesn't work for all cases.

So the intent at least is to do this warning iff the existing
interface is already set to "1".  So if you did put that bridge into
the VM network and we enabled forwarding on it, that would seem to
change it's behaviour and possibly break it?

> I think we need to get more information on how to most easily,
> generically, and reliably determine if the kernel accept_ra setting
> can be ignored. Possibly the NetworkManager people can help us out
> here.

++ to that, if the correct response is to error, or automatically set
it to "2", or ignore it are all open questions :)


[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/52af5e901e4e5e7727ae83db18a37730b5f898fe/src/devices/nm-device.c#L1553
[2] https://review.opendev.org/#/c/688031/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]