Systemd-networkd: Difference between revisions
m (→[Link] section: added NamePolicy, which is useful for forcing or preventing interface name change. It's used e.g. in the iwd arch wiki) |
(My network bridge would not inherit MAC address unless I did this) |
||
(170 intermediate revisions by 44 users not shown) | |||
Line 2: | Line 2: | ||
[[Category:Network managers]] | [[Category:Network managers]] | ||
[[Category:Virtualization]] | [[Category:Virtualization]] | ||
[[de:Systemd/systemd-networkd]] | |||
[[es:Systemd-networkd]] | [[es:Systemd-networkd]] | ||
[[fr: | [[fr:Systemd-networkd]] | ||
[[ja:systemd-networkd]] | [[ja:systemd-networkd]] | ||
[[ru:Systemd-networkd]] | [[ru:Systemd-networkd]] | ||
Line 20: | Line 21: | ||
== Basic usage == | == Basic usage == | ||
The {{Pkg|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]]. | The {{Pkg|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]]. | ||
Line 26: | Line 28: | ||
To use ''systemd-networkd'', [[start/enable]] {{ic|systemd-networkd.service}}. | To use ''systemd-networkd'', [[start/enable]] {{ic|systemd-networkd.service}}. | ||
It is optional to also [[ | {{Note|Ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. Find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them.}} | ||
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]]. | * 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 to obtain DNS addresses from DHCP servers or IPv6 router advertisements.<br>(by setting ({{ic|1=DHCP=}} and/or {{ic|1=IPv6AcceptRA=}} in the {{ic|[Network]}} section, and {{ic|1=UseDNS=yes}} (the default) in the corresponding section(s) {{ic|[DHCPv4]}}, {{ic|[DHCPv6]}}, {{ic|[IPv6AcceptRA]}}, see {{man|5|systemd.network}}). | |||
* Note that ''systemd-resolved'' can also be used without ''systemd-networkd''. | * Note that ''systemd-resolved'' can also be used without ''systemd-networkd''. | ||
=== systemd-networkd-wait-online === | |||
{{Expansion|Per {{man|8|systemd-networkd-wait-online.service}}, "online means that the link's operational state is equal or higher than "degraded"." | |||
Add instructions for setting {{ic|RequiredForOnline{{=}}routable}} in ''.network'' files.}} | |||
Enabling {{ic|systemd-networkd.service}} also enables {{ic|systemd-networkd-wait-online.service}}, which is a oneshot system service that waits for the network to be configured. The latter has {{ic|1=WantedBy=network-online.target}}, so it will be started only when {{ic|network-online.target}} itself is enabled or pulled in by some other unit. See also [[systemd#Running services after the network is up]]. | |||
By default, {{ic|systemd-networkd-wait-online.service}} waits for all links managed by ''systemd-networkd'' to be fully configured or failed, and for at least one link to be online. | |||
For system with multiple network interfaces that are not expected to be connected all the time (e.g. if a dual-port Ethernet card, but only one cable plugged in), starting {{ic|systemd-networkd-wait-online.service}} 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 {{ic|--any}} parameter to the {{ic|ExecStart}} line: | |||
{{hc|/etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf|2= | |||
[Service] | |||
ExecStart= | |||
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any | |||
}} | |||
Alternatively, use {{ic|systemd-networkd-wait-online@.service}} to wait for a specific interface. For example, to wait for {{ic|enp1s0}}, [[disable]] {{ic|systemd-networkd-wait-online.service}} and [[enable]] {{ic|systemd-networkd-wait-online@enp1s0.service}}. | |||
See {{man|8|systemd-networkd-wait-online}} for details. | |||
=== Configuration examples === | === Configuration examples === | ||
{{Expansion|Mention {{ic|networkctl edit}} and {{ic|/usr/lib/systemd/network/*.example}}}} | |||
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network/}}. For a full listing of options and processing order, see [[#Configuration files]] and {{man|5|systemd.network}}. | All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network/}}. For a full listing of options and processing order, see [[#Configuration files]] and {{man|5|systemd.network}}. | ||
systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system. If it is desired to divert from the automatic interface naming, see [[Network configuration#Change interface name]] for examples. | |||
After making changes to a configuration file, [[restart]] {{ic|systemd-networkd.service}}. | After making changes to a configuration file, [[restart]] {{ic|systemd-networkd.service}}. | ||
Line 42: | Line 70: | ||
{{Note| | {{Note| | ||
* The options specified in the configuration files are case sensitive. | * The options specified in the configuration files are case sensitive. | ||
* In the examples below, {{ic|enp1s0}} is the wired adapter and {{ic|wlp2s0}} is the wireless adapter. These names can be different on different systems. It is also possible to use a wildcard, e.g. {{ic|1=Name=en*}}. | * In the examples below, {{ic|enp1s0}} is the wired adapter and {{ic|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. {{ic|1=Name=en*}} or {{ic|1=Name=wl*}}. | ||
* | * Devices can also be matched by their type. E.g. {{ic|1=Type=ether}} for Ethernet, {{ic|1=Type=wlan}} for Wi-Fi and {{ic|1=Type=wwan}} for WWAN. | ||
* Note that {{ic|1=Type=ether}} will also match virtual Ethernet interfaces. To exclude them, use {{ic|1=Type=ether}} in combination with {{ic|1=Kind=!*}}. | |||
* To disable IPv6, see [[IPv6#systemd-networkd_3|IPv6#systemd-networkd]]. | |||
}} | }} | ||
==== Wired adapter using DHCP ==== | ==== Wired adapter using DHCP ==== | ||
{{hc|/etc/systemd/network/20-wired.network|2= | {{hc|/etc/systemd/network/20-wired.network|2= | ||
[Match] | [Match] | ||
Line 53: | Line 84: | ||
[Network] | [Network] | ||
DHCP= | DHCP=yes | ||
}} | }} | ||
==== Wired adapter using a static IP ==== | ==== Wired adapter using a static IP ==== | ||
{{hc|/etc/systemd/network/20-wired.network|2= | {{hc|/etc/systemd/network/20-wired.network|2= | ||
[Match] | [Match] | ||
Line 65: | Line 97: | ||
Gateway=10.1.10.1 | Gateway=10.1.10.1 | ||
DNS=10.1.10.1 | DNS=10.1.10.1 | ||
}} | }} | ||
Line 71: | Line 102: | ||
==== Wireless adapter ==== | ==== Wireless adapter ==== | ||
{{hc|/etc/systemd/network/25-wireless.network| | 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. | ||
{{hc|/etc/systemd/network/25-wireless.network|2= | |||
[Match] | [Match] | ||
Name=wlp2s0 | Name=wlp2s0 | ||
[Network] | [Network] | ||
DHCP= | 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 using a static IP|wired adapter]]. | If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]]. | ||
{{Tip|{{ic|1=IgnoreCarrierLoss=3s}} ensures that ''systemd-networkd'' will not re-configure the interface (e.g., release and re-acquire a DHCP lease) for a short period (3 seconds in this example) while the wireless interface roams to another access point within the same wireless network (SSID), which translates to shorter downtime when roaming.}} | |||
To authenticate to the wireless network, use e.g. [[wpa_supplicant]] or [[iwd]]. | |||
==== Wired and wireless adapters on the same machine ==== | ==== Wired and wireless adapters on the same machine ==== | ||
Line 88: | Line 125: | ||
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). | 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). | ||
''systemd-networkd'' [https://github.com/systemd/systemd/issues/17698 does not set per-interface-type default route metrics], so it needs to be configured manually: | |||
{{Note|The {{ic|Metric}} option is for static routes while the {{ic|RouteMetric}} option is for setups not using static routes. See {{man|5|systemd.network}} for more details.}} | {{Note|The {{ic|Metric}} option is for static routes while the {{ic|RouteMetric}} option is for setups not using static routes. See {{man|5|systemd.network}} for more details.}} | ||
Line 96: | Line 135: | ||
[Network] | [Network] | ||
DHCP= | DHCP=yes | ||
[DHCPv4] | |||
RouteMetric=100 | |||
[ | [IPv6AcceptRA] | ||
RouteMetric= | RouteMetric=100 | ||
}} | |||
{{hc|/etc/systemd/network/25-wireless.network|2= | {{hc|/etc/systemd/network/25-wireless.network|2= | ||
Line 106: | Line 149: | ||
[Network] | [Network] | ||
DHCP= | DHCP=yes | ||
[ | [DHCPv4] | ||
RouteMetric= | RouteMetric=600 | ||
[IPv6AcceptRA] | |||
RouteMetric=600 | |||
}} | }} | ||
== Configuration files == | == Configuration files == | ||
Configuration files are located in {{ic|/usr/lib/systemd/network/}}, the volatile runtime network directory {{ic|/run/systemd/network/}} and the local administration network directory {{ic|/etc/systemd/network/}}. Files in {{ic|/etc/systemd/network/}} have the highest priority. | The global configuration file in {{ic|/etc/systemd/networkd.conf}} may be used to override some defaults only. The main configuration is performed per network device. Configuration files are located in {{ic|/usr/lib/systemd/network/}}, the volatile runtime network directory {{ic|/run/systemd/network/}} and the local administration network directory {{ic|/etc/systemd/network/}}. Files in {{ic|/etc/systemd/network/}} have the highest priority. | ||
There are three types of configuration files. They all use a format similar to [[systemd#Writing unit files|systemd unit files]]. | There are three types of configuration files. They all use a format similar to [[systemd#Writing unit files|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: | They all follow the same rules: | ||
Line 144: | Line 176: | ||
{{Tip| | {{Tip| | ||
* | * Files in {{ic|/etc/systemd/network/}} override the corresponding system-supplied file in {{ic|/usr/lib/systemd/network/}}. Optionally use a symlink to {{ic|/dev/null}} to "mask" a system file. | ||
* | * systemd accepts the values {{ic|1}}, {{ic|true}}, {{ic|yes}}, {{ic|on}} for a true boolean, and the values {{ic|0}}, {{ic|false}}, {{ic|no}}, {{ic|off}} for a false boolean. See {{man|7|systemd.syntax}}. | ||
* systemd-networkd will alter routing tables also for other network software. If this is undesired, configure {{ic|1=ManageForeignRoutingPolicyRules=}} in {{man|5|networkd.conf}} accordingly. For example, see [[WireGuard#Connection lost after sleep using systemd-networkd]]. | |||
}} | }} | ||
=== network files === | === network files === | ||
{{Remove|Duplicates the {{man|5|systemd.network}} man page.}} | |||
These files are aimed at setting network configuration variables, especially for servers and containers. | These files are aimed at setting network configuration variables, especially for servers and containers. | ||
''.network'' files have the following sections: {{ic|[Match]}}, {{ic|[Link]}}, {{ic|[Network]}}, {{ic|[Address]}}, {{ic|[Route]}}, and {{ic|[ | ''.network'' files have the following sections: {{ic|[Match]}}, {{ic|[Link]}}, {{ic|[Network]}}, {{ic|[Address]}}, {{ic|[Route]}}, and {{ic|[DHCPv4]}}. Below are commonly configured keys for each section. See {{man|5|systemd.network}} for more information and examples. | ||
==== [Match] ==== | ==== [Match] ==== | ||
Line 165: | Line 198: | ||
| {{ic|1=MACAddress=}} || Match MAC addresses, e.g. {{ic|1=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 || | | {{ic|1=MACAddress=}} || Match MAC addresses, e.g. {{ic|1=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 || | ||
|- | |- | ||
| {{ic|1=Host=}} || Match the hostname or machine ID of the host. || hostname string with globs, | | {{ic|1=Host=}} || Match the hostname or machine ID of the host. || hostname string with globs, {{man|5|machine-id}} || | ||
|- | |- | ||
| {{ic|1=Virtualization=}} || Check whether the system is executed in a virtualized environment. {{ic|1=Virtualization=false}} will only match your host machine, while {{ic|1=Virtualization=true}} matches any container or VM. It is possible to check for a specific virtualization type or implementation. || boolean, logical negation ({{ic|!}}), type ({{ic|vm}}, {{ic|container}}), implementation ({{ | | {{ic|1=Virtualization=}} || Check whether the system is executed in a virtualized environment. {{ic|1=Virtualization=false}} will only match your host machine, while {{ic|1=Virtualization=true}} matches any container or VM. It is possible to check for a specific virtualization type or implementation, or for a user namespace (with {{ic|private-users}}). || boolean, logical negation ({{ic|!}}), type ({{ic|vm}}, {{ic|container}}), implementation (see {{man|1|systemd-detect-virt}}), {{ic|private-users}} || | ||
|} | |} | ||
==== [Link] ==== | ==== [Link] ==== | ||
{| class = "wikitable" | |||
! Parameter !! Description !! Accepted Values !! Default Value | |||
|- | |||
| {{ic|1=MACAddress=}} || Assign a hardware address to the device. Useful for [[MAC address spoofing#systemd-udevd|MAC address spoofing]]. || full colon-, hyphen- or dot-delimited hexadecimal MAC addresses || | |||
|- | |||
| {{ic|1=MTUBytes=}} || Maximum transmission unit in bytes to set for the device. Note that if IPv6 is enabled on the interface, and the MTU is chosen below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value. Setting a larger MTU value (e.g. when using [[jumbo frames]]) can significantly speed up your network transfers || integer (usual suffixes K, M, G, are supported and are understood to the base of 1024) || | |||
|- | |||
| {{ic|1=Multicast=}} || allows the usage of [[wikipedia:Multicast_address|multicast]] || boolean || ? not documented ? | |||
|} | |||
==== [Network] ==== | ==== [Network] ==== | ||
Line 181: | Line 220: | ||
! Parameter !! Description !! Accepted Values !! Default Value | ! Parameter !! Description !! Accepted Values !! Default Value | ||
|- | |- | ||
| {{ic|1=DHCP=}} || Controls DHCPv4 and/or DHCPv6 client support. || boolean, {{ic|ipv4}}, {{ic|ipv6}} || {{ic| | | {{ic|1=DHCP=}} || Controls DHCPv4 and/or DHCPv6 client support. || boolean, {{ic|ipv4}}, {{ic|ipv6}} || {{ic|no}} | ||
|- | |- | ||
| {{ic|1=DHCPServer=}} || If enabled, a DHCPv4 server will be started. || boolean || {{ic| | | {{ic|1=DHCPServer=}} || If enabled, a DHCPv4 server will be started. || boolean || {{ic|no}} | ||
|- | |- | ||
| {{ic|1=MulticastDNS=}} || Enables [ | | {{ic|1=MulticastDNS=}} || Enables [[RFC:6762|multicast DNS]] support. When set to {{ic|resolve}}, only resolution is enabled, but not host or service registration and announcement. || boolean, {{ic|resolve}} || {{ic|false}} | ||
|- | |- | ||
| {{ic|1=DNSSEC=}} || Controls DNSSEC DNS validation support on the link. When set to {{ic|allow-downgrade}}, compatibility with non-DNSSEC capable networks is increased, by automatically turning off DNSSEC in this case. || boolean, {{ic|allow-downgrade}} || {{ic|false}} | | {{ic|1=DNSSEC=}} || Controls DNSSEC DNS validation support on the link. When set to {{ic|allow-downgrade}}, compatibility with non-DNSSEC capable networks is increased, by automatically turning off DNSSEC in this case. || boolean, {{ic|allow-downgrade}} || {{ic|false}} | ||
|- | |- | ||
| {{ic|1=DNS=}} || Configure static [[DNS]] addresses. May be specified more than once. || | | {{ic|1=DNS=}} || Configure static [[DNS]] addresses. May be specified more than once. || {{man|3|inet_pton}} || | ||
|- | |- | ||
| {{ic|1=Domains=}} || A list of domains which should be resolved using the DNS servers on this link. | | {{ic|1=Domains=}} || A list of domains which should be resolved using the DNS servers on this link. {{man|5|systemd.network|[NETWORK] SECTION OPTIONS}} || domain name, optionally prefixed with a tilde ({{ic|~}}) || | ||
|- | |- | ||
| {{ic|1=IPForward=}} || If enabled, incoming packets on any network interface will be forwarded to any other interfaces according to the routing table. || boolean, {{ic|ipv4}}, {{ic|ipv6}} || {{ic| | | {{ic|1=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, {{ic|ipv4}}, {{ic|ipv6}} || {{ic|no}} | ||
|- | |- | ||
| {{ic|1=IPMasquerade=}} || If enabled, packets forwarded from the network interface will appear as coming from the local host. || | | {{ic|1=IPMasquerade=}} || If enabled, packets forwarded from the network interface will appear as coming from the local host. Depending on the value, implies {{ic|1=IPForward=ipv4}}, {{ic|1=IPForward=ipv6}} or {{ic|1=IPForward=yes}}. || {{ic|ipv4}}, {{ic|ipv6}}, {{ic|both}}, {{ic|no}} || {{ic|no}} | ||
|- | |- | ||
| {{ic|1=IPv6PrivacyExtensions=}} || Configures use of stateless temporary addresses that change over time (see [ | | {{ic|1=IPv6PrivacyExtensions=}} || Configures use of stateless temporary addresses that change over time (see [[RFC:4941|RFC 4941]]). When {{ic|prefer-public}}, enables the privacy extensions, but prefers public addresses over temporary addresses. When {{ic|kernel}}, the kernel's default setting will be left in place. || boolean, {{ic|prefer-public}}, {{ic|kernel}} || {{ic|no}} | ||
|} | |} | ||
==== [Address] ==== | ==== [Address] ==== | ||
{| class = "wikitable" | |||
! Parameter !! Description !! Accepted Values !! Default Value | |||
|- | |||
| {{ic|1=Address=}} || Specify this key more than once to configure several addresses. Mandatory unless DHCP is used. If the specified address is {{ic|0.0.0.0}} (for IPv4) or {{ic|::}} (for IPv6), a new address range of the requested size is automatically allocated from a system-wide pool of unused ranges. || static IPv4 or IPv6 address and its prefix length (see {{man|3|inet_pton}}) || | |||
|} | |||
==== [Route] ==== | ==== [Route] ==== | ||
Line 209: | Line 252: | ||
* {{ic|1=Destination=}} the destination prefix of the route, possibly followed by a slash and the prefix length | * {{ic|1=Destination=}} the destination prefix of the route, possibly followed by a slash and the prefix length | ||
If {{ic| | If {{ic|Destination}} is not present in {{ic|[Route]}} section, this section is treated as a default route. | ||
==== [ | {{Tip|Put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|[Address]}} section contains only an {{ic|Address}} key and {{ic|[Route]}} section contains only a {{ic|Gateway}} key.}} | ||
==== [DHCPv4] ==== | |||
{| class = "wikitable | {| class = "wikitable | ||
Line 219: | Line 263: | ||
| {{ic|1=UseDNS=}} || controls whether the DNS servers advertised by the DHCP server are used || boolean || {{ic|true}} | | {{ic|1=UseDNS=}} || controls whether the DNS servers advertised by the DHCP server are used || boolean || {{ic|true}} | ||
|- | |- | ||
| {{ic|1=Anonymize=}} || when true, the options sent to the DHCP server will follow the [ | | {{ic|1=Anonymize=}} || when true, the options sent to the DHCP server will follow the [[RFC:7844]] (Anonymity Profiles for DHCP Clients) to minimize disclosure of identifying information || boolean || {{ic|false}} | ||
|- | |- | ||
| {{ic|1=UseDomains=}} || controls whether the domain name received from the DHCP server will be used as DNS search domain. If set to {{ic|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, {{ic|route}} || {{ic|false}} | | {{ic|1=UseDomains=}} || controls whether the domain name received from the DHCP server will be used as DNS search domain. If set to {{ic|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, {{ic|route}} || {{ic|false}} | ||
|- | |||
| {{ic|1=IPv6OnlyMode=}} || when true, the DHCP client will signal to the DHCP server that it supports IPv6-only operation ([[RFC:8925]], IPv6-Only Preferred Option for DHCPv4). If the DHCPv4 server returns that option in its DHCP response, the client will abort the DHCP request, will not acquire an IPv4 address and will configure an IPv6-only network || boolean || {{ic|true}} if IPv6 is enabled | |||
|} | |} | ||
==== [DHCPServer] ==== | ==== [DHCPServer] ==== | ||
This is an example of a DHCP server configuration which works well with [[hostapd]] to create a wireless hotspot. {{ic|IPMasquerade}} adds the firewall rules for [[Internet sharing#Enable NAT|NAT]] and {{ic|IPForward}} | This is an example of a DHCP server configuration which works well with [[hostapd]] to create a wireless hotspot. {{ic|IPMasquerade}} adds the firewall rules for [[Internet sharing#Enable NAT|NAT]] and implies {{ic|1=IPForward=ipv4}} to enable [[Internet sharing#Enable packet forwarding|packet forwarding]]. | ||
{{Accuracy|{{ic|1=IPMasquerade=ipv4}} does not add the rules for the {{ic|filter}} table, they have to be added manually. See [[systemd-nspawn#Use a virtual Ethernet link]].}} | |||
{{hc|/etc/systemd/network/''wlan0''.network| | {{hc|/etc/systemd/network/''wlan0''.network|2= | ||
[Match] | [Match] | ||
Name=wlan0 | Name=wlan0 | ||
Line 235: | Line 283: | ||
Address=10.1.1.1/24 | Address=10.1.1.1/24 | ||
DHCPServer=true | DHCPServer=true | ||
IPMasquerade= | IPMasquerade=ipv4 | ||
[DHCPServer] | [DHCPServer] | ||
Line 243: | Line 290: | ||
EmitDNS=yes | EmitDNS=yes | ||
DNS=9.9.9.9 | DNS=9.9.9.9 | ||
}} | |||
=== netdev files === | === netdev files === | ||
{{Remove|Duplicates the {{man|5|systemd.netdev}} man page.}} | |||
These files will create virtual network devices. They have two sections: {{ic|[Match]}} and {{ic|[NetDev]}}. Below are commonly configured keys for each section. See {{man|5|systemd.netdev}} for more information and examples. | These files will create virtual network devices. They have two sections: {{ic|[Match]}} and {{ic|[NetDev]}}. Below are commonly configured keys for each section. See {{man|5|systemd.netdev}} for more information and examples. | ||
Line 252: | Line 301: | ||
* {{ic|1=Host=}} the hostname | * {{ic|1=Host=}} the hostname | ||
* {{ic|1=Virtualization=}} check if running in a | * {{ic|1=Virtualization=}} check if the system is running in a virtualized environment | ||
==== [NetDev] section ==== | ==== [NetDev] section ==== | ||
Line 261: | Line 310: | ||
* {{ic|1=Kind=}} e.g. ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. '''mandatory''' | * {{ic|1=Kind=}} e.g. ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. '''mandatory''' | ||
== | == 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 {{ic|ip a}} command to the concerned interfaces. | |||
* we assume the ''host'' is the main OS (ie the one booting) to and the ''container'' is the guest virtual machine. | |||
* all interface names and IP addresses are only examples. | |||
=== | === Network bridge with DHCP === | ||
==== Bridge interface ==== | |||
First, create a virtual [[bridge]] interface with a ''.netdev'' unit file which tells ''systemd-networkd'' to create a device named {{ic|br0}} that functions as an Ethernet bridge. | |||
{{hc|/etc/systemd/network/25-br0.netdev|2= | |||
[NetDev] | |||
Name=br0 | |||
Kind=bridge | |||
}} | |||
{{ | Optionally add {{ic|1=MACAddress=none}} to the {{ic|NetDev}} section for the bridge to inherit MAC address from one of the bridged interfaces. This also requires a creation of ''25-br0.link'' file. | ||
== | {{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, assign a MAC address to your bridge, probably the same as your physical device, adding the line {{ic|1=MACAddress=''xx'':''xx'':''xx'':''xx'':''xx'':''xx''}} in the {{ic|NetDev}} section above.}} | ||
[[Restart]] {{ic|systemd-networkd.service}} to have ''systemd-networkd'' create the bridge. | |||
To see the newly created bridge on the host and on the container, type: | |||
{{hc|$ 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 | Note that the interface {{ic|br0}} is listed but is still DOWN at this stage. | ||
==== Bind Ethernet to bridge ==== | |||
The next step is to add a network interface to the newly created bridge. The configuration file of the bridge 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 {{ic|en*}} into the bridge {{ic|br0}}. | |||
{{hc|/etc/systemd/network/25-br0-en.network|2= | |||
{{hc|/etc/systemd/network/ | |||
[Match] | [Match] | ||
Name=en* | Name=en* | ||
[Network] | [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 address. | |||
{{Note|Ensure that no other ''.network'' file attempts to match interfaces by {{ic|1=Name=en*}}. Only the first file that matches an interface is applied.}} | |||
==== 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. | |||
{{hc|/etc/systemd/network/25-br0.network|2= | |||
[Match] | |||
Name=br0 | |||
[Network] | |||
DHCP=yes | |||
}} | |||
=== | ==== Inherit MAC address (optional) ==== | ||
==== | For the bridge to inhering MAC address from one of the bridged interfaces, set {{ic|1=MACAddress=none}} and {{ic|1=MACAddressPolicy=none}}. | ||
{{hc|/etc/systemd/network/25-br0.netdev|2= | |||
{{hc|/etc/systemd/network/ | |||
[NetDev] | [NetDev] | ||
Name=br0 | Name=br0 | ||
Kind=bridge | Kind=bridge | ||
MACAddress=none | |||
}} | }} | ||
{{hc|/etc/systemd/network/25-br0.link|2= | |||
{{hc|/etc/systemd/network/ | |||
[Match] | [Match] | ||
OriginalName=br0 | |||
[ | [Link] | ||
MACAddressPolicy=none | |||
}} | |||
==== Configure the container ==== | |||
Use the {{ic|1=--network-bridge=br0}} option when starting the container. See [[systemd-nspawn#Use a network bridge]] for details. | |||
==== Result ==== | ==== Result ==== | ||
Line 427: | Line 429: | ||
* we have now one IP address for {{ic|br0}} on the host, and one for {{ic|host0}} in the container | * we have now one IP address for {{ic|br0}} on the host, and one for {{ic|host0}} in the container | ||
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option | * two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option as explained in [[systemd-nspawn#Use a network bridge]] for details. | ||
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. | * the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. | ||
* on host | * on host | ||
{{Out of date|''brctl'' is deprecated, use {{ic|bridge link}}. See [[Network bridge#With iproute2]].}} | |||
{{hc|$ brctl show| | {{hc|$ brctl show| | ||
Line 455: | Line 459: | ||
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''. | the above command outputs confirm we have activated {{ic|br0}} and {{ic|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 {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). This setup routes any service on the gateway to the desired device. | |||
The following configuration needs to be done for this setup: | |||
* on host | * on host | ||
The configuration is very similar to | 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/''MyBridge''.netdev | ||
/etc/systemd/network/''MyEth''.network | /etc/systemd/network/''MyEth''.network | ||
Next, you need to configure the IP and DNS of the newly created virtual bridge interface. | Next, you need to configure the IP and DNS of the newly created virtual bridge interface. For example: | ||
{{hc|/etc/systemd/network/''MyBridge''.network| | {{hc|/etc/systemd/network/''MyBridge''.network|2= | ||
[Match] | [Match] | ||
Name=br0 | Name=br0 | ||
Line 481: | Line 482: | ||
Address=192.168.1.87/24 | Address=192.168.1.87/24 | ||
Gateway=192.168.1.254 | Gateway=192.168.1.254 | ||
}} | |||
* on container | * on container | ||
To get configure a static IP address on the container, we need to override the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file, which provides a DHCP configuration for the {{ic|host0}} network interface of the container. This can be done by placing the configuration into {{ic|/etc/systemd/network/80-container-host0.network}}. For example: | |||
{{hc|/etc/systemd/network/80-container-host0.network|2= | |||
{{hc|/etc/systemd/network/ | |||
[Match] | [Match] | ||
Name=host0 | Name=host0 | ||
Line 499: | Line 496: | ||
Address=192.168.1.94/24 | Address=192.168.1.94/24 | ||
Gateway=192.168.1.254 | Gateway=192.168.1.254 | ||
}} | |||
Make sure that {{ic|systemd-networkd.service}} is [[enabled]] in the container. | |||
=== MACVLAN bridge === | |||
For the host to be able to reach containers connected via MACVLAN, the host itself also needs to connect via MACVLAN and not directly to the underlying Ethernet network interface. | |||
On the host, attach the underlying Ethernet network interface to MACVLAN and make sure it does not get assigned IP addresses. For example, using {{ic|mv-0}} as the MACVLAN interface name and with {{ic|enp1s0}} as the host's Ethernet interface: | |||
{{hc|/etc/systemd/network/30-enp1s0.network|2= | |||
[Match] | |||
Name=enp1s0 | |||
[Link] | |||
RequiredForOnline=carrier | |||
[Network] | |||
MACVLAN=mv-0 | |||
DHCP=no | |||
IPv6AcceptRA=false | |||
LinkLocalAddressing=no | |||
MulticastDNS=false | |||
LLMNR=false | |||
}} | |||
{{Tip| | |||
* {{ic|RequiredForOnline{{=}}carrier}} prevents [[#systemd-networkd-wait-online|systemd-networkd-wait-online.service]] from waiting (and eventually failing) for the connection to acquire an IP address, which will never happen. | |||
* The underlying network interface does not necessarily need to be a physical Ethernet interface. For example, a MACVLAN bridge can be attached to a bond. | |||
}} | |||
Create the MACVLAN bridge {{ic|mv-0}}: | |||
{{hc|/etc/systemd/network/25-mv-0.netdev|2= | |||
[NetDev] | |||
Name=mv-0 | |||
Kind=macvlan | |||
[MACVLAN] | |||
Mode=bridge | |||
}} | |||
Configure the host's network connection on the MACVLAN bridge ({{ic|mv-0}}). The following example uses DHCP, replace the options as necessary. | |||
{{hc|/etc/systemd/network/35-mv-0.network|2= | |||
[Match] | |||
Name=mv-0 | |||
[Link] | |||
RequiredForOnline=routable | |||
[Network] | |||
BindCarrier=enp1s0 | |||
DHCP=yes | |||
}} | |||
For the container, attach a MACVLAN to the '''underlying Ethernet network interface''' ({{ic|enp1s0}} in the examples above). For example, in {{ic|/etc/systemd/nspawn/''container_name''.nspawn}} specify: | |||
{{bc|1= | |||
[Network] | |||
MACVLAN=enp1s0 | |||
}} | |||
For containers started from the command line, pass them the {{ic|--network-macvlan{{=}}enp1s0}} option. | |||
In the container, the MACVLAN interface will have the name {{ic|mv-''underlying_interface_name''}} (e.g. {{ic|mv-enp1s0}}). Configure the network connection as necessary (just like in the host) by matching the interface name. For example, using DHCP: | |||
{{hc|/etc/systemd/network/30-mv-enp1s0.network|2= | |||
[Match] | |||
Name=mv-enp1s0 | |||
[Link] | |||
RequiredForOnline=routable | |||
[Network] | |||
DHCP=yes | |||
}} | |||
== Tips and tricks == | == Tips and tricks == | ||
Line 505: | Line 578: | ||
=== Interface and desktop integration === | === Interface and desktop integration === | ||
''systemd-networkd'' does not have a proper interactive management interface | ''systemd-networkd'' does not have a proper interactive graphical management interface. Still, some tools are available to either display or modify the current state of the network, receive notifications or interact with the wireless configuration: | ||
* ''networkctl'' provides a [[command-line shell]] interface to query or modify the network interface states. It is worth noting that in order to change only some aspects of an interface behavior, one is required to first [[Help:Reading#Append, add, create, edit|edit]] one or more configuration files in {{ic|/etc/systemd/network/}}. | |||
* ''networkctl'' | |||
* When ''networkd'' is configured with [[wpa_supplicant]], both ''wpa_cli'' and ''wpa_gui'' offer the ability to associate and configure WLAN interfaces dynamically. | * When ''networkd'' is configured with [[wpa_supplicant]], both ''wpa_cli'' and ''wpa_gui'' offer the ability to associate and configure WLAN interfaces dynamically. | ||
* {{AUR|networkd-notify-git}} can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association). | * {{AUR|networkd-notify-git}} can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association). | ||
Line 519: | Line 590: | ||
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: | 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. | {{Note|Number in the file name decides the order in which the files are processed. Users can [Match] based on SSID or BSSID or both.}} | ||
{{hc|/etc/systemd/network/24-wireless-office.network| | {{hc|/etc/systemd/network/24-wireless-office.network|2= | ||
# special configuration for office WiFi network | # special configuration for office WiFi network | ||
[Match] | [Match] | ||
Line 533: | Line 604: | ||
DNS=10.1.10.1 | DNS=10.1.10.1 | ||
#DNS=8.8.8.8 | #DNS=8.8.8.8 | ||
}} | |||
{{hc|/etc/systemd/network/25-wireless-dhcp.network| | {{hc|/etc/systemd/network/25-wireless-dhcp.network|2= | ||
# use DHCP for any other WiFi network | # use DHCP for any other WiFi network | ||
[Match] | [Match] | ||
Line 541: | Line 612: | ||
[Network] | [Network] | ||
DHCP= | DHCP=yes | ||
}} | |||
=== Bonding a wired and wireless interface === | === Bonding a wired and wireless interface === | ||
Line 552: | Line 623: | ||
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. | 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. | ||
{{hc|/etc/systemd/network/bond0.netdev| | {{hc|/etc/systemd/network/30-bond0.netdev|2= | ||
[NetDev] | [NetDev] | ||
Name=bond0 | Name=bond0 | ||
Line 561: | Line 632: | ||
PrimaryReselectPolicy=always | PrimaryReselectPolicy=always | ||
MIIMonitorSec=1s | MIIMonitorSec=1s | ||
}} | |||
Set the wired interface as the primary: | Set the wired interface as the primary: | ||
{{hc|/etc/systemd/network/ | {{hc|/etc/systemd/network/30-ethernet-bond0.network|2= | ||
[Match] | [Match] | ||
Name=enp0s25 | Name=enp0s25 | ||
Line 572: | Line 643: | ||
Bond=bond0 | Bond=bond0 | ||
PrimarySlave=true | PrimarySlave=true | ||
}} | |||
Set the wireless as the secondary: | Set the wireless as the secondary: | ||
{{hc|/etc/systemd/network/30-wifi- | {{hc|/etc/systemd/network/30-wifi-bond0.network|2= | ||
[Match] | [Match] | ||
Name=wlan0 | Name=wlan0 | ||
Line 582: | Line 653: | ||
[Network] | [Network] | ||
Bond=bond0 | Bond=bond0 | ||
}} | |||
{{Note|When using MAC addresses in the {{ic|[Match]}} section, use of {{ic|PermanentMACAddress}} is recommended over {{ic|MACAddress}}, see [https://github.com/systemd/systemd/issues/27432 this upstream discussion].}} | |||
Configure the bond interface | Configure the bond interface just like a normal interface: | ||
{{hc|/etc/systemd/network/ | {{hc|/etc/systemd/network/30-bond0.network|2= | ||
[Match] | [Match] | ||
Name=bond0 | Name=bond0 | ||
[Network] | [Network] | ||
DHCP= | BindCarrier=enp0s25 wlan0 | ||
DHCP=yes | |||
}} | |||
Now if the wired network is unplugged, the connection should remain through the wireless: | Now if the wired network is unplugged, the connection should remain through the wireless: | ||
{{hc|$ networkctl| | {{hc|$ networkctl| | ||
IDX LINK TYPE OPERATIONAL SETUP | IDX LINK TYPE OPERATIONAL SETUP | ||
1 lo loopback carrier unmanaged | 1 lo loopback carrier unmanaged | ||
Line 604: | Line 678: | ||
4 links listed. | 4 links listed. | ||
}} | |||
== | === Speeding up TCP slow-start === | ||
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[https://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/]. 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: | |||
{{hc|/etc/systemd/network/eth0.network|2= | |||
[Match] | |||
Name=eth0 | |||
#[Network] | |||
#Gateway=... <-- Remove this if you have it, and put it in the Gateway= line below | |||
[Route] | |||
# This will apply to the gateway supplied via DHCP. If you manually specify | |||
# your gateway, put it here instead. | |||
Gateway=_dhcp4 | |||
== | # The defaults for these values is 10. They are a multiple of the MSS (1460 bytes). | ||
InitialCongestionWindow=10 | |||
InitialAdvertisedReceiveWindow=10 | |||
}} | |||
The defaults of {{ic|10}} work well for connections slower than 10 Mbit/s. For a 100 Mbit/s connection, a value of {{ic|30}} works well. The manual page {{man|5|systemd.network|[ROUTE] SECTION OPTIONS}} says a value of {{ic|100}} is considered excessive. | |||
{{ | If the [[sysctl]] setting {{ic|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 {{ic|Initial*}} settings set above. | ||
The sysctl setting {{ic|net.ipv4.tcp_congestion_control}} 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 {{ic|Initial*}} 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). | |||
== See also == | == See also == | ||
* [ | * {{man|8|systemd-networkd}} | ||
* [https://web.archive.org/web/20201111213850/https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog] | |||
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums) | * [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums) |
Latest revision as of 13:06, 19 April 2024
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
.
systemctl --type=service
and then stop them.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 to obtain DNS addresses from DHCP servers or IPv6 router advertisements.
(by setting (DHCP=
and/orIPv6AcceptRA=
in the[Network]
section, andUseDNS=yes
(the default) in the corresponding section(s)[DHCPv4]
,[DHCPv6]
,[IPv6AcceptRA]
, see systemd.network(5)). - Note that systemd-resolved can also be used without systemd-networkd.
systemd-networkd-wait-online
Enabling systemd-networkd.service
also enables systemd-networkd-wait-online.service
, which is a oneshot system service that waits for the network to be configured. The latter has WantedBy=network-online.target
, so it will be started only when network-online.target
itself is enabled or pulled in by some other unit. See also systemd#Running services after the network is up.
By default, systemd-networkd-wait-online.service
waits for all links managed by systemd-networkd to be fully configured or failed, and for at least one link to be online.
For system with multiple network interfaces that are not expected to be connected all the time (e.g. if a dual-port Ethernet card, but only one cable plugged in), starting systemd-networkd-wait-online.service
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 --any
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
Alternatively, use systemd-networkd-wait-online@.service
to wait for a specific interface. For example, to wait for enp1s0
, disable systemd-networkd-wait-online.service
and enable systemd-networkd-wait-online@enp1s0.service
.
See systemd-networkd-wait-online(8) for details.
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. If it is desired to divert from the automatic interface naming, see Network configuration#Change interface name for examples.
After making changes to a configuration file, restart systemd-networkd.service
.
- The options specified in the configuration files are case sensitive.
- In the examples below,
enp1s0
is the wired adapter andwlp2s0
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*
orName=wl*
. - Devices can also be matched by their type. E.g.
Type=ether
for Ethernet,Type=wlan
for Wi-Fi andType=wwan
for WWAN. - Note that
Type=ether
will also match virtual Ethernet interfaces. To exclude them, useType=ether
in combination withKind=!*
. - 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
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 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.
IgnoreCarrierLoss=3s
ensures that systemd-networkd will not re-configure the interface (e.g., release and re-acquire a DHCP lease) for a short period (3 seconds in this example) while the wireless interface roams to another access point within the same wireless network (SSID), which translates to shorter downtime when roaming.To authenticate to the wireless network, use e.g. wpa_supplicant or iwd.
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).
systemd-networkd does not set per-interface-type default route metrics, so it needs to be configured manually:
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 [DHCPv4] RouteMetric=100 [IPv6AcceptRA] RouteMetric=100
/etc/systemd/network/25-wireless.network
[Match] Name=wlp2s0 [Network] DHCP=yes [DHCPv4] RouteMetric=600 [IPv6AcceptRA] RouteMetric=600
Configuration files
The global configuration file in /etc/systemd/networkd.conf
may be used to override some defaults only. The main configuration is performed per network device. 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
- Files in
/etc/systemd/network/
override the corresponding system-supplied file in/usr/lib/systemd/network/
. Optionally use a symlink to/dev/null
to "mask" a system file. - systemd accepts the values
1
,true
,yes
,on
for a true boolean, and the values0
,false
,no
,off
for a false boolean. See systemd.syntax(7). - systemd-networkd will alter routing tables also for other network software. If this is undesired, configure
ManageForeignRoutingPolicyRules=
in networkd.conf(5) accordingly. For example, see WireGuard#Connection lost after sleep using systemd-networkd.
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 [DHCPv4]
. 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(5) | |
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, or for a user namespace (with private-users ). |
boolean, logical negation (! ), type (vm , container ), implementation (see systemd-detect-virt(1)), private-users |
[Link]
Parameter | Description | Accepted Values | Default Value |
---|---|---|---|
MACAddress= |
Assign a hardware address to the device. Useful for MAC address spoofing. | full colon-, hyphen- or dot-delimited hexadecimal MAC addresses | |
MTUBytes= |
Maximum transmission unit in bytes to set for the device. Note that if IPv6 is enabled on the interface, and the MTU is chosen below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value. Setting a larger MTU value (e.g. when using jumbo frames) can significantly speed up your network transfers | integer (usual suffixes K, M, G, are supported and are understood to the base of 1024) | |
Multicast= |
allows the usage of multicast | boolean | ? not documented ? |
[Network]
Parameter | Description | Accepted Values | Default Value |
---|---|---|---|
DHCP= |
Controls DHCPv4 and/or DHCPv6 client support. | boolean, ipv4 , ipv6 |
no
|
DHCPServer= |
If enabled, a DHCPv4 server will be started. | boolean | no
|
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. systemd.network(5) § [NETWORK] SECTION OPTIONS | 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 |
no
|
IPMasquerade= |
If enabled, packets forwarded from the network interface will appear as coming from the local host. Depending on the value, implies IPForward=ipv4 , IPForward=ipv6 or IPForward=yes . |
ipv4 , ipv6 , both , no |
no
|
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 |
no
|
[Address]
Parameter | Description | Accepted Values | Default Value |
---|---|---|---|
Address= |
Specify this key more than once to configure several addresses. Mandatory unless DHCP is used. If the specified address is 0.0.0.0 (for IPv4) or :: (for IPv6), a new address range of the requested size is automatically allocated from a system-wide pool of unused ranges. |
static IPv4 or IPv6 address and its prefix length (see inet_pton(3)) |
[Route]
Gateway=
this option is mandatory unless DHCP is usedDestination=
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.
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.[DHCPv4]
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 RFC:7844 (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
|
IPv6OnlyMode= |
when true, the DHCP client will signal to the DHCP server that it supports IPv6-only operation (RFC:8925, IPv6-Only Preferred Option for DHCPv4). If the DHCPv4 server returns that option in its DHCP response, the client will abort the DHCP request, will not acquire an IPv4 address and will configure an IPv6-only network | boolean | true if IPv6 is enabled
|
[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.
/etc/systemd/network/wlan0.network
[Match] Name=wlan0 [Network] Address=10.1.1.1/24 DHCPServer=true IPMasquerade=ipv4 [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 hostnameVirtualization=
check if the system is running in a virtualized environment
[NetDev] section
Most common keys are:
Name=
the interface name. mandatoryKind=
e.g. bridge, bond, vlan, veth, sit, etc. mandatory
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 the main OS (ie the one booting) to and the container is the guest virtual machine.
- all interface names and IP addresses are only examples.
Network bridge with DHCP
Bridge interface
First, create a virtual bridge interface with a .netdev unit file which tells systemd-networkd to create a device named br0
that functions as an Ethernet bridge.
/etc/systemd/network/25-br0.netdev
[NetDev] Name=br0 Kind=bridge
Optionally add MACAddress=none
to the NetDev
section for the bridge to inherit MAC address from one of the bridged interfaces. This also requires a creation of 25-br0.link file.
MACAddress=xx:xx:xx:xx:xx:xx
in the NetDev
section above.Restart systemd-networkd.service
to have systemd-networkd 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 a network interface to the newly created bridge. The configuration file of the bridge 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
.
/etc/systemd/network/25-br0-en.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 address.
Name=en*
. Only the first file that matches an interface is applied.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/25-br0.network
[Match] Name=br0 [Network] DHCP=yes
Inherit MAC address (optional)
For the bridge to inhering MAC address from one of the bridged interfaces, set MACAddress=none
and MACAddressPolicy=none
.
/etc/systemd/network/25-br0.netdev
[NetDev] Name=br0 Kind=bridge MACAddress=none
/etc/systemd/network/25-br0.link
[Match] OriginalName=br0 [Link] MACAddressPolicy=none
Configure the container
Use the --network-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 forhost0
in the container - two new interfaces have appeared:
vb-MyContainer
in the host andhost0
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
$ 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). This setup routes any service on the 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.
MACVLAN bridge
For the host to be able to reach containers connected via MACVLAN, the host itself also needs to connect via MACVLAN and not directly to the underlying Ethernet network interface.
On the host, attach the underlying Ethernet network interface to MACVLAN and make sure it does not get assigned IP addresses. For example, using mv-0
as the MACVLAN interface name and with enp1s0
as the host's Ethernet interface:
/etc/systemd/network/30-enp1s0.network
[Match] Name=enp1s0 [Link] RequiredForOnline=carrier [Network] MACVLAN=mv-0 DHCP=no IPv6AcceptRA=false LinkLocalAddressing=no MulticastDNS=false LLMNR=false
RequiredForOnline=carrier
prevents systemd-networkd-wait-online.service from waiting (and eventually failing) for the connection to acquire an IP address, which will never happen.- The underlying network interface does not necessarily need to be a physical Ethernet interface. For example, a MACVLAN bridge can be attached to a bond.
Create the MACVLAN bridge mv-0
:
/etc/systemd/network/25-mv-0.netdev
[NetDev] Name=mv-0 Kind=macvlan [MACVLAN] Mode=bridge
Configure the host's network connection on the MACVLAN bridge (mv-0
). The following example uses DHCP, replace the options as necessary.
/etc/systemd/network/35-mv-0.network
[Match] Name=mv-0 [Link] RequiredForOnline=routable [Network] BindCarrier=enp1s0 DHCP=yes
For the container, attach a MACVLAN to the underlying Ethernet network interface (enp1s0
in the examples above). For example, in /etc/systemd/nspawn/container_name.nspawn
specify:
[Network] MACVLAN=enp1s0
For containers started from the command line, pass them the --network-macvlan=enp1s0
option.
In the container, the MACVLAN interface will have the name mv-underlying_interface_name
(e.g. mv-enp1s0
). Configure the network connection as necessary (just like in the host) by matching the interface name. For example, using DHCP:
/etc/systemd/network/30-mv-enp1s0.network
[Match] Name=mv-enp1s0 [Link] RequiredForOnline=routable [Network] DHCP=yes
Tips and tricks
Interface and desktop integration
systemd-networkd does not have a proper interactive graphical management interface. Still, some tools are available to either display or modify the current state of the network, receive notifications or interact with the wireless configuration:
- networkctl provides a command-line shell interface to query or modify the network interface states. It is worth noting that in order to change only some aspects of an interface behavior, one is required to first edit one or more configuration files in
/etc/systemd/network/
. - 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:
/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=yes
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
[Match]
section, use of PermanentMACAddress
is recommended over MACAddress
, see this upstream discussion.Configure the bond interface just like a normal interface:
/etc/systemd/network/30-bond0.network
[Match] Name=bond0 [Network] BindCarrier=enp0s25 wlan0 DHCP=yes
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.
Speeding up TCP slow-start
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[1]. 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:
/etc/systemd/network/eth0.network
[Match] Name=eth0 #[Network] #Gateway=... <-- Remove this if you have it, and put it in the Gateway= line below [Route] # This will apply to the gateway supplied via DHCP. If you manually specify # your gateway, put it here instead. Gateway=_dhcp4 # The defaults for these values is 10. They are a multiple of the MSS (1460 bytes). InitialCongestionWindow=10 InitialAdvertisedReceiveWindow=10
The defaults of 10
work well for connections slower than 10 Mbit/s. For a 100 Mbit/s connection, a value of 30
works well. The manual page systemd.network(5) § [ROUTE] SECTION OPTIONS says a value of 100
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 Initial*
settings set above.
The sysctl setting net.ipv4.tcp_congestion_control
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 Initial*
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).
See also
- systemd-networkd(8)
- Tom Gundersen posts on Core OS blog
- How to set up systemd-networkd with wpa_supplicant (WonderWoofy's walkthrough on Arch forums)