Usually on Linux desktops, NetworkManager is used to manage network settings, since it does an excellent job and has GUI front-ends for all popular graphical environments. However, on Linux servers its use is not advisable: it consumes a lot of resources. NetworkManager occupies about 20 MB in RAM, while systemd-networkd and systemd-resolvd together less than 2 MB. For this reason, the default
Linux server server distributions often use various proprietary daemons.
Thus, a whole zoo of scripts and utilities emerges: the networking daemon under Debian, which manages the network configuration via ifupdown, using 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 should not a thing that is so simple and common to various systems as setting up a network have the same look?
We suggest starting to use the quick and easy
systemd-networkd daemon , especially since many distributions have already switched to systemd, so switching to systemd-networkd is easy. 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 demons.
Start systemd-networkd
Despite the passions that were raging around the
systemd implementation, many popular Linux distributions began using this service manager and delivering it by default. Therefore, your system probably already contains everything you need to enable systemd-networkd. Requires systemd version 210 and above.
You can check the version with the command:
$ systemctl
To use, start the following two services and turn them on when the system boots (disabling the other daemons that control the network configuration):
$ systemctl enable systemd-networkd $ systemctl start systemd-networkd $ systemctl enable systemd-resolved $ systemctl start systemd-resolved
Configuration
As an example of switching, consider the transfer of the default network configuration in CentOS (/etc/rc.d/init.d/network initscript) to systemd-networkd.
Completely similar move can be done for Fedora and, with minor changes, 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 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: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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
The configuration files for CentOS (or Fedora) can be found in the directory / etc / sysconfig / network-scripts
$ 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.8
You need to create 4 files in the / etc / systemd / network / directory
$ 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/16
That'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 configured
Other types of networks:
DHCP
In this example, we 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=ipv6
Connection type "Bridge"
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=ipv4
And configure the interface to connect:
$ cat /etc/systemd/network/wired.network [Match] Name=eth* [Network] Bridge=br0
Disadvantages (not relevant, by and large, for servers)
1. Will not work without systemd.
2. There is no CLI or front-end GUI. Both NetworkManager and netctl do not suffer from this disadvantage. For example, to connect to WiFi, you need a command line. Not quite relevant for the server.
3. For the first connection to WiFi, you need root rights. However, this is not at all a disadvantage, since in the future, this wireless network will be automatically connected.
4. If you are not careful, the WiFi password can be stored in clear text in the command history. but this can be easily avoided in several ways: temporarily disable the recording of commands in history (for bash: set + o history, set -o history), use a shell that does not store history (for example, dash), or simply manually delete a password from history.
Benchmark
Testing the speed of obtaining addresses via DHCP, Network manager and dnsmasq 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: Configured
In 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
The average time after several attempts was 2.5 seconds.
Conclusion
In view of the active use of systemd by various top Linux distributions, it can be concluded that, nevertheless, the community is striving to unify the main system functions. These include, among other things, network configuration, and systemd, in turn, offers a convenient, fast and functional solution. And while this solution faces the problem of the lack of a GUI for desktop systems, but for
Linux servers it will probably become a “de facto” standard and will replace a bunch of legacy demons and individual utilities. This will make Linux much more convenient for containerization and use in virtual machines.