networkd: please consider adding a possibility to set sysctl variables like ipv6/accept_ra

[Zugschlus]

Hi,

to properly use IPv6, it is sometimes necessary to set sysctl variables before the link is set to up. An incomplete list of those variables include accept_ra, accept_redirects, autoconf, dad_transmits, hop_limit, mtu, router_solicitation_*. Since some interfaces are only ever created by networks (bridges, VLANs), this needs to be done in between netdev creation and IP address configuration.

The natural place to do this would most probably be the [Netdev] section of a .netdev part. The easiest way to do this in networkd would be to allow multiple "sysctl" lines like

sysctl=accept_ra=1
sysctl=autoconf=1

but the nicer way would probably be to have something like

IPv6AcceptRA=1
IPv6Autoconf=1

but that would mean that networkd would have to follow introduction of new variables at kernel side. Personally, I would prefer having both, as this would give nice configuration files for "old" variables and still the possibility to set variables that networkd does not yet know about.

Greetings
Marc

[poettering]

Yeah, we should allow control of more sysctl settings where they make sense. I'd always be careful though with blanket exposing all available options, and instead look at each one individually before exposing it.

Also, some of the options might also be controllable via netlink, in which case we should prefer the netlink way.

[Zugschlus]

I have just noticed that this is vital for bridges: Before systemd-networkd, you can't set any options on a bridge since it doesn't exist yet. After systemd-networkd, you can't change any options since the bridge is already up.

I don't care how things are pushed into the kernel, as long as it is possible to do so. And please consider that by not exposing a setting, you're taking the possibility to set those settings from your users completely.

[thx1111]

I am still uncomfortable with the idea of systemd "taking over" the sysctl settings, as seems to have started with "IPForward=", in systemd.network(5). This is a "slippery slope", where, if you do one sysctl setting, you will have to do them all. And, the problem with "more than one way to do it" is that confusion will result from using more than one, possibly conflicting, mechanism for system configuration. Then ensues an "Easter Egg Hunt", finding which configuration has priority, and where exactly it might be located.

[johannbg]

@thx1111
Systemd already has ( in a sense ) "taking over" the sysctl settings ( see man systemd-sysctl.service and man sysctl.d ). That said yep this was not thoroughly thought through when the IPForward stuff got committed and pandoras box has indeed already been opened here.

Correct ordering needs to be ensured ( basically anything that has been put in the .conf file in any of the sysctl.d directories takes precedence over entries in network files or elsewhere for that matter ) as well as networkctl needs to display if sysctl variable has been set in relation the interfaces it manages and differentiate in that ouput whether the configuration knob was set in a sysctl.conf file or in an network configuration file

[thx1111]

basically anything that has been put in the .conf file in any of the sysctl.d directories takes
precedence over entries in network files or elsewhere for that matter

So then there exists an important distinction between "/etc/sysctl.conf" and the "/etc/sysctl.d/*.conf" files?

My understanding is that .network files will over-ride "/etc/sysctl.conf" unless "IPForward=kernel" is set. Are you saying, effectively, that in moving "/etc/sysctl.conf" to "/etc/sysctl.d/sysctl.conf", the "sysctl.conf" file will then over-ride the .network files?

[johannbg]

@thx1111 Administrators expect to add or find the configuration knobs in the sysctl.conf file or in .conf file that reside in sysctl.d/* directories.

Depending on what the intent was from the commiter when he committed the PR for IPForward, it will either break ( if it take precedence over sysct.conf or any sysctl.d directories in their order of precedence ) administrators expectations and tribute to their "re-education" and "frustration" or it will honour it ( if it does not take precedence over sysct.conf or any sysctl.d directories in their order of precedence as in it does nothing if it finds ) which is the pandora box of "precedence" he opened.

From "my opinion" the "correct" behaviour is that the traditional sysctl configuration entries for networking that reside in sysctl configuration files should always take precedence over whatever gets added to networkd and it's configuration files so the order of precedence is this...
/etc/sysctl.conf
/etc/sysctl.d/.conf
/run/sysctl.d/.conf
/usr/lib/sysctl.d/*.conf
networkd configuration files and knobs..
which means that the "IPForward=kernel" is the "sane" ( flame and downstream patch free ) upstream default since it leaves administrators having to opt-out consciously from their own "expectations".

[johannbg]

Arguably this options should have been a global switch to use or not to use sysctl configuration entries in networkd configurations as in IPSYSCTL= that either preserves and honours the sysctl settings or not otherwise this might end up in endless IP$FOO=kernel options for every sysctl configuration setting networkd might ever decide to "interfere" with.

[j16sdiz]

I think sysctl can't match interface with, for example, mac address.
If I want to do "disable ra for this usb network device when I plug it in", what is the sane option?

[poettering]

To make this clear: whether something is a netlink attribute or a sysctl is just a detail of implementation, and I am very sure that networkd should cover all relevant settings, regardless which precise API is used to set them. Also, whether something is actually a sysctl is at best a documentation issue, but should not be visible in the way we expose the setting in .network or .link files.

Hence I am all in favour of exposing the requested options in networkd. Happy to take a patch for this btw! @ssahani maybe this is something for you?

[johannbg]

@poettering fair so nuff which method do expect to take precedence and in which order? Be advised that if you intend on having Networkd take precedence you will pretty much break every administrators expectation and existing configurations

[poettering]

networkd should take precedence. If you don't want networkd to manage your interfaces, then don't tell it to. If you do want it to manage your interface, then it should do that comprehensivey.

[Zugschlus]

Please also keep in mind that a sysctl setting cannot be modified if it doesn't exist, and that there are sysctl settings that cannot be changed while the link is up. This clashes with networkd's current way of creating the link and bringing it up atomically in the same operation, as this is, for example, the case for a VLAN or Bridge interface.

If a sysctl setting for such interfaces is not exposed in a .network or .netdev file and/or networkd doesn't grow a hook between .netdev and .network init (which is unlikely), there is no way to modify a non-exposed setting short of invoking networkd, taking the link down, modifying the sysctl setting and re-invoking networkd or not using networkd at all. The later would be a pity.

[johannbg]

@poettering this behaviour and order of precedence needs to be well documented and corporates with customers will need to add this to their customers courses since this breaks administrators expectations

[ssahani]

@poettering will post a patch for this .

[keszybz]

So, accept_ra is done. What about accept_redirects, autoconf, dad_transmits, hop_limit, mtu, router_solicitation_* ? @ssahani any plans?

[ssahani]

@keszybz will post patches :)

[Zugschlus]

accept_ra_from_local should also be set from systemd-networkd.

Use case: Imagine a router having fe80::1 on the interface pointing inwards. This is common in IPv6 setups so that systems without SLAAC can easily have a default gateway configured.

If "our" router's Default gateway has also fe80::1, Linux will ignore the default route since it thinks that the address is already configured locally.

This behavior can be changed by setting accept_ra_from_local for the interface that as fe80::1 not configured. This sysctl needs to be set after the interface was created (which will happen in systemd-networkd in case of a VLAN or bond interface) and soon after it was brought up, so that it is already set when the router answers to the Router Solicitation.

Setting this in a dedicated unit After systemd-networkd.service is too late, we have already ignored the first router advertisement in this case and need to wait for the next regular RA packet.

[poettering]

So, which sysctl options are still missing? a number where added over the time, anything still missing you are looking for @Zugschlus?

[j16sdiz]

@poettering May we have some generic config / hook for this kind of sysctl?

Following the current approach, if the kernel add a new config in the future, we need to upgrade to whole system suite. That would be lots of work for testing..

[poettering]

@j16sdiz well, the kernel sysctls have all kind of weird propagation logic built in (for example: the ip fowarding sysctl is completely strange with its propagation logic), morever what is set is not normalized or user friendly usually. Then, we do configure some options automatically depending on other options. All that kinda indicates we should expose all relevant options natively through friendly, normalized options.

If you want to set sysctls without any such normalization you can always use sysctl.d, it should just work.

[bobrik]

Can I request autoconf to be the next available setting? Currently it's only possible to control ndisc_router_process_autonomous_prefix from the router side, which is not always convenient.

[poettering]

hmm, let's close this issue here. networkd can control quite a few sysctls these days. If there are some missing still that people actually use, then please file new, individual issues, so that we can track each separately and close them when they are done. For now it appears most of what was requested here has been implemented, and for the rest let's see whether people file such bugs because they need them.

Or so say this differently: there's no point in exposing options people don't actually use, and let's use the issue filing as method of figuring out which ones people actually want.

[zhangyoufu]

accept_redirects was not added yet.

[keszybz]

If there are some missing still that people actually use, then please file new, individual issues, so that we can track each separately and close them when they are done.