September 1, 2016 at 16:05Advantages of systemd-networkd on Linux virtual servers
Typically, on Linux desktops, NetworkManager is used to manage network settings, since it does its job well and has GUI frontends for all popular graphical environments. However, on Linux servers, its use is not advisable: it consumes a lot of resources. NetworkManager takes up about 20 MB of RAM, while systemd-networkd and systemd-resolvd together are less than 2 MB. For this reason, by default, Linux server server distributions often use various native daemons.
This creates a whole zoo of scripts and utilities: the networking daemon for Debian, which manages the network configuration through ifupdown, using the configuration files stored in /etc/networking/interfaces.d and the / etc / networking / interfaces file, under CentOS network, which uses scripts ifup and ifdown and, of course, their configuration files located in / etc / sysconfig / network-scripts, netctl under ArchLinux. Everyone knows that Linux is a constructor, but why shouldn't such a simple and common thing for a wide variety of systems as setting up a network look the same?
We suggest starting to use the fast and simple systemd-networkd daemon., especially in light of the fact that many distributions have already switched to systemd, so switching to systemd-networkd will not be difficult. Currently, systemd-networkd can replace many utilities and supports network configuration both via DHCP (client and server) and with static IP addresses, bridges, tunnels, VLANs, wireless networks (using wpa_supplicant).
In this article, we will look at how to activate systemd-networkd and start using it, and what are its main advantages over other daemons.
Despite the passions surrounding the introduction of systemd , many popular Linux distributions began to use this service manager and supply it by default. Therefore, your system probably already contains everything you need to enable systemd-networkd. Requires systemd version 210 and higher.
You can check the version using the command:
To use it, start the following two services and enable them to work when the system boots (disabling other daemons that control the network configuration):
As an example of a switch, consider moving the default network configuration in CentOS (/etc/rc.d/init.d/network initscript) to systemd-networkd.
Moving in exactly the same way can be done for Fedora and, with minor modifications, for other distributions. The systemd-networkd configuration files are located in the / etc / systemd / network directory. The following types are available:
Configuration for an example: two interfaces with static IP in LAN and WAN.
Configuration files for CentOS (or Fedora) can be found in the / etc / sysconfig / network-scripts directory
It is necessary to create 4 files in the directory / etc / systemd / network /
That's it: the network configuration is complete. Now you can restart the service:
Other types of networks:
DHCP
In this example, we will configure DHCP IPv4 and IPv6; IPv6, if not needed, can be excluded.
Connection of the “Bridge” type
First creates a virtual interface configuration:
And configure the interface to connect:
1. Will not work without systemd.
2. There is no CLI or GUI frontends. Both NetworkManager and netctl do not suffer from this flaw. For example, to connect to WiFi, you need a command line. Not entirely relevant for the server.
3. For the first connection to WiFi, root privileges are required. However, this is not quite a drawback, since in the future, this wireless network will automatically connect.
4. If you are not careful, then the WiFi password can be stored in clear text in the command history. but this can be easily avoided in several ways: temporarily disable writing commands to history (for bash: set + o history, set -o history), use a shell that does not remember history (for example, dash), or simply manually remove the password from the history.
The speed of receiving addresses via DHCP is tested, Network manager and dnsmasq are disabled.
Soft:
In less than a second.
The average time after several attempts was 2.5 seconds.
In view of the active use of systemd by various top Linux distributions, we can conclude that, nevertheless, the community seeks to unify the basic system functions. These include, among other things, network configuration, and systemd, in turn, offers a convenient, fast and functional solution. And while this solution so far encounters the problem of the lack of a GUI for desktop systems, it will probably become the de facto standard for Linux servers and will replace a bunch of legacy daemons and separate utilities. This will make Linux much more convenient for containerization and use on virtual machines.
This creates a whole zoo of scripts and utilities: the networking daemon for Debian, which manages the network configuration through ifupdown, using the configuration files stored in /etc/networking/interfaces.d and the / etc / networking / interfaces file, under CentOS network, which uses scripts ifup and ifdown and, of course, their configuration files located in / etc / sysconfig / network-scripts, netctl under ArchLinux. Everyone knows that Linux is a constructor, but why shouldn't such a simple and common thing for a wide variety of systems as setting up a network look the same?
We suggest starting to use the fast and simple systemd-networkd daemon., especially in light of the fact that many distributions have already switched to systemd, so switching to systemd-networkd will not be difficult. Currently, systemd-networkd can replace many utilities and supports network configuration both via DHCP (client and server) and with static IP addresses, bridges, tunnels, VLANs, wireless networks (using wpa_supplicant).
In this article, we will look at how to activate systemd-networkd and start using it, and what are its main advantages over other daemons.
Running systemd-networkd
Despite the passions surrounding the introduction of systemd , many popular Linux distributions began to use this service manager and supply it by default. Therefore, your system probably already contains everything you need to enable systemd-networkd. Requires systemd version 210 and higher.
You can check the version using the command:
$ systemctl --versionTo use it, start the following two services and enable them to work when the system boots (disabling other daemons that control the network configuration):
$ systemctl enable systemd-networkd
$ systemctl start systemd-networkd
$ systemctl enable systemd-resolved
$ systemctl start systemd-resolvedConfiguration
As an example of a switch, consider moving the default network configuration in CentOS (/etc/rc.d/init.d/network initscript) to systemd-networkd.
Moving in exactly the same way can be done for Fedora and, with minor modifications, for other distributions. The systemd-networkd configuration files are located in the / etc / systemd / network directory. The following types are available:
- .link - describe the physical parameters of each interface: name, MAC, MTU and others
- .network - describe the network parameters: IP, routes, DNS and others
- .netdev - describe virtual interfaces, bridges
Configuration for an example: two interfaces with static IP in LAN and WAN.
$ ip addr
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 04:01:40:23:1f:01 brd ff:ff:ff:ff:ff:ff
inet 188.166.46.238/18 brd 188.166.63.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a03:b0c0:2:d0::69:7001/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::601:40ff:fe23:1f01/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 04:01:40:23:1f:02 brd ff:ff:ff:ff:ff:ff
inet 10.133.248.54/16 brd 10.133.255.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::601:40ff:fe23:1f02/64 scope link
valid_lft forever preferred_lft forever Configuration files for CentOS (or Fedora) can be found in the / etc / sysconfig / network-scripts directory
$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE='eth0'
TYPE=Ethernet
BOOTPROTO=none
ONBOOT='yes'
HWADDR=04:01:40:23:1f:01
IPADDR=188.166.46.238
NETMASK=255.255.192.0
GATEWAY=188.166.0.1
NM_CONTROLLED='yes'
IPV6INIT=yes
IPV6ADDR=2A03:B0C0:0002:00D0:0000:0000:0069:7001/64
IPV6_DEFAULTGW=2A03:B0C0:0002:00D0:0000:0000:0000:0001
IPV6_AUTOCONF=no
DNS1=2001:4860:4860::8844
DNS2=2001:4860:4860::8888
DNS3=8.8.8.8It is necessary to create 4 files in the directory / etc / systemd / network /
$ cat /etc/systemd/network/90-external.link
[Match]
MACAddress=04:01:40:23:1f:01
[Link]
Name=eth-outer
$ cat /etc/systemd/network/90-internal.link
[Match]
MACAddress=04:01:40:23:1f:02
[Link]
Name=eth-inner
$ cat eth-external.network
[Match]
Name= eth-outer
[Network]
DHCP=no
Adress=188.166.46.238/18
Adress=2A03:B0C0:0002:00D0:0000:0000:0000:0069:7001/64
Gateway=188.166.0.1
Gateway= 2A03:B0C0:0002:00D0:0000:0000:0000:0000:0001
DNS=2001:4860:4860:8844
DNS=2001:4860:4860:8888
DNS=8.8.8.8
$ cat eth-internal.network
[Match]
Name=eth-inner
[Network]
Address=10.133.248.54/16That's it: the network configuration is complete. Now you can restart the service:
systemctl restart systemd-networkd
$ networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback n/a n/a
2 eth-outer ether routable configured
3 eth-inner ether routable configuredOther types of networks:
DHCP
In this example, we will configure DHCP IPv4 and IPv6; IPv6, if not needed, can be excluded.
$ cat /etc/systemd/network/wired-dhcp.network
[Match]
Name=eth*
[Network]
DHCP=ipv4
DHCP=ipv6Connection of the “Bridge” type
First creates a virtual interface configuration:
$ cat /etc/systemd/network/bridge.netdev
[NetDev]
Name=br0
Kind=bridge
$ cat /etc/systemd/network/bridge.network
[Match]
Name=br0
[Network]
DHCP=ipv4And configure the interface to connect:
$ cat /etc/systemd/network/wired.network
[Match]
Name=eth*
[Network]
Bridge=br0Disadvantages (not relevant, by and large, for servers)
1. Will not work without systemd.
2. There is no CLI or GUI frontends. Both NetworkManager and netctl do not suffer from this flaw. For example, to connect to WiFi, you need a command line. Not entirely relevant for the server.
3. For the first connection to WiFi, root privileges are required. However, this is not quite a drawback, since in the future, this wireless network will automatically connect.
4. If you are not careful, then the WiFi password can be stored in clear text in the command history. but this can be easily avoided in several ways: temporarily disable writing commands to history (for bash: set + o history, set -o history), use a shell that does not remember history (for example, dash), or simply manually remove the password from the history.
Benchmark
The speed of receiving addresses via DHCP is tested, Network manager and dnsmasq are disabled.
Soft:
- CentOS 7
- kernel-3.10.0-327.28.3.el7
- systemd 219
- ISC DHCP client daemon and dhclient-script 4.2.5
systemd-networkd
$ systemctl start systemd-networkd
$ journalctl -u systemd-networkd.service
Sep 01 13:04:41 localhost systemd[1]: Starting Network Service...
Sep 01 13:04:41 localhost systemd-networkd[4085]: Enumeration completed
Sep 01 13:04:41 localhost systemd[1]: Started Network Service.
Sep 01 13:04:41 localhost systemd-networkd[4085]: eth0: DHCPv4 address 192.168.1.114/24 via 192.168.1.1
Sep 01 13:04:41 localhost systemd-networkd[4085]: eth0: ConfiguredIn less than a second.
ISC DHCP
$ time dhclient -v eth0
Interface up - dhclient
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/enp2s0/94:de:80:1a:da:af
Sending on LPF/enp2s0/94:de:80:1a:da:af
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x5b763f4d)
DHCPACK from 192.168.1.1 (xid=0x5b763f4d)
bound to 192.168.1.115 -- renewal in 20662 seconds.
real 0m2.243s
user 0m0.042s
sys 0m0.216sThe average time after several attempts was 2.5 seconds.
Conclusion
In view of the active use of systemd by various top Linux distributions, we can conclude that, nevertheless, the community seeks to unify the basic system functions. These include, among other things, network configuration, and systemd, in turn, offers a convenient, fast and functional solution. And while this solution so far encounters the problem of the lack of a GUI for desktop systems, it will probably become the de facto standard for Linux servers and will replace a bunch of legacy daemons and separate utilities. This will make Linux much more convenient for containerization and use on virtual machines.