Introduction to networkd, network management from systemd

• 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

The [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.

The default .link file is /usr/lib/systemd/network/99-default.link . It applies to all devices and only specifies MACAddressPolicy and NamePolicy .

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 [Match] section.

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 ( eth0 , 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 MACAddress and Name that udev has set for our device.

Lets have a look at a basic .network file:

[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., Virtualization , Host and 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.

Bridge

Imagine you want to create a bridge and add your ethernet devices to it. You would then drop in a .netdev file:

[NetDev] Name=bridge0 Kind=bridge

And set 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.

VLAN

Similarly, if you want to set up two VLAN's, you'd create two .netdev files:

[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.

Future plans

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.