Bug 82956 - systemd-networkd ignores bond0's initial mode
Summary: systemd-networkd ignores bond0's initial mode
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium major
Assignee: Tom Gundersen
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-22 16:20 UTC by Antony Messerli
Modified: 2017-11-20 16:34 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Antony Messerli 2014-08-22 16:20:31 UTC
systemd-networkd ignores bond0's initial mode that has been set in the configuration file.  By default when the bonding module is loaded, it appears to load bond0 as it's default roundrobin mode.  If I've set Mode=802.3ad in the configuration file, it ignores it since it assumes that bond0 has already been configured.

/etc/systemd/network/10-create-bond1.network:
[Match]
Name=enp1s0f[01]

[Network]
Bond=bond1

/etc/systemd/network/20-bond1.netdev:
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
LACPTransmitRate=fast
MIIMonitorSec=1s
UpDelaySec=2s
DownDelaySec=8s

In this case, I have to load bonding with the configuration I want to start with for bond0:

modprobe bonding mode=4 mii=100 lacp_mode=1 

That or I have to skip bond0 and start with bond1 as my configuration.
Comment 1 Susant Sahani 2014-08-22 16:36:43 UTC
there is a issue with conf:

/etc/systemd/network/10-create-bond1.network:
[Match]
Name=enp1s0f[01]

[Network]
Bond=bond1 <====================== here bond1

/etc/systemd/network/20-bond1.netdev:
[NetDev]
Name=bond0 <================it's bond0
Kind=bond

Could you try with same name for example 'bond0' and let us know if it works for you ?
Comment 2 Antony Messerli 2014-08-22 16:50:27 UTC
Yeah, my mistake, I totally copied that in wrong:

/etc/systemd/network/10-create-bond0.network:
[Match]
Name=enp1s0f[01]

[Network]
Bond=bond0
EOF

/etc/systemd/network/10-bond0.netdev:
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
LACPTransmitRate=fast
MIIMonitorSec=1s
UpDelaySec=2s
DownDelaySec=8s

If you remove the module with modprobe -r bonding and then reload with modprobe bonding, you'll see by default it does load up a bond0 by default.  If you check /proc/net/bonding/bond0 and then reload systemd-networkd to reconfigure, you'll see that the setting is still set the default of roundrobin and doesn't pick up the 802.3ad setting.

Adding a modules.d/bonding.conf with the settings I want to bond0 does appear to get around this.
Comment 3 Susant Sahani 2014-08-22 17:14:04 UTC
This is expected . The modes only applied only when freshly created bond with networkd.
Comment 4 Susant Sahani 2014-08-22 17:17:31 UTC
Tom added this to the man  http://cgit.freedesktop.org/systemd/systemd/commit/?id=7c1cff4 . Sorry forgot to add in the previous comment.
Comment 5 Antony Messerli 2014-08-22 17:20:16 UTC
Right, but by default with nothing configured, loading the bonding module appears to create a generic bond0.

For someone attempting to set up a new configuration in systemd-networkd on a bond0 device, this prevents settings in the [Bond] section from ever getting applied.

I would think that either the bonding module shouldn't load a default bond0 when the module is loaded or systemd-networkd should handle the case where when initially loading the bonding module, that it knows that bond0 has been loaded with some generic settings and that a configuration needs to be applied to it.
Comment 6 Susant Sahani 2014-08-22 17:24:42 UTC
Well the bond module get auto loaded . We don't have to load it via modprobe explicitly. 

a unused name should work in this scenario
Comment 7 Antony Messerli 2014-08-22 17:42:48 UTC
I'd like to use the unused bond0 in this case as if I utilize bond1, I still have a loaded bond0 device lingering around.

If I set up a modprobe.d options file, then things work as expected with bond0:

/etc/modprobe.d/bonding.conf

options bonding miimon=100
options bonding lacp_rate=1
options bonding mode=4

Just seems a bit hacky since that's what networkd should be able to handle with having to set up a modprobe.d file.
Comment 8 Susant Sahani 2014-08-22 18:42:10 UTC
hmmm looks like for the name 'bond0 'it's not working . Can you confirm it works with other bond names ? like bond1 , test-bond etc ?
Comment 9 Antony Messerli 2014-08-22 19:25:20 UTC
Yeah it works fine with all the other bonds.  I tested bond1 and bond2 when bond0 was acting weird and that's how I narrowed the issue to bond0 and it being loaded by default with no configuration.
Comment 10 Susant Sahani 2014-08-22 19:30:26 UTC
Thanks I was debugging this . What it appears is when the bond module gets loaded it's picks the bond parameters from the module params rather than netlink attributes. Later on kernel does not support to update the attributes passed via netlink . That's why bond0 is behaving this way. But if we try to create with other names this does work. I guess this makes sense. Thanks for the information.
Comment 11 Tom Gundersen 2014-10-27 10:23:24 UTC
We should requset a new kernel config making it possible to disable the "autocreation" of dummy netdevs when the modules get loaded.
Comment 12 Susant Sahani 2015-03-08 02:43:04 UTC
Please try with module parameters

options bonding max_bonds=0.
This should stop creating the bond0
Comment 13 Sébastien Luttringer 2015-04-29 22:38:35 UTC
I tested with max_bonds=0 and it works.

Adding this parameters offer something expected. I mean:
- having bond0 works like other bonds
- duplicate configuration in module config and networkd config.
- allow multiple bond mode configuration without aliasing

I guess the rational behind "we don't touch existing bond/brigdes" is to prevent breakage of a network connection.

I the other hand it's confusing to have a different behaviour for bond0. For sure because the kernel create a free iface. I spend some times to understand that systemd-networkd doesn't honnor its configuration parameters.

I think we could at least add a warning saying that we don't create/update the bond/bridge because it already exists, and we will not honor configuration.

If we keep in mind that we don't honor configuration, networkctl print the bond has "configured" (green colored). This is misleading, because in fact it has not been configured by networkd.
Comment 14 jeff 2015-06-12 15:22:38 UTC
I just ran into this today with a new Fedora 22 system and lost a lot of time debugging.  I think that at least there needs to be more warning given by systemd-networkd that parts of the configuration aren't being applied because it conflicts with pre-existing settings, or there needs to be a mode for systemd-networkd where it takes complete control and overrides pre-existing settings.
Comment 15 Lennart Poettering 2017-11-20 16:34:30 UTC
I guess we can call this fixed by https://github.com/systemd/systemd/pull/6448.


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.