How to set up static networking with
systemd-networkd, or at least how I did
I recently switched my Fedora 21 office workstation from Fedora's
/etc/init.d/network init script based method of network setup
to using the (relatively new) systemd network setup functionality,
for reasons that I covered yesterday. The
systemd documentation is a little bit scant and not complete, so
in the process I accumulated some notes that I'm going to write
First, I'm going to assume that you're having networkd take over
everything from the ground up, possibly including giving your
physical network devices stable names. If you were previously
doing this through
udev, you'll need to comment out bits of
/etc/udev/rules.d/70-persistent-net.rules (or wherever your
system put it).
To configure your networking you need to set up two files for each
network connection. The first file will describe the underlying
.link files for
physical devices and
.netdev files for
VLANs, bridges, and so on. For physical links, you can use various
things to identify the device (I use just the MAC address, which
matches what I doing in
udev) and then set its name with '
in the '
[Link]' section. Just to make you a bit confused, the
VLANs set up on a physical device are not configured in its
The second file describes the actual networking on the device
(physical or virtual), including virtual devices associated with
it; this is done with
Again you can use various things to identify which device you want
to operate on; I used the name of the device (a
Name=<whatever>). Most of the setup will be done in the
[Network] section, including telling networkd what VLANs to create.
If you want IP aliases on a give interface, specify multiple
addresses. Although it's not documented, experimentally the last
address specified becomes the primary (default) address of the
interface, ie the default source address for traffic going out
(This is unfortunately reversed from what I expected, which was that the first address specified would be the primary. Hopefully the systemd people will not change this behavior but document it, and then provide a way of specifying primary versus secondary addresses.)
If you're setting up IP aliases for an interface, it's important
to know that
ifconfig will now be misleading. In the old approach,
alias interfaces got created (eg '
em0:0') and showed the alias
IP. In the networkd world those interfaces are not created and you
need to turn to '
ip addr list' in order to see your IP aliases.
Not knowing this can be very alarming, since in
ifconfig it looks
like your aliases disappeared. In general you can expect networkd
to give you somewhat different
ip output because
it does stuff somewhat differently.
For setting up VLANs, the
VLAN= name in your physical device's
.network file is paired up with the
in your VLAN's
.netdev file. You then create another
file with a
Name= setting of your VLAN's name to configure
the VLAN interface's IP address and so on. Unfortunately this is a
bit tedious, since your
.netdev VLAN file basically exists to set
a single value (the
Id= setting); it would be more
convenient (although less pure) if you could just put that information
into a new
[VLAN] section in the
.network file that specified
Name and Id together.
If you're uniquely specifying physical devices in
.link files (eg
with a MAC address for all of them, with no wildcards) and devices
.network files, I believe that the filenames of all of these
files are arbitrary. I chose to give my VLANs filenames of eg
em0.151 is the interface name) just in
case. As you can see, there seems to be relatively little constraint
on the interface names and I was able to match the names required
by my old Fedora
ifcfg-* setup so that I didn't have to change
any of my scripts et al.
You don't need to define a
lo interface; networkd will set one
up automatically and do the right thing.
Once you have everything set up in
/etc/systemd/network, you need
to enable this by (in my case) '
chkconfig --del network; systemctl
enable systemd-networkd' and then rebooting. If you have systemd
.service units that want to wait for networking to be up, you
also want to enable the
which does what it says in its manpage,
and then make your units depend on it in the usual way. Note that
this is not quite the same as setting your SysV init script ordering
so that your init scripts came after
network, since this service
waits for at least one interface to be plugged in to something
(unfortunately there's no option to override this). While systemd
still creates the '
pseudo-devices, they will now appear faster and with less configured
than they did with the old init scripts.
(I used to wait for the appearance of the
em0.151 device as a
sign that the underlying
em0 device had been fully configured
with IP addresses attached and so on. This is no longer the case
in the networkd world, so this hack broke on me.)
In another unfortunate thing, there's no syntax checker for networkd files and it is somewhat hard to get warning messages. networkd will log complaints to the systemd journal, but it won't print them out on the console during boot or anything (at least not that I saw). However I believe that you can start or restart it while the system is live and then see if things complain.
(Why yes I did make a mistake the first time around. It turns out
Label= setting in the
[Address] section of
files is not for a description of what the address is and does not
like 'labels' that have spaces or other funny games in them.)
On the whole, systemd-networkd doesn't cover all of the cases but
then neither did Fedora
ifcfg-* files. I was able to transform
all of my rather complex
ifcfg-* setup into networkd control files
with relatively little effort and hassle and the result came very
close to working the first time. My networkd config files have a
few more lines than my
ifcfg-* files, but on the other hand I
feel that I fully understand my networkd files and will in the
future even after my current exposure to them fades.
ifcfg-* files also contain a certain amount of black magic
and superstition, which I'm happy to not be carrying forward, and
at least some settings that turn out to be mistakes now that I've
actually looked them up.)