Network Daemon

The systemd system management daemon appeared in 2010 as a potential replacement for the venerable but outdated init. System management daemons like systemd and init perform the important role of launching necessary services when the system boots, and they listen for requests for other services while the system is running.

Systemd seems to have won the contest as the next-generation init replacement, stepping ahead of Ubuntu's Upstart project. Fedora has used systemd since version 15; other supporters include the new RHEL 7, openSUSE since 12.1, Mandriva 2011, Debian 8, Mageia 2, Gentoo, Arch Linux, and Tizen [1] [2]. Recently, even Ubuntu announced that they were moving to systemd.

In the spirit of Free Software, the recent upsurge in attention for systemd has brought in new energy from community developers working on their own innovations. Norwegian developer Tom Gundersen has added basic network functionality to the systemd project. The imaginatively named daemon systemd-networkd [3] officially became part of the systemd project in release 210. The goal of systemd-networkd is to add a means for managing network configuration through systemd. According to the developers, systemd-networkd "detects and configures network devices as they appear, as well as creating virtual network devices" [4].

Networkd is particular useful with statically configured networks. Very powerful syntax lets the admin configure the network to match existing environmental conditions – for example, on the basis of the properties of the physical network devices, the server architecture, or the virtualization type.

Currently, networkd supports static IPv4 and IPv6 addresses and dynamic IPs via DHCPv4 and IPv4LL. The daemon can even handle bridging, bonding, and VLANs with IP-in-IP and SIT (Simple Internet Transition) tunnels. When this issue went to press, the latest 214 version saw the developers add support for virtual Ethernet (veth) devices, GRE (Generic Routing Encapsulation) tunnels, and VTI (Virtual Tunnel Interface). [Ed note: systemd 215 was released after this article was written.] Networkd uses its own libraries, and these libraries will eventually be available for third-party programs [5].

© Harald Hoyer, CC-BY-SA 3.0Figure 1: Systemd developer Lennart Poettering (in 2012). The Guatemala-born German is also responsible for PulseAudio and Avahi.

Less Overhead

Networkd monitors networking both at the administrative and operational level. From an administrative point of view, the daemon detects who manages the device (systemd-networkd or some another framework), and whether the configuration is complete. From an operational point of view, the software determines whether udev has made the low-level settings, whether the device is switched on and the cable is plugged in, whether an IP is set and, if so, what that is.

No extra packages are needed on a server to assign a static IP, because the existing systemd handles the network configuration. One advantage over larger configuration tools such as Gnome NetworkManager, Wicd, or ConnMan is reduced complexity, with fewer packages to install, maintain, or patch. Operations require fewer resources as well.

Following the logic of systemd, the daemon is implemented as a service named systemd-networkd.service; systemctl activates and starts it:

systemctl enable systemd-networkd.service
systemctl start systemd-networkd.service

Like systemd service files, networkd configuration files exist in /usr/lib/systemd/network. Admins can complement them with higher priority files created locally in /etc/systemd/network. Currently, there are three types of configuration files: .link, .network, and .netdev.

.link Files

Using .link files, networkd performs basic settings on network devices (name of the network interface, MTU, Wake on LAN, modified MAC address) without having to use the services of, for example, ethtool to do so. Link files contain a [Match] block in which the admin uses simple keywords to define the units on which to apply the changes defined in the included [Link] block. The example in Listing 1 is for an Intel E1000 device with a specific MAC address. Lines 4 to 6 query the PCI slot in which the device is inserted, whether the system is running on a virtual machine, and whether the operating system is on a 64-bit system.

The desired settings in the example relate to the device name, set an MTU of 1,450 bytes, and a throughput of 10Mbps. Line 12 changes the MAC address. From a technical point of view, udev, which became part of the systemd project in 2012, performs the changes before it notifies userspace of the existence and properties of the device; this avoids potential conflicts.

A .link file may, but need not, exist for each device, because networkd additionally uses a standard link file for all devices that contains the basic policies for dealing with names and MAC addresses.

Strictly speaking, these LINK files are not part of networkd, but a udev supplement that lets the admin use a simple and self-explanatory syntax to handle lower level settings without even having to read the rules for the complex syntax and logic of udev. Here, networkd is obviously targeting the needs of maintainers who package Linux distributions; however, it equally benefits Live media that try to configure the launched system to match the current environment.

.network Files

Network files directly configure systemd-networkd. The same matching logic applies as for the LINK files: A [Match] block defines the devices on which the daemon applies the settings from the [Network] block:

[Match]
Name=en*
[Network]
DHCP=yes

This example launches DHCP for all interfaces whose names start with en. The following lines show how to set a static IP address:

[Match]
Name=enp0s25
[Network]
Address=192.168.0.34/24
Gateway=192.168.0.254

Admins are typically done with configuration at this point, and the server or VM correctly retrieves their IPs – or has them set – if systemd-networkd is enabled.