systemd-networkd — Network configuration

Network Daemon

© Lead Image © Giedrius Zaleckas,

© Lead Image © Giedrius Zaleckas,

Article from Issue 166/2014

The new networkd component of the systemd project supports basic network configuration. Despite its early stage of development, one thing is clear: This is a daemon with brains.

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.

Listing 1

LINK File Example


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:


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


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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Professor Knopper's Lab – Removing systemd

    The systemd service manager has been widely adopted by many Linux distros, so why would you want to remove it? The professor reveals why and how.

  • Systemd GUIs

    Graphical frontends make it easier to take full advantage of the Systemd process manager. We examine some leading tools for the KDE environment.

  • Command Line: Systemd

    Wondering what all the fuss is about systemd? We explain the basic concepts and capabilities of the new system management suite – coming soon to a distro near you.

  • iNet Wireless Daemon

    Intel's iNet wireless daemon offers virtually all of the features found in the obsolete WPA Supplicant, and it is smaller by a factor of 10.

  • systemd-homed

    Systemd has already changed almost everything about the Linux startup process. Now an experimental new feature takes on the challenge of user home directories.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More