Bug 89509

Summary: systemd-networkd: net.ipv4.conf.default.forwarding is ignored in 219
Product: systemd Reporter: Alex Crawford <alex.crawford>
Component: generalAssignee: Tom Gundersen <teg>
Status: RESOLVED FIXED QA Contact: systemd-bugs
Severity: normal    
Priority: medium CC: fdbt-ba, james, matt, mike, radek
Version: unspecified   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Alex Crawford 2015-03-10 01:46:27 UTC
It appears as though the kernel parameters "net.ipv?.conf.*.forwarding" are no longer taking their default value from "net.ipv4.conf.default.forwarding". This seems to be because of the introduction of Network.IPForwarding in networkd. If this attribute is not set, rather than using the default for "net.ipv?.conf.*.forwarding" (the behavior in 218), networkd is using the default value of Network.IPForwarding (which is false).


Under systemd 218, I see:
 $ sysctl -a -r 'net\.ipv4\.conf\..*\.forwarding'
 net.ipv4.conf.all.forwarding = 1
 net.ipv4.conf.default.forwarding = 1
 net.ipv4.conf.eth0.forwarding = 1
 net.ipv4.conf.lo.forwarding = 1


However, under systemd 219, I see:

 $ sysctl -a -r 'net\.ipv4\.conf\..*\.forwarding'
 net.ipv4.conf.all.forwarding = 1
 net.ipv4.conf.default.forwarding = 1
 net.ipv4.conf.eth0.forwarding = 0
 net.ipv4.conf.lo.forwarding = 0


Notice, that eth0 is no longer forwarding even though I have enabled that via sysctl.d. The network unit for eth0 is:

 $ cat /usr/lib64/systemd/network/zz-default.network
 [Network]
 DHCP=v4
 
 [DHCP]
 UseMTU=true
 UseDomains=true


Unless, Network.IPForwarding is set, the default forwarding value via the kernel should be used. This change-in-behavior appears to have been introduced by 5a8bcb674f71a20e95df55319b34c556638378ce (networkd: add minimal IP forwarding and masquerading support to .network files).
Comment 1 Lennart Poettering 2015-03-10 10:26:22 UTC
Yeah this was an underdocumented change in 219: we manage the IP forwarding setting per interfac now. You have to set IPForward=yes in the .network files explicitly now, otherwise you will not get IP forwarding on that interface.
Comment 2 mike@marineau.org 2015-03-10 19:06:57 UTC
(In reply to Lennart Poettering from comment #1)
> Yeah this was an underdocumented change in 219: we manage the IP forwarding
> setting per interfac now. You have to set IPForward=yes in the .network
> files explicitly now, otherwise you will not get IP forwarding on that
> interface.

Intentional or not from your perspective, from our perspective it is a regression because networkd is now overriding sysctl which up until 219 was the only mechanism for providing those settings. Although distros can update any .network files we ship to update this appropriately there isn't a practical way migrate user provided configs to the new semantics safely. The interaction between net.ipv4.conf.all.* net.ipv4.conf.default.* and net.ipv4.conf.<if>.* can depend on the timing of systemd-sysctl.service, any scripts or other services that may alter those settings, and the discovery of network devices by the kernel. We could probably some up with some script to make an educated guess and run that before the new networkd starts but it is going to be prone to error. Without a safe migration path we simply cannot ship a networkd with this behavior without breaking some subset of our user's systems.

I'm open to other ideas but the best scheme I can think of is to turn `IPForwarding` into a trinary value where the default "unset" or "kernel" or whatnot value leaves the setting untouched.
Comment 3 Lennart Poettering 2015-04-12 20:03:53 UTC
(In reply to mike@marineau.org from comment #2)

> I'm open to other ideas but the best scheme I can think of is to turn
> `IPForwarding` into a trinary value where the default "unset" or "kernel" or
> whatnot value leaves the setting untouched.

I figure I'd be Ok with such a change. But Tom has to sign off too!
Comment 4 mike@marineau.org 2015-04-13 17:19:35 UTC
(In reply to Lennart Poettering from comment #3)
> (In reply to mike@marineau.org from comment #2)
> 
> > I'm open to other ideas but the best scheme I can think of is to turn
> > `IPForwarding` into a trinary value where the default "unset" or "kernel" or
> > whatnot value leaves the setting untouched.
> 
> I figure I'd be Ok with such a change. But Tom has to sign off too!

Nick Owens wrote a patch to implement this but it needs documentation updates:
https://github.com/coreos/systemd/commit/930ab8adedbcc64b128d4dd9aaa3c53d79fd9b54
Comment 5 Lennart Poettering 2015-04-14 12:12:00 UTC
Also, the if check should be inside the link_set_ipv4_forward() call and cause an early exit, instead of link_configure...

Either way, Tom really needs to sign off on this.
Comment 6 Lennart Poettering 2015-04-24 08:56:03 UTC
*** Bug 89491 has been marked as a duplicate of this bug. ***
Comment 7 James 2015-04-24 14:54:57 UTC
> we manage the IP forwarding setting per interfac now. You have to set
> IPForward=yes in the .network files explicitly now, otherwise you will
> not get IP forwarding on that interface.

I would suggest that a less "invasive" approach, more compatible with the traditional sysctl, would be to have systemd-networkd default to _not_ configuring per interface forwarding, and then to _dis_able per interface forwarding by specifying "IPForward=no" in the .network files, when desired.

> this was an underdocumented change in 219

For the future, a bit of warning can help avoid "breakage" and unnecessary work.
Comment 8 Tom Gundersen 2015-05-15 20:46:17 UTC
I agree that a 'kernel' option makes sense to handle backwards compatibility, in the ideal future it should not be used though, so I think we should still default to 'no'.

Yup, this change should have been mentioned in the release notes, that was an oversight.
Comment 9 Radek Podgorny 2015-06-01 18:26:32 UTC
well, if the "kernel" is not the default value, there's no backwards compatibility.

i agree with james that if ipforward is not specified, systemd should just NOT touch the current (default) setting. it should do so only if you specifically select either yes or no.
Comment 10 Lennart Poettering 2015-06-08 21:13:54 UTC
github PR has been merged.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.