Get started with NetworkManager on Linux

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.