Bug#818978: New issues with bridges in Debian Jessie/Stretch

[Maciej Delmanowski]

On Feb 28, Michael Biebl wrote:
>>>     allow-hotplug br0
>> 
>> Using allow-hotplug for bridge interfaces is not a good idea. You really
>> should use that for physical hardware only, which actually is "plugged in".
>> 
>> If you want to treat it like hotplugged hardware, you have to create the
>> interfaces yourself (using brctl), as you already noted.
>> 
>> So, this is really a misconfiguration imho.
>> 
>> Use "auto br0" and you should be fine.

Unfortunately, using ifupdown auto/hotplug configuration complicates things
when 'systemd' is introduced. To summarize explanation found in

https://lists.debian.org/debian-user/2015/04/msg01208.html:

The 'auto <interface>' stanza is used by the 'networking.service' which starts
network interfaces on boot. All of the network interface processes, like
'dhclient', started this way end up in one 'networking.service' CGroup. The
downside of this is that modifications to interface layout need to stop and
start all of the network interfaces at once, using 'networking.service'. This
might not apply anymore on Debian Stretch, but it still applies in Debian
Jessie.

The 'hotplug <interface>' stanza is used by the 'ifup at .service' which starts
each network interface processes, like 'dhclient', in its own separate CGroup.
This allows modification of each network interface separately and doesn't
result in disruption in connectivity when non-default network interfaces are
modified.

One problem with this is that the 'ifup at .service' interfaces are not brought
up automatically at boot. For this, I created a separate 'systemd' service

https://github.com/debops/ansible-ifupdown/blob/master/templates/etc/systemd/system/ifup-allow-boot.service.j2

This service is executed just after `networking.service` and brings up all
network interfaces marked as 'allow-boot' using calls to `ifup at .service`
units. The current mechanism is probably horrible, shelling out to start
another service unit doesn't seem like an efficient idea, is there a better
interface for this? Anyhow, this mechanism works as long as the interfaces are
marked as 'allow-hotplug', otherwise 'ifup at .service' doesn't even touch
a given interface due to the use of '--allow=hotplug' in the unit arguments.

The above changes are very important to me because I'm using Ansible to modify
network interface configuration remotely. Without these changes remote network
configuration becomes unreliable, there's no way to be sure if there's no
rough 'dhclient' process for a given network interface that might mess up
networking. Using separate CGroups for each network interface makes network
configuration reliable.

I've checked your suggestion with dropping the 'hotplug br0' and adding the
'auto br0' stanza for the bridge, and this solution works, but the result is
that the 'dhclient' process ends up in the 'networking.service' CGroup.

I suppose that a solution for this would be for my custom service to create
the bridge interface manually before calling 'ifup at br0.service', but that
doesn't fix the usage later when the service can be stopped and started
separately. Directly creating the symlinks for each network interface in
'/etc/systemd/system/' won't work either because the 'ifup at .service' only runs
for network interfaces marked with 'allow-hotplug'.

Guus Sliepen <guus at debian.org> wrote:
> > > It seems that the latest changes in the 'systemd' package result in issues
> > > with configuration of network bridges. I can reproduce this issue reliably on
> > > Debian Jessie KVM guest, and most likely on Debian Stretch KVM guest (haven't
> > > tried repeatedly yet).
> Hm, what does this have to do with bug 818978, which is about systemd
> crashing in LXC containers?

I'm not sure if it's directly related to this bug. Perhaps its due to other
changes introduced in the 215-17+deb8u6 version of the 'systemd' package.
After checking the changelog for the Debian Jessie package
http://metadata.ftp-master.debian.org/changelogs/main/s/systemd/systemd_215-17+deb8u6_changelog
it seemed to be the only related change. I wasn't able to get the
215-17+deb8u5 version from snapshot.debian.org for some reason, but
215-17+deb8u4 version worked without the issue.

Any suggestions on how to proceed would be appreciated.

Thanks for your work and best regards,
Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170228/36581292/attachment-0002.sig>