systemd-networkd

To use systemd-networkd, start/enable .

It is optional to also configure systemd-resolved, which is a network name resolution service to local applications, considering the following points:

• It is important to understand how resolv.conf and systemd-resolved interact to properly configure the DNS that will be used, some explanations are provided in systemd-resolved.
• systemd-resolved is required if DNS entries are specified in .network files.
• systemd-resolved is also required if you want to obtain DNS addresses from DHCP servers or IPv6 router advertisements.
  (by setting ( and/or in the [Network] section, and (the default) in the corresponding section(s) , [DHCPv6], , see ).
• Note that systemd-resolved can also be used without systemd-networkd.

Enabling also enables , which is a oneshot system service that waits for the network to be configured. The latter has , so it will be started only when itself is enabled or pulled in by some other unit. See also systemd#Running services after the network is up.

By default, waits for all links it is aware of and which are managed by systemd-networkd to be fully configured or failed, and for at least one link to be online.

If your system has multiple network interfaces, but some are not expected to be connected all the time (e.g. if you have a dual-port Ethernet card, but only one cable plugged in), starting will fail after the default timeout of 2 minutes. This may cause an unwanted delay in the startup process. To change the behaviour to wait for any interface rather than all interfaces to become online, edit the service and add the parameter to the ExecStart line:

/etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any

Other behaviour such as which specific interface(s) to wait for or the operational state can be configured as well. See for the available parameters.

All configurations in this section are stored as in . For a full listing of options and processing order, see #Configuration files and .

systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use to list the devices on the system.

After making changes to a configuration file, restart .

can be used more than once to configure multiple IPv4 or IPv6 addresses. See #network files or  for more options.

In order to connect to a wireless network with systemd-networkd, a wireless adapter configured with another application such as wpa_supplicant or iwd is required.

/etc/systemd/network/25-wireless.network

[Match]
Name=wlp2s0

[Network]
DHCP=yes
IgnoreCarrierLoss=3s

If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a wired adapter.

To authenticate to the wireless network, use e.g. wpa_supplicant or iwd.

This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel to decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.

The kernel's route metric (same as configured with ip) decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).

If using IPv6, you will need to separately set the metric for the IPv6 routes too, such as:

Instead of editing udev rules, a .link file can be used to rename an interface. A useful example is to set a predictable interface name for a USB-to-Ethernet adapter based on its MAC address, as those adapters are usually given different names depending on which USB port they are plugged into.

These files are aimed at setting network configuration variables, especially for servers and containers.

.network files have the following sections: , [Link], [Network], , , and . Below are commonly configured keys for each section. See for more information and examples.

• this option is mandatory unless DHCP is used
• the destination prefix of the route, possibly followed by a slash and the prefix length

If is not present in section this section is treated as a default route.

This is an example of a DHCP server configuration which works well with hostapd to create a wireless hotspot. IPMasquerade adds the firewall rules for NAT and implies to enable packet forwarding.

These files will create virtual network devices. They have two sections: and [NetDev]. Below are commonly configured keys for each section. See for more information and examples.

• the hostname
• check if the system is running in a virtualized environment

Most common keys are:

• the interface name. mandatory
• e.g. bridge, bond, vlan, veth, sit, etc. mandatory

These files are an alternative to custom udev rules and will be applied by udev as the device appears. They have two sections: and [Link]. Below are commonly configured keys for each section. See for more information and examples.

• the MAC address
• the host name
• the device type e.g. vlan

• MACAddressPolicy= persistent or random addresses, or
• a specific address
• list of policies by which the interface name should be set, e.g. kernel, keep

First, create a virtual bridge interface with a netdev unit file. We tell systemd to create a device named br0 that functions as an ethernet bridge.

Restart to have systemd create the bridge.

To see the newly created bridge on the host and on the container, type:

Note that the interface br0 is listed but is still DOWN at this stage.

The next step is to add to the newly created bridge a network interface. Its configuration file must be loaded before those of the bridged interfaces, so its configuration file should be alphanumerically prior to those. In the example below, we add any interface that matches the name en* into the bridge br0.

The Ethernet interface must not have DHCP or an IP address associated as the bridge requires an interface to bind to with no IP: modify the corresponding accordingly to remove the addressing.

Now that the bridge has been created and has been bound to an existing network interface, the IP configuration of the bridge interface must be specified. This is defined in a third .network file, the example below uses DHCP.

/etc/systemd/network/''mybridge''.network

[Match]
Name=br0

[Network]
DHCP=ipv4

Use the option when starting the container. See systemd-nspawn#Use a network bridge for details.

• on host

• on container

• we have now one IP address for br0 on the host, and one for in the container
• two new interfaces have appeared: in the host and in the container. This comes as a result of the option as explained in systemd-nspawn#Use a network bridge for details.
• the DHCP address on comes from the system file.
• on host

the above command output confirms we have a bridge with two interfaces binded to.

• on host

• on container

the above command outputs confirm we have activated br0 and interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by systemd-networkd.

Setting a static IP address for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system /usr/lib/systemd/network/99-default.link file has the option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.

The following configuration needs to be done for this setup:

• on host

The configuration is very similar to the #Network bridge with DHCP section. First, a virtual bridge interface needs to be created and the main physical interface needs to be bound to it. This task can be accomplished with the following two files, with contents equal to those available in the DHCP section.

/etc/systemd/network/MyBridge.netdev
/etc/systemd/network/MyEth.network

Next, you need to configure the IP and DNS of the newly created virtual bridge interface. For example:

• on container

To get configure a static IP address on the container, we need to override the system file, which provides a DHCP configuration for the network interface of the container. This can be done by placing the configuration into . For example:

/etc/systemd/network/80-container-host0.network

[Match]
Name=host0

[Network]
DNS=192.168.1.254
Address=192.168.1.94/24
Gateway=192.168.1.254

Make sure that is enabled in the container.

systemd-networkd does not have a proper interactive management interface neither via command-line shell nor graphical.

Still, some tools are available to either display the current state of the network, receive notifications or interact with the wireless configuration:

• networkctl (via CLI) offers a simple dump of the network interface states.
• When networkd is configured with wpa_supplicant, both wpa_cli and wpa_gui offer the ability to associate and configure WLAN interfaces dynamically.
• can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association).
• The daemon allows executing scripts in response to network interface state changes, similar to NetworkManager-dispatcher.
• As for the DNS resolver systemd-resolved, information about current DNS servers can be visualized with .

Often there is a situation where your home wireless network uses DHCP and office wireless network uses static IP. This mixed setup can be configured as follows:

See also Wireless bonding.

Bonding allows connection sharing through multiple interfaces, so if e.g. the wired interface is unplugged, the wireless is still connected and the network connectivity remains up seamlessly.

Create a bond interface. In this case the mode is active-backup, which means packets are routed through a secondary interface if the primary interface goes down.

/etc/systemd/network/30-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
PrimaryReselectPolicy=always
MIIMonitorSec=1s

Set the wired interface as the primary:

Set the wireless as the secondary:

Configure the bond interface as you would a normal interface:

Now if the wired network is unplugged, the connection should remain through the wireless:

On a higher bandwidth link with moderate latency (typically a home Internet connection that is above 10 Mbit/s) the default settings for the TCP Slow Start algorithm are somewhat conservative. This issue exhibits as downloads starting slowly and taking a number of seconds to speed up before they reach the connection's full bandwidth. It is particularly noticeable with a pacman upgrade, where each package downloaded starts off slowly and often finishes before it has reached the connection's full speed.

These settings can be adjusted to make TCP connections start with larger window sizes than the defaults, avoiding the time it takes for them to automatically increase on each new TCP connection. While this will usually decrease performance on slow connections (or if the values are increased too far) due to having to retransmit a larger number of lost packets, they can substantially increase performance on connections with sufficient bandwidth.

It is important to benchmark before and after changing these values to ensure it is improving network speed and not reducing it. If you are not seeing downloads begin slowly and gradually speed up, then there is no need to change these values as they are already optimal for your connection speed. When benchmarking, be sure to test against both a high speed and low speed remote server to ensure you are not speeding up access to fast machines at the expense of making access to slow servers even slower.

To adjust these values, edit the .network file for the connection:

The defaults of work well for connections slower than 10 Mbit/s. For a 100 Mbit/s connection, a value of 30 works well. The manual page says a value of is considered excessive.

If the sysctl setting net.ipv4.tcp_slow_start_after_idle is enabled then the connection will return to these initial settings after it has been idle for some time (and often a very small amount of time). If this setting is disabled then the connection will maintain a higher window if a larger one was negotiated during packet transfer. Regardless of the setting, each new TCP connection will begin with the settings set above.

The sysctl setting is not directly related to these values, as it controls how the congestion and receive windows are adjusted while a TCP link is active, and particularly when the path between the two hosts is congested and throughput must be reduced. The above values simply set the default window values selected for each new connection, before any congestion algorithm takes over and adjusts them as needed. Setting higher initial values simply shortcuts some negotiation while the congestion algorithm tries to find the optimum values (or, conversely, setting the wrong initial values adds additional negotiation time while the congestion algorithm works towards correcting them, slowing down each newly established TCP connection for a few seconds extra).