Bug 80007

Summary:	systemd-networkd: networkd can't create bond from 2 auto configured interfaces post-boot
Product:	systemd	Reporter:	Sean P. Kane <spkane00>
Component:	general	Assignee:	Tom Gundersen <teg>
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	major
Priority:	medium	CC:	simon.lallemand, spkane00
Version:	unspecified
Hardware:	All
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Sean P. Kane 2014-06-13 23:37:07 UTC

CoreOS related bug filing: 
https://github.com/coreos/bugs/issues/36

Using cloud-init to setup network and netdev units for bonded interfaces does not work as expected, since networkd does not ifdown interfaces that it did not setup.

This means that a physical system with 2 nics that is netbooted with a plain CoreOS image will have those interfaces setup during boot automatically by udev(?) and when cloud-init sets up a bond and then restarts networkd, networkd, does not ifdown eno1 and eno2, which means they can not be enslaved to the bond and things fail to come up properly.

networkd could likely continue to ignore devices it knows nothing about, but assume that it is safe to down interfaces that it now has configuration for, even if it didn't initially bring them up.

A bit more documentation:
https://gist.github.com/spkane/8f117f67533822b2481f

Comment 1 Sean P. Kane 2014-06-13 23:42:56 UTC

It also appears that if the bond is setup to use DHCP, that it doesn't wait long enough for link to be established after the interface is upped before requesting DHCP, and therefore the bond has no IP. A second netword restart works fine, since the interfaces are already up. (Not completely sure if this is a networkd or linux dist issue)

Comment 2 Tom Gundersen 2014-06-19 16:11:24 UTC

Hm, we probably should try to be more clever about this. However, could you explain how come the interfaces are up in the first place. This sounds strange?

Comment 3 Sean P. Kane 2014-07-17 23:03:21 UTC

Sorry for the delay, I never got a notification of your reply.

I am pretty sure that the initial setup is done via udev.

http://coreos.com/blog/intro-to-systemd-networkd/

Comment 4 Simon Lallemand 2015-03-11 08:07:10 UTC

I'm also impacted by this bug.
I don't think that the reasons for which the interfaces are up matters here. Take the case when someone configures an interface manually and then decides to use networkd, I think that case should be handled.

I'm not sure if networkd should set down the interfaces for which it has a new config when stopping or if it should ensure when starting that all the interfaces it will be configuring are down. But doing nothing about these interfaces and failing doesn't seem the good solution.

Comment 5 Sam Tresler 2015-03-13 18:52:24 UTC

To add a little more color to this issue, that I am also affected by, it is very common to have the interfaces up when attempting to apply a new configuration, many times it is the only way. 

For example, a common server provisioning workflow might be: 

Power On
DHCP single interface
tftp and pxeboot into the OS
Cloud-init writes the .network and .netdev files to the appropriate locations
restart networking to come up with bonding

With this current issue the network restart doesn't create the bond as desired. 

For now, as a workaround, I'm adding a tiny bash script that does this during the provisioning sequence, but would love to see a fix to this in the future. Thanks.

Comment 6 Yu Watanabe 2019-08-19 15:12:10 UTC

It seems this is already fixed.

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.