Broken network support in systemd networkd+nspawn #404

LEW21 opened this Issue Jul 4, 2015 · 7 comments


None yet

4 participants

LEW21 commented Jul 4, 2015

Nspawn-based containers executed on CoreOS (with systemd-nspawn@.service) currently are unable to access the network. There are 2 reasons:

  1. /usr/lib/systemd/network/ has a higher priority than systemd's - which means it's used instead of the systemd's one, and networkd does not try to setup the containers network.
    • This can be easily workarounded by symlinking to /etc/systemd/network/, so it's not a big problem (but still probably should get fixed).
  2. systemd-networkd is built without iptables support ("nat" portage flag), which means it's unable to provide IP masquerading support for containers.
    • This is a deal breaker, as manually setting up masquerading is quite hard.
mischief commented Jul 4, 2015

@LEW21 can you give a simple example to reproduce the problem?

LEW21 commented Jul 4, 2015
cd /var/lib/machines
mkdir archlinux
cd archlinux
tar -xf archlinux.tar.xz

machinectl start archlinux
machinectl login archlinux
#archlinux login: root
#Password: a

Without the first part, networkctl reports "degraded" status:

networkctl status -a # on host
# Output contains: State: degraded (configured)

networkctl status -a # on container
# Output contains: State: degraded (configuring)

Without the second part, networkd cries about IP masquerading:

journalctl -u systemd-networkd -b # on host
# Output contains: ve-archlinux: Could not enable IP masquerading: Operation not supported

Additional note: Container's networkd also complains that
host0: Cannot configure IPv4 forwarding for interface host0: Read-only file system
But this is not a problem, on my home Arch host I also get those warnings in containers - and everything works. So this can be ignored.


@LEW21 have you tried to reproduce this since nat flag was enabled?

LEW21 commented Mar 23, 2016

Flag fixed the 2nd problem, and I'm now constantly using nspawn containers on CoreOS.

However, the 1st problem still exists (and I'm using the symlink workaround).


do you know what (if anything) happens to docker containers launched when you make that symlink?

i'm worried that if it is changed, there will be unintended side effects for other folks.

LEW21 commented Mar 23, 2016 matches devices named "ve-", and docker calls them "veth" - so they never get matched, and those settings are not applied to them.

Therefore there should be no side effects.


Yeah, let's move Docker to /usr/lib/systemd/network/

@dm0- dm0- self-assigned this Dec 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment