.netdev Files

Even if you have to create virtual network devices, look no further than networkd. You can use *.netdev files to configure net devices, which currently means bridges, bonded interfaces, and VLANs. To build a bridge, you create a file named bridge0.netdev (the file name up to the dot is arbitrary):

[NetDev]
Name=bridge0
Kind=bridge

Also, you add the following property to all your network files:

Bridge=bridge0

This defines the device as a member and part of the bridge.

One practical application of such a network bridge is running a virtualization server when the admin needs to open up a path to the physical network for the VMs. For example, I run KVM as a virtualization platform on my computer; it uses a single physical gigabit NIC named enp6s0 (since udev 197) [6]. To add that NIC to a bridge now, I need to perform several steps, starting with static.network:

[Match]
Name=enp6s0
[Network]
Bridge=br0

The physical device enp6s0 is assigned a property "part of the bridge named br0." The bridge is a network device; a file of type netdev defines it. In my example, the br0.netdev file looks like this:

[NetDev]
Name=br0
Kind=bridge

The bridge now exists, but it still needs a valid IP address. A bridge.network file takes care of this:

[Match]
Name=br0
[Network]
Address=172.31.98.12/24
Gateway=172.31.98.250

These three small files complete the configuration, and networkd provides the connection data for the host and the VMs. This is pleasingly simple and easy to understand compared with the previously required systemd service files. For my first KVM setup with systemd on Gentoo Linux, I was forced to do battle with a mile-long service file (/etc/systemd/system/bridge.service).

At this point, I did two more things to eliminate the need for separate configurations at different locations: First, I enforced full-duplex Gigabit mode. To do so, I needed a line in the local startup script:

ethtool -s enp6s0 speed 1000 duplex fullautoneg on

Second, I enabled Wake-on-LAN (WOL) so I could power on the machine remotely. A separate systemd unit was previously needed, as you can see in Listing 2. Now, both WOL and gigabit connectivity are handled elegantly by a single networkd link file (Listing 3).

01 [Match]
02 MACAddress=38:60:77:33:11:22
03
04 [Link]
05 MTUBytes=1500
06 BitsPerSecond=1G
07 Duplex=full
08 WakeOnLan=magic

01 [Unit]
02 Description=Wake-on-LAN for %i
03 Requires=network.target
04 After=sys-subsystem-net-devices-%i.device
05
06 [Service]
07 ExecStart=/usr/sbin/ethtool -s %i wol g
08 Type=oneshot
09
10 [Install]
11 WantedBy=multi-user.target\

Objectives and Benefits

On most dedicated servers, but also on embedded devices, the network configuration is quite static for the whole service life. Once you have decided on systemd as your init system, networkd covers the entire network setup without a need to install and maintain additional packages.

Moreover, you should see better performance. On my system, the systemd-analyze tool clocked the start time of systemd-networkd at a fast 3 milliseconds. Retrieving IPs via DHCP is also fast; measurements by the developer show astonishingly short DHCP dialogs – albeit in the laboratory and without checking whether the IP is already in use somewhere else on the subnet.

If you mainly rely on virtualization at the data center, systemd-networkd opens up more options. If a virtual machine is sometimes on one physical host and sometimes on another, it is possible to use LINK files to define the correct network setup within the VM automatically, depending on the current environment.

The network configuration can take place at a very early stage, using initramfs. Combined with the very fast boot and shutdown times that are possible with systemd, networkd makes it easy to switch VMs on and off on demand. You can even manage containers using systemd-nspawn [7].

News and Views

Networkd is increasingly interacting with other systemd subsystems. The systemd-timesyncd daemon added to recent releases and the systemd-resolved daemon (still at an early stage of development) are associated closely with networkd, depending on the status of network connectivity. They ensure the correct synchronization of the system time or set the DNS server. More features are planned, including DNSSEC and M-DNS caching.

When this issue went to press, a DHCPv6 client and a DHCPv4 server were in preparation. The developers have no intention of replacing top dogs like the ISC DHCP server; instead, they are focusing on the special case of container virtualization. A host could use networkd to assign IPs to the containers it operates. Another possible application is running hotspots on mobile devices. These ideas are still under discussion and development.

The systemd-networkd developers are also talking to the maintainers of Gnome NetworkManager and ConnMan to avoid duplication and to create meaningful interfaces.