> The logic here is that when we create a new bond we will create it > with these settings, but we will not change the settings of a > preexisting bond, as that may have been created by somebody else we > don't know about so we figure better leave it alone. > > The confusing part here is that the kernel will create bond0 with > default settings, and we will then not touch that. Ideally there would > be a kernel config switch to make it not create default devices like > that, but for the moment I think the best solution is to simply call > your bond something else. So if you put bond1 everywhere instead > things should JustWork(TM).
I performed some tests, and I was able to run my system without bond interfaces. So I think there's nothing that could trigger creation of these kind of interfaces. The next thing I did was to create a .netdev file that set bond0 interface (+ the rest of config files), and here's the log: # journalctl -b | grep -i bond Mar 05 05:04:12 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : netdev ready Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving wlan0 as an active interface with an up link Mar 05 05:04:12 morfikownia kernel: IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : bond0 : could not bring up interface: Invalid argument Mar 05 05:04:12 morfikownia kernel: bonding: bond0: Enslaving eth1 as an active interface with an up link Mar 05 05:04:12 morfikownia systemd-networkd[862]: bond0 : gained carrier Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0 : DHCPv4 address 192.168.1.113/24 via 192.168.1.1 Mar 05 05:04:19 morfikownia systemd-networkd[862]: bond0 : link configured As you can see, there's nothing before it, so I don't understand why the bond0 interface has some problems. Anyway, I changed the files and set bond1 instead of bond0, and here's the log: root:~# journalctl -b | grep -i bond Mar 05 05:09:18 morfikownia kernel: bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting MII monitoring interval to 1000 Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting up delay to 5000 Mar 05 05:09:18 morfikownia kernel: bonding: bond1: Setting down delay to 5000 Mar 05 05:09:18 morfikownia systemd-networkd[945]: bond1 : netdev ready Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving wlan0 as an active interface with a down link Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : gained carrier Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : bond1 : could not bring up interface: Invalid argument Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : lost carrier Mar 05 05:09:19 morfikownia systemd-networkd[945]: bond1 : DHCPv4 connection considered system critical, ignoring request to reconfigure it. Mar 05 05:09:19 morfikownia kernel: bonding: bond1: Enslaving eth1 as an active interface with a down link Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status up for interface wlan0, enabling it in 0 ms Mar 05 05:09:20 morfikownia kernel: bonding: bond1: link status definitely up for interface wlan0, 0 Mbps full duplex Mar 05 05:09:20 morfikownia kernel: bonding: bond1: first active interface up! Mar 05 05:09:20 morfikownia systemd-networkd[945]: bond1 : gained carrier Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1 : DHCPv4 address 192.168.1.150/24 via 192.168.1.1 Mar 05 05:09:22 morfikownia systemd-networkd[945]: bond1 : link configured It's a little bit longer, and as you can see there's just bond1 info and nothing concerning bond0. Also the MAC address changed in this point -- it looks like the bond0 interface caused that problem. I thougt that the only one interface was created, but there were two of them. The bond0 interface looks like this: root:~# cat /proc/net//bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: down MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 and the other one: root:~# cat /proc/net//bonding/bond1 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: load balancing (round-robin) MII Status: up MII Polling Interval (ms): 1000 Up Delay (ms): 5000 Down Delay (ms): 5000 Slave Interface: wlan0 MII Status: up Speed: Unknown Duplex: Unknown Link Failure Count: 0 Permanent HW addr: c0:cb:38:01:f0:f5 Slave queue ID: 0 Slave Interface: eth1 MII Status: down Speed: 10 Mbps Duplex: half Link Failure Count: 0 Permanent HW addr: 3c:4a:92:00:4c:5b Slave queue ID: 0 and the bond1 works as expected as you may observe. So why the bond0 interface has been created and by what? Should that happen because the only thing that creates the bond interface is connected with systemd itself -- there's no external application that would be involved in the process.
pgpvR13K3nfTD.pgp
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel