systemd-networkd

From ArchWiki
Jump to navigation Jump to search

systemd-networkd is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by systemd-nspawn or for virtual machines. It also works fine on simple connections.

Basic usage

The systemd package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters, covered later in this article, can be set up by services, such as wpa_supplicant or iwd.

Required services and setup

To use systemd-networkd, start/enable systemd-networkd.service.

Note: You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with systemctl --type=service and then stop them.

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

  • The systemd-resolved service is required if DNS entries are specified in .network files.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: IPv6 router advertisements are unrelated to domain name resolution. What would systemd-resolved do with that? (Discuss in Talk:Systemd-networkd#)
  • systemd-resolved is also required if you want to obtain DNS addresses from DHCP servers or IPv6 router advertisements (by setting IPv6AcceptRA= in the [Network] section, and, in their own section, setting UseDNS=yes (the default)).
  • 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.
  • Note that systemd-resolved can also be used without systemd-networkd.

Configuration examples

All configurations in this section are stored as foo.network in /etc/systemd/network/. For a full listing of options and processing order, see #Configuration files and systemd.network(5).

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

After making changes to a configuration file, restart systemd-networkd.service.

Note:
  • The options specified in the configuration files are case sensitive.
  • In the examples below, enp1s0 is the wired adapter and wlp2s0 is the wireless adapter. These names can be different on different systems. See Network_configuration#Network_interfaces for checking your adapter names.
  • It is also possible to use a wildcard, e.g. Name=en*.
  • If you want to disable IPv6, see IPv6#systemd-networkd.

Wired adapter using DHCP

/etc/systemd/network/20-wired.network
[Match]
Name=enp1s0

[Network]
DHCP=yes

Wired adapter using a static IP

/etc/systemd/network/20-wired.network
[Match]
Name=enp1s0

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1
#DNS=8.8.8.8

Address= can be used more than once to configure multiple IPv4 or IPv6 addresses. See #network files or systemd.network(5) for more options.

Wireless adapter

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

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

Wired and wireless adapters on the same machine

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).

Note: The Metric option is for static routes while the RouteMetric option is for setups not using static routes. See systemd.network(5) for more details.
/etc/systemd/network/20-wired.network
[Match]
Name=enp1s0

[Network]
DHCP=yes

[DHCP]
RouteMetric=10
/etc/systemd/network/25-wireless.network
[Match]
Name=wlp2s0

[Network]
DHCP=yes

[DHCP]
RouteMetric=20

Renaming an interface

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.

/etc/systemd/network/10-ethusb0.link
[Match]
MACAddress=12:34:56:78:90:ab

[Link]
Description=USB to Ethernet Adapter
Name=ethusb0
Note: Any user-supplied .link must have a lexically earlier file name than the default config 99-default.link in order to be considered at all. For example, name the file 10-ethusb0.link and not ethusb0.link.

Configuration files

Configuration files are located in /usr/lib/systemd/network/, the volatile runtime network directory /run/systemd/network/ and the local administration network directory /etc/systemd/network/. Files in /etc/systemd/network/ have the highest priority.

There are three types of configuration files. They all use a format similar to systemd unit files.

  • .network files. They will apply a network configuration for a matching device
  • .netdev files. They will create a virtual network device for a matching environment
  • .link files. When a network device appears, udev will look for the first matching .link file

They all follow the same rules:

  • If all conditions in the [Match] section are matched, the profile will be activated
  • an empty [Match] section means the profile will apply in any case (can be compared to the * wildcard)
  • all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live
  • files with identical name replace each other
Tip:
  • Files in /etc/systemd/network/ override the corresponding system-supplied file in /usr/lib/systemd/network/. You can also create a symlink to /dev/null to "mask" a system file.
  • systemd accepts the values 1, true, yes, on for a true boolean, and the values 0, false, no, off for a false boolean

network files

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

.network files have the following sections: [Match], [Link], [Network], [Address], [Route], and [DHCP]. Below are commonly configured keys for each section. See systemd.network(5) for more information and examples.

[Match]

Parameter Description Accepted Values Default Value
Name= Match device names, e.g. en*. By prefixing with !, the list can be inverted. white-space separated device names with globs, logical negation (!)
MACAddress= Match MAC addresses, e.g. MACAddress=01:23:45:67:89:ab 00-11-22-33-44-55 AABB.CCDD.EEFF whitespace-separated MAC addresses in full colon-, hyphen- or dot-delimited hexadecimal
Host= Match the hostname or machine ID of the host. hostname string with globs, machine ID
Virtualization= Check whether the system is executed in a virtualized environment. Virtualization=false will only match your host machine, while Virtualization=true matches any container or VM. It is possible to check for a specific virtualization type or implementation. boolean, logical negation (!), type (vm, container), implementation (qemu, kvm, zvm, vmware, microsoft, oracle, xen, bochs, uml, bhyve, qnx, openvz, lxc, lxc-libvirt, systemd-nspawn, docker, podman, rkt, wsl, acrn)

[Link]

  • MACAddress= useful for MAC address spoofing
  • MTUBytes= setting a larger MTU value (e.g. when using jumbo frames) can significantly speed up your network transfers
  • Multicast= allows the usage of multicast on interface(s)

[Network]

Parameter Description Accepted Values Default Value
DHCP= Controls DHCPv4 and/or DHCPv6 client support. boolean, ipv4, ipv6 false
DHCPServer= If enabled, a DHCPv4 server will be started. boolean false
MulticastDNS= Enables multicast DNS support. When set to resolve, only resolution is enabled, but not host or service registration and announcement. boolean, resolve false
DNSSEC= Controls DNSSEC DNS validation support on the link. When set to allow-downgrade, compatibility with non-DNSSEC capable networks is increased, by automatically turning off DNSSEC in this case. boolean, allow-downgrade false
DNS= Configure static DNS addresses. May be specified more than once. inet_pton(3)
Domains= A list of domains which should be resolved using the DNS servers on this link. more information domain name, optionally prefixed with a tilde (~)
IPForward= If enabled, incoming packets on any network interface will be forwarded to any other interfaces according to the routing table. See Internet sharing#Enable packet forwarding for details. boolean, ipv4, ipv6 false
IPMasquerade= If enabled, packets forwarded from the network interface will appear as coming from the local host. Implies IPForward=ipv4. boolean false
IPv6PrivacyExtensions= Configures use of stateless temporary addresses that change over time (see RFC 4941). When prefer-public, enables the privacy extensions, but prefers public addresses over temporary addresses. When kernel, the kernel's default setting will be left in place. boolean, prefer-public, kernel false

[Address]

  • Address= this option is mandatory unless DHCP is used

[Route]

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

If Destination is not present in [Route] section this section is treated as a default route.

Tip: You can put the Address= and Gateway= keys in the [Network] section as a short-hand if [Address] section contains only an Address key and [Route] section contains only a Gateway key.

[DHCP]

Parameter Description Accepted Values Default Value
UseDNS= controls whether the DNS servers advertised by the DHCP server are used boolean true
Anonymize= when true, the options sent to the DHCP server will follow the RFC7844 (Anonymity Profiles for DHCP Clients) to minimize disclosure of identifying information boolean false
UseDomains= controls whether the domain name received from the DHCP server will be used as DNS search domain. If set to route, the domain name received from the DHCP server will be used for routing DNS queries only, but not for searching. This option can sometimes fix local name resolving when using systemd-resolved boolean, route false

[DHCPServer]

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 IPForward=ipv4 to enable packet forwarding.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: IPMasquerade=true does not add the rules for the filter table, they have to be added manually. See systemd-nspawn#Use a virtual Ethernet link. (Discuss in Talk:Systemd-networkd#)
/etc/systemd/network/wlan0.network
[Match]
Name=wlan0

[Network]
Address=10.1.1.1/24
DHCPServer=true
IPMasquerade=true

[DHCPServer]
PoolOffset=100
PoolSize=20
EmitDNS=yes
DNS=9.9.9.9

netdev files

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

[Match] section

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

[NetDev] section

Most common keys are:

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

link files

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

Tip: Use udevadm test-builtin net_setup_link /sys/path/to/network/device as the root user to diagnose problems with .link files.

[Match] section

  • MACAddress= the MAC address
  • Host= the host name
  • Virtualization=
  • Type= the device type e.g. vlan

[Link] section

  • MACAddressPolicy= persistent or random addresses, or
  • MACAddress= a specific address
  • NamePolicy= list of policies by which the interface name should be set, e.g. kernel, keep
Note: the system /usr/lib/systemd/network/99-default.link is generally sufficient for most of the basic cases.

Usage with containers

systemd-networkd can provide fully automatic configuration of networking for systemd-nspawn containers when it is used on the host system as well as inside the container. See systemd-nspawn#Networking for a comprehensive overview.

For the examples below,

  • we will limit the output of the ip a command to the concerned interfaces.
  • we assume the host is your main OS you are booting to and the container is your guest virtual machine.
  • all interface names and IP addresses are only examples.

Network bridge with DHCP

Bridge interface

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

/etc/systemd/network/mybridge.netdev
[NetDev]
Name=br0
Kind=bridge
Tip: systemd-networkd assigns a MAC address generated based on the interface name and the machine ID to the bridge. This may cause connection issues, for example in case of routing based on MAC filtering. To circumvent such problems you may assign a MAC address to your bridge, probably the same as your physical device, adding the line MACAddress=xx:xx:xx:xx:xx:xx in the NetDev section above.

Restart systemd-networkd.service to have systemd create the bridge.

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

$ ip a
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff

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

Bind ethernet to bridge

The next step is to add to the newly created bridge a network interface. In the example below, we add any interface that matches the name en* into the bridge br0.

/etc/systemd/network/bind.network
[Match]
Name=en*

[Network]
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 /etc/systemd/network/MyEth.network accordingly to remove the addressing.

Bridge network

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

Configure the container

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

Result

  • on host
$ ip a
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.87/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::16da:e9ff:feb5:7a88/64 scope link 
       valid_lft forever preferred_lft forever
6: vb-MyContainer: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d07c:97ff:fe97:3725/64 scope link 
       valid_lft forever preferred_lft forever
  • on container
$ ip a
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.73/24 brd 192.168.1.255 scope global host0
       valid_lft forever preferred_lft forever
    inet6 fe80::5c96:85ff:fe83:a85d/64 scope link 
       valid_lft forever preferred_lft forever

Notice

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

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: brctl is deprecated, use bridge link. See Network bridge#With iproute2. (Discuss in Talk:Systemd-networkd#)
$ brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.14dae9b57a88	no		enp7s0
							vb-MyContainer

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

  • on host
$ ip route
default via 192.168.1.254 dev br0 
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.87
  • on container
$ ip route
default via 192.168.1.254 dev host0 
192.168.1.0/24 dev host0  proto kernel  scope link  src 192.168.1.73

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

Network bridge with static IP addresses

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 MACAddressPolicy=persistent 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:

/etc/systemd/network/MyBridge.network
[Match]
Name=br0

[Network]
DNS=192.168.1.254
Address=192.168.1.87/24
Gateway=192.168.1.254
  • on container

To get configure a static IP address on the container, we need to override the system /usr/lib/systemd/network/80-container-host0.network file, which provides a DHCP configuration for the host0 network interface of the container. This can be done by placing the configuration into /etc/systemd/network/80-container-host0.network. 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 systemd-networkd.service is enabled in the container.

Tips and tricks

Interface and desktop integration

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.
  • networkd-notify-gitAUR can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association).
  • The networkd-dispatcherAUR 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 resolvectl status.

Configuring static IP or DHCP based on SSID (location)

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:

Note: Number in the file name decides the order in which the files are processed. You can [Match] based on SSID or BSSID or both.
/etc/systemd/network/24-wireless-office.network
# special configuration for office WiFi network
[Match]
Name=wlp2s0
SSID=office_ap_name
#BSSID=aa:bb:cc:dd:ee:ff

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1
#DNS=8.8.8.8
/etc/systemd/network/25-wireless-dhcp.network
# use DHCP for any other WiFi network
[Match]
Name=wlp2s0

[Network]
DHCP=ipv4

Bonding a wired and wireless interface

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:

/etc/systemd/network/30-ethernet-bond0.network
[Match]
Name=enp0s25

[Network]
Bond=bond0
PrimarySlave=true

Set the wireless as the secondary:

/etc/systemd/network/30-wifi-bond0.network
[Match]
Name=wlan0

[Network]
Bond=bond0

Configure the bond interface as you would a normal interface:

/etc/systemd/network/30-bond0.network
[Match]
Name=bond0

[Network]
DHCP=ipv4

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

$ networkctl
IDX LINK    TYPE     OPERATIONAL      SETUP     
  1 lo      loopback carrier          unmanaged 
  2 enp0s25 ether    no-carrier       configured
  3 bond0   bond     degraded-carrier configured
  5 wlan0   wlan     enslaved         configured

4 links listed.

Troubleshooting

Mount services at boot fail

If running services like Samba/NFS which fail if they are started before the network is up, you may want to enable the systemd-networkd-wait-online.service. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.

See also