systemd-networkd — Network configuration
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:
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) . To add that NIC to a bridge now, I need to perform several steps, starting with
[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 (
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 .
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.
- systemd: http://freedesktop.org/wiki/Software/systemd/
- "Init Systems" by Kristian Kißling, Linux Pro Magazine, issue 156, November 2013, p. 42, http://www.linuxpromagazine.com/Issues/2013/156/Init-Systems
- Networkd commits: http://lists.freedesktop.org/archives/systemd-commits/2013-November/004659.html
- systemd-networkd: https://wiki.archlinux.org/index.php/Systemd-networkd#network_files
- Introduction to networkd: https://coreos.com/blog/intro-to-systemd-networkd/
- Predictable network interface names: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
- systemd-nspawn: https://www.youtube.com/watch?v=s7LlUs5D9p4/
Buy this article as PDF
Popular open source encryption tool is vulnerable to attack
New “Yakkety Yak” edition emphasizes cloud and servers
Google finally enters the phone hardware business.
Innovative system adds a hard drive and Ubuntu Core to the RPi for an IoT hub.
Linux is two weeks younger than we thought!
The Apache Software Foundation considers retiring OpenOffice
Adobe won’t kill the plugin in 2017
Linux Foundation's big event celebrates the 25th anniversary of Linux
Linux has evolved from “won’t be a professional” project to one of the most professional software projects in the history of computers.