systemd-networkd messes up networking

Bug #1713226 reported by msaxl on 2017-08-26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
network-manager (Ubuntu)
nplan (Ubuntu)
systemd (Ubuntu)
Steve Langasek

Bug Description

Since systemd-234-2ubuntu8 systemd-networkd is enabled by default.

This causes problems existing configurations
ex1: if the network has ipv6 enables (the host recieves a router advertisement), networkmanager does not configure the network anymore so you get only ipv6 and no ipv4 connections (since systemd-networkd seems to bring only the link up)

ex2: if you use systemd-nspawn and configured static ip addresses in /etc/network/interfaces, systemd-networkd adds a dhcp obtained address on the host0 adapter and a 169.254 address

For the average user both is not expected, so my solution was systemctl disable systemd-networkd, but since you seem to insist having this enabled, it must be made sure systemd-networkd does not touch existing configurations.

My suggestion is:
1) if /etc/network/interfaces contains anything other than lo -> do not enable systemd-networkd
2) if network-manager is enabled, systemd-networkd must be disabled and vice versa

Dimitri John Ledkov (xnox) wrote :

Is this on upgrades to artful? or clean-install / clean-bring up of artful?

Note that artful will no longer have ifupdown installed on clean-install, and thus /etc/network/interfaces changes for clean-installs will have no effect at all. And one should instead use netplan e.g. $ sudo netplan ifupdown-migrate
to move the system over to networkd.

The router advertisement vs networkmanager is interesting case. In practice networkd should not have configured the interface imho, if it was not told to manage it via netplan configuration. Or e.g. NetworkManager should still consider interface for management, even if it has acquired RA ipv6.

msaxl (saxl) wrote :

this was a upgrade so the ifupdown problem should not happen with clean installs.
How is the migration planned?

If for example one will do a upgrade from 16.04 to the next 18.04 such problems are a clear show stopper since breaking the network for most servers will mean needing physical access.

On my system there is nothing that puts the interface to state up, so I blame systemd-networkd being it (normal desktop system, so /etc/network/interfaces contains only a lo entry).
But after all I consider having two systems that configure the same set of network interfaces will never work reliable.
I think the best would be systemd-networkd.service conflicts network-manager.service

What is the pro of enabling systemd-networkd on desktop systems? I see advantages on server systems over ifupdown, but afaik neither gnome nor plasma has systemd-networkd integration.

Dimitri John Ledkov (xnox) wrote :


It seems that unconditional enablement and start of networkd in src:systemd.postinst has side-effects, especially when netwokr-manager is directly managing desktop systems, without netplan.

I think we should not unconditially enable and start entworkd in src:systemd.postinst, and instead have networkd enable baked into cloud-images and/or done by netcfg or the netplan generator on boot.

Changed in systemd (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
Dimitri John Ledkov (xnox) wrote :


for both examples, can you please attach the existing configs for ifupdown, network-manager, and networkd? As in the contents of /etc/network/interfaces /etc/NetworkManager and output of udevadm info on the interface and contents of /etc/systemd/network?

I want to reproduce these bugs and verify what the current behaviour is both for upgrade and clean-install cases, and figure out all the bugs / inconsistencies present to fix any upgrade/clean-install issues.

Dimitri John Ledkov (xnox) wrote :

also, we got new network-manager in artful which may have regressed.

msaxl (saxl) wrote :

Here are the files of the networkmanager systemd-networkd conflict (I already removed ifupdown, the problem is the same, so we say for sure networkmanager or systemd-networkd causes the problem)

the output of ip a is the following:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:1d:7d:c3:a3:a1 brd ff:ff:ff:ff:ff:ff
    inet6 fd12:2017:8387:0:8d6:b5ff:bf63:6389/64 scope global mngtmpaddr noprefixroute dynamic
       valid_lft 86396sec preferred_lft 14396sec
    inet6 fd12:2017:8387:0:21d:7dff:fec3:a3a1/64 scope global mngtmpaddr noprefixroute dynamic
       valid_lft 86304sec preferred_lft 14304sec
    inet6 fe80::21d:7dff:fec3:a3a1/64 scope link
       valid_lft forever preferred_lft forever

the profile that should come up has addr-gen-mode=stable-privacy, so somehow it adds another ipv6 address, but it totally ignores ipv4...

msaxl (saxl) wrote :

The example 2 in my first posting is not an bug since the package contains /lib/systemd/network/ As I wrote this only affects systemd-nspawn containers

the unexpected "thing" is that when you upgrade you do not expect a system wide configuration that is active in parallel to the "old" ifupdown configuration. To keep your old configuration someone can for example touch /etc/systemd/network/

I have no idea how to deal with that "problem", but I think that not many have such configurations and less do a container upgrade instead of a clean update. With luck the rest will be directed here by google ;)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ifupdown (Ubuntu):
status: New → Confirmed
Changed in network-manager (Ubuntu):
status: New → Confirmed
Changed in nplan (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments