Most current Linux distributions use NetworkManager for creating and managing network connections. That means I need to understand it as a system administrator. In a series of articles, I will share what I've learned to date and why I think NetworkManager is an improvement over past options.
Red Hat introduced NetworkManager in 2004 to simplify and automate network configuration and connections, especially wireless connections. The intent was to relieve users from the task of manually configuring each new wireless network before using it. NetworkManager can manage wired network connections without interface configuration files, although it uses network connection files for wireless connections.
In this article, I'll review what NetworkManager is and how to use it to view network connections and devices for Linux hosts. I'll even solve a couple of problems in the process.
What NetworkManager replaces
NetworkManager is a replacement for previous network management tools. The original interface configuration command, ifconfig
, and its interface configuration files are obsolete. You can see this in the ifconfig
man pages, which contain a note stating just that.
The ip
command replaces the ifconfig
command and performs essentially the same tasks. Both commands have coexisted for some time now, allowing Sysadmins to use either one, which keeps scripts dependent upon ifconfig
functional. Although its man pages do not yet indicate it, the ifconfig
command is obsolete, and NetworkManager has made it so in practice.
It is now time to rewrite those scripts, because using NetworkManager commands makes the most sense.
How NetworkManager works
NetworkManager is run as a systemd service and is enabled by default. NetworkManager works with D-Bus to detect and configure network interfaces as they are plugged into the Linux computer. This plug-and-play management of network interfaces makes plugging into new networks—both wired and wireless—trivially easy for the user. When previously installed network interfaces are detected during Linux startup, they are treated exactly like a device plugged in after the system is already up and running. Treating all devices as plug-and-play in every instance makes handling those devices easier for the operating system, since there is only one code base to deal with both sets of circumstances.
The udev daemon creates an entry for each network interface card (NIC) installed in the system in the network rules file. D-Bus signals the presence of a new network device—wired or wireless—to NetworkManager. NetworkManager then listens to the traffic on the D-Bus and responds by creating a configuration for this new device. Such a configuration is, by default, stored only in RAM and is not permanent. It must be created every time the computer is booted.
NetworkManager uses the information from D-Bus to initialize each NIC. It first looks for configuration files that provide a more permanent static configuration. When notified of a new device, NetworkManager checks for the existence of old network interface configuration files (ifcfg-*
) in /etc/sysconfig/network-scripts
. The ifcfg-rh plugin allows the use of these legacy files for backward compatibility.
Next, NetworkManager looks for its own interface connection files, located in the /etc/NetworkManager/system-connections
directory. Most distributions, including Fedora, keep their network connection files in the /etc/NetworkManager/system-connections
directory, using the network's name as the file name.
For example, my System76 Oryx Pro laptop originally used POP!_OS
. I have replaced this with Fedora, which is currently at release 35, and each wireless connection I have made with it has a file in /etc/NetworkManager/system-connections
. These maintain a record of the service set identifier (SSID) and wireless passwords for each network. The Dynamic Host Configuration Protocol (DHCP) server in the wireless router provides the rest of the network configuration data for these wireless connections. For security purposes, because these files contain passwords, they are read/write only by the root user, just like system account files /etc/passwd
and /etc/shadow
.
The /etc/NetworkManager/system-connections directory
on that laptop contained files for the wired network as well as each of the wireless networks I connected with. The structure of these files is different from the old ifcfg
files, but they are in ASCII plain text format and are readable and easily understandable.
This process is sequence sensitive. The first set of configuration files found is used. If no configuration files are found, NetworkManager generates a configuration using the data from a DHCP server. If an interface configuration file does not exist, plugging in a new device or connecting with a new wireless network causes udev to notify NetworkManager of the new device or wireless connection. In Fedora up through release 28, NetworkManager creates the new interface configuration file. Beginning with Fedora 29 and higher, NetworkManager creates only the connection and does not create an interface configuration file.
If no configuration files or DHCP server is found, no network connection is possible.
Viewing interface configuration
NetworkManager's command-line interface program, nmcli, provides several options to determine the current state of any network interface hardware installed in the host as well as currently active connections. The nmcli program can manage networking on any host, whether it uses a graphical user interface (GUI) or not, so it can also manage remote hosts over a secure shell (SSH) connection. It works on both wired and wireless connections.
I'll start with some basic information for using the nmcli tool. I'm using a Fedora system I have set up as a router, since an example with multiple network interfaces will be more interesting than a simple workstation host with only a single interface.
I'll start with the easiest command, nmcli
with no options. This simple command shows information similar to the now obsolete ifconfig
command, including the name and model of the NIC, the media access control (MAC) address and (internet protocol) IP address, and which NIC is configured as the default gateway. It also shows the DNS configuration for each interface.
The nmcli command requires admin privileges. Most distributions recommend that you use sudo
but I just switch to the root
user.
$ su -
# nmcli
enp4s0: connected to enp4s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:04:44:03, hw, mtu 1500
ip4 default, ip6 default
inet4 45.20.209.41/29
route4 0.0.0.0/0
route4 45.20.209.40/29
inet6 2600:1700:7c0:860:8616:f9ff:fe04:4403/64
inet6 fe80::8616:f9ff:fe04:4403/64
route6 2600:1700:7c0:860::/64
route6 ::/0
enp1s0: connected to enp1s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:E9:89, hw, mtu 1500
inet4 192.168.10.1/24
route4 192.168.10.0/24
inet6 fe80::8616:f9ff:fe03:e989/64
route6 fe80::/64
enp2s0: connected to enp2s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:FD:85, hw, mtu 1500
inet4 192.168.0.254/24
route4 192.168.0.0/24
inet6 fe80::8616:f9ff:fe03:fd85/64
route6 fe80::/64
eno1: unavailable
"Intel I219-V"
ethernet (e1000e), 04:D9:F5:1C:D5:C5, hw, mtu 1500
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.0.52 8.8.8.8 8.8.4.4
interface: enp4s0
servers: 192.168.0.52 8.8.8.8
interface: enp1s0
servers: 192.168.0.52 8.8.8.8
interface: enp2s0
Use the command nmcli device show
to get complete information about known devices and nmcli connection show
to get an overview of active connection profiles. Consult nmcli(1) and nmcli-examples(7) manual pages for complete usage details. You can also issue the help command, nmcli -h
, as the root user to view the basic top-level nmcli
commands:
# nmcli -h
Usage: nmcli [OPTIONS] OBJECT { COMMAND | help }
OPTIONS
-a, --ask ask for missing parameters
-c, --colors auto|yes|no whether to use colors in output
-e, --escape yes|no escape columns separators in values
-f, --fields <field,...>|all|common specify fields to output
-g, --get-values <field,...>|all|common shortcut for -m tabular -t -f
-h, --help print this help
-m, --mode tabular|multiline output mode
-o, --overview overview mode
-p, --pretty pretty output
-s, --show-secrets allow displaying passwords
-t, --terse terse output
-v, --version show program version
-w, --wait <seconds> set timeout waiting for finishing operations
OBJECT
g[eneral] NetworkManager's general status and operations
n[etworking] overall networking control
r[adio] NetworkManager radio switches
c[onnection] NetworkManager's connections
d[evice] devices managed by NetworkManager
a[gent] NetworkManager secret agent or polkit agent
m[onitor] monitor NetworkManager changes
Note that the objects can be spelled out or abbreviated down to the first character. These objects are all unique, so only the first character is required to specify any single object.
Try nmcli g
to view the general status.
# nmcli g
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled enabled enabled
That output does not show very much. I also know that the host, in this case, has no WiFi hardware, so this is a misleading result. You should not use the nmcli g
command for that reason. Better object commands are c
[onnection] and d
[evice], which are the ones I use most frequently.
# nmcli c
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0
enp0s20f0u7 0f5427bb-f8b1-5d51-8f74-ac246b0b00c5 ethernet --
enp1s0 abf4c85b-57cc-4484-4fa9-b4a71689c359 ethernet --
# nmcli d
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet connected enp4s0
enp1s0 ethernet connected enp1s0
enp2s0 ethernet connected enp2s0
eno1 ethernet unavailable --
lo loopback unmanaged --
There is a lot of really interesting information here. Notice that the last two entries using the c
object command have no entries in the device column. This result could mean either that they are not active or do not exist or that there are one or more configuration errors.
The additional information we get using the d
object command does not even show the enp0s20f0u7 device. It also shows device eno1 (a motherboard device), which was not displayed using the c
object command.
Your output should look more like this, though the device name will be different, and it will depend on the specific location on the PCI bus the NIC is connected to.
# nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 6e6f63b9-6d9e-3d13-a3cd-d54b4ca2c3d2 ethernet enp0s3
# nmcli d
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet connected Wired connection 1
lo loopback unmanaged --
It seems that I have a couple of anomalies to explore. First, I want to know what device enp0s20f0u7 is in the connection list. Since NetworkManager does not recognize this device in the device list, there is probably a network configuration file in /etc/sysconfig/network-scripts
even though no such hardware device exists on the host. I checked that directory, found the interface configuration file, and displayed the contents.
# ls -l
total 20
-rw-r--r-- 1 root root 352 Jan 2 2021 ifcfg-eno1
-rw-r--r-- 1 root root 419 Jan 5 2021 ifcfg-enp0s20f0u7
-rw-r--r-- 1 root root 381 Jan 11 2021 ifcfg-enp1s0
-rw-r--r-- 1 root root 507 Jul 27 2020 ifcfg-enp2s0
-rw-r--r-- 1 root root 453 Jul 27 2020 ifcfg-enp4s0
cat ifcfg-enp0s20f0u7
# Interface configuration file for ifcfg-enp0s20f0u7
# This is a USB Gb Ethernet dongle
# This interface is for the wireless routers
# Correct as of 20210105
TYPE="Ethernet"
BOOTPROTO="static"
NM_CONTROLLED="yes"
DEFROUTE="no"
NAME=enp0s20f0u7
UUID="fa2117dd-6c7a-44e0-9c9d-9c662716a352"
ONBOOT="yes"
HWADDR=8c:ae:4c:ff:8b:3a
IPADDR=192.168.10.1
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8
After looking at this file, I recalled that I had used a USB Gigabit dongle for a while because the motherboard NIC installed on that host had apparently failed. That was a quick fix, and I later installed a new NIC on the PCIe motherboard bus, so I could remove this interface configuration file. I did not delete it, however; I moved it to the /root
directory in case I ever need it again.
Notice the comments I used to ensure that my future self or another system administrator would have some understanding of why this file exists.
The second anomaly is why the entry for enp1s0 appears twice. This can only occur when the NIC name is specified in more than one interface configuration file. So I tried the following steps, and sure enough, enp1s0 erroneously appears in the ifcfg-eno1
configuration file as well as the ifcfg-enp1s0
file.
# grep enp1s0 *
ifcfg-eno1:NAME=enp1s0
ifcfg-enp1s0:# Interface configuration file for enp1s0 / 192.168.10.1
ifcfg-enp1s0:NAME=enp1s0
# cat ifcfg-eno1
## Interface configuration file for eno1 / 192.168.10.1
## This interface is for the wireless routers
## Correct as of 20200727
TYPE="Ethernet"
BOOTPROTO="static"
NM_CONTROLLED="yes"
DEFROUTE="no"
NAME=enp1s0
ONBOOT="yes"
HWADDR=04:d9:f5:1c:d5:c5
IPADDR=192.168.10.1
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8
I changed the NAME to NAME=eno1 and restarted NetworkManager. The changes in the interface configuration files are not activated until I restart NetworkManager. The device and connection results now look like this. I am still not using the onboard NIC, which is probably fine now that I have removed the wrong name from the ifcfg-eno1
interface configuration file. That will require downtime for that router.
# systemctl restart NetworkManager
# nmcli d
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet connected enp4s0
enp1s0 ethernet connected enp1s0
enp2s0 ethernet connected enp2s0
eno1 ethernet unavailable --
lo loopback unmanaged --
# nmcli c
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0
eno1 abf4c85b-57cc-4484-4fa9-b4a71689c359 ethernet --
Another option is to show only the active connections. This is a good option with clean results, but it can also mask other problems if you use it exclusively.
# nmcli connection show --active
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0
Having changed the device name in the ifcfg-eno1
file to the correct one, I suspect that the motherboard NIC, eno1, will work again. I will experiment with that the next time I have a maintenance session on that host.
Isn't that more interesting than a host with a single NIC? And I found some problems in the process.
Using NetworkManager tools to manage networking is covered in the Red Hat Enterprise Linux (RHEL) 8 document "Configuring and Managing Networking."
Final thoughts
I am a fan of the "if it ain't broke, don't fix it" philosophy. However, even the simplest use of NetworkManager from the command line, viewing the current state of the network devices and connections, has shown me two anomalies in my previous configurations that I had missed. I am now a fan of NetworkManager. The older tools were good, but NetworkManager is better; the additional information it provides is invaluable.
In part 2 of this series, I will discuss managing network interfaces.
1 Comment