Introduction to networkd, network management from systemd
February 25, 2014 · By Tom Gundersen
As of version 210, systemd now includes support for basic network configuration through udev and networkd. CoreOS sponsored the development of networkd. It will soon be available in CoreOS, so we would like to take the opportunity to introduce some of its features.
Configuring low-level network device settings
As an alternative to custom udev rules, udev now applies some common low-level configuration to network device as the devices appear. To specify the settings, drop
.link files into
/etc/systemd/network/. Let’s have a look at an example and then go through the options:
[Match] MACAddress=12:34:56:78:9a:bc Driver=brcmsmac Path=pci-0000:02:00.0-* Type=wlan Virtualization=no Host=my-laptop Architecture=x86-64 [Link] Name=wireless0 MTUBytes=1450 BitsPerSecond=10M WakeOnLan=magic MACAddress=cb:a9:87:65:43:21
[Match] section expresses that this file will match any wireless device with the given MAC address, using the
brmsmac driver and connected to the given pci bus, when running on a non-virtualized 64bit x86 machine with hostname
my-laptop. When such a device appears, the
[Link] section says that udev will rename it to
wireless0, change its MTU, speed and MAC address and enable Wake-On-Lan. All this happens before udev notifies the rest of userspace about the device, to avoid confusion due to, e.g., changing interface name and MAC address.
Two further keys deserve special mention: When
MACAddressPolicy=persistent is given and the device has a random MAC address set by the kernel at boot, udev will reset it to one which is also random, but guaranteed to be the same for the given device between boots. Conversely,
MACAddressPolicy=random instructs udev to always reset the MAC address to a different random one on each boot. Lastly,
NamePolicy controls how the interface will be assigned a persistent name, if at all. It takes an ordered list of policies, and the first successful one is used to determine the name.
.link file is
/usr/lib/systemd/network/99-default.link. It applies to all devices and only specifies
Unlike udev rule files, only one
.link file is applied to a given device. Namely the first one (in alphabetical order) that matches according to its
Setting up network connections
A new system daemon, networkd, supports setting up some basic (and some not so basic) network configurations. The support is mostly aimed at servers and containers, so it is a great fit for CoreOS.
networkd is configured using .network files, which work similarly to
.link files described above. The same matching logic applies, with one additional option: namely to match on the interface name, using the
Name key. It is worth noting that it is not safe to match on the names given by the kernel (
eth1,…) as these may change between reboots. The only exception to warning is if you are matching on all of them with
Name=eth*. Also, we should note that networkd is only made aware of new network devices after udev has applied its low-level settings to them, so we can safely match on the new
Name that udev has set for our device.
Lets have a look at a basic
[Match] Name=en* [Network] DHCP=yes
This will start DHCP on each interface whose name starts with
en, which is the scheme used by udev’s naming policies to name ethernet devices.
If you want to set up a static address on a specific device you could use:
[Match] Name=enp2s0 [Network] Address=192.168.0.15/24 Gateway=192.168.0.1
Lastly, if you want to set up the static address on
enp2s0, and use DHCP for everything else, you would use the two above
.network files, but make sure they are ordered correctly. E.g., name the first one
20-dhcp.network and the second
10-static.network, to make sure the static configuration matches
enp2s0 before the dhcp one does. As for
.link files, only the first matching
.network file is applied.
Bridging, bonding and VLANs
The last feature of networkd I’d like to highlight is the support for creating and using virtual network devices.
Virtual network devices are created using
.netdev files, which also support a limited form of the matching logic described above. More precisely, as there is no hardware to match on, they only support matching on their environment, i.e.,
Architecture. This means that with the same configuration you can get different setups on different machines, or depending on whether or not we are running in a container, etc.
Imagine you want to create a bridge and add your ethernet devices to it. You would then drop in a
[NetDev] Name=bridge0 Kind=bridge
Bridge=bridge0 in the
.network files applied to your devices. Under this setup, networkd will create
bridge0 as soon as it starts, and add all your matching devices to it as they appear.
Similarly, if you want to set up two VLAN’s, you’d create two
[NetDev] Name=vlan1 Kind=vlan [VLAN] Id=1
[NetDev] Name=vlan2 Kind=vlan [VLAN] Id=2
And in your
.network file you would set
VLAN=vlan1 vlan2, to create the VLANs when your device appears.
This is only the beginning! We are hard at work at adding more features, so any suggestions, feature requests or patches are very welcome. In the short-term we are looking forward to adding DHCP6 and IPv4LL support, introspection both via a library and via dbus, and runtime control via dbus and a commandline client.