Bug 82956

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 ?

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.

This is expected . The modes only applied only when freshly created bond with networkd.

Tom added this to the man  http://cgit.freedesktop.org/systemd/systemd/commit/?id=7c1cff4 . Sorry forgot to add in the previous comment.

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.

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

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.

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 ?

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.

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.

We should requset a new kernel config making it possible to disable the "autocreation" of dummy netdevs when the modules get loaded.

Please try with module parameters

options bonding max_bonds=0.
This should stop creating the bond0

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.

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.

I guess we can call this fixed by https://github.com/systemd/systemd/pull/6448.