RED HAT ENTERPRISE LINUX

Configuring Network Settings

Network Interfaces and NetworkManager Configuration

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this hands-on module on configuring network settings in Red Hat Enterprise Linux. In the previous module, we learned how to investigate network configuration. Now we'll learn how to change it. Network configuration is one of the most critical tasks for any system administrator. A misconfigured network can leave a server unreachable, disrupt services, or create security vulnerabilities. We'll focus on NetworkManager and its command-line tool nmcli - the standard way to configure networking on modern RHEL systems. You'll learn to create and modify network connections, configure static IP addresses, set up DNS, and manage hostname settings. We'll also cover the underlying configuration files and how to troubleshoot when things go wrong. By the end of this module, you'll be able to configure networking from scratch on a RHEL server, whether it's a simple DHCP client or a server with multiple static IP addresses.

Learning Objectives

Configure connections with nmcli

Create, modify, and manage network connections using the command line

Set static IP addressing

Configure IPv4 and IPv6 addresses, gateways, and DNS servers

Manage hostnames

Configure system hostname and understand hostname types

Understand configuration files

Know where network settings are stored and how to edit them

We have four main learning objectives for this module. First, we'll master configuring connections with nmcli. This is the command-line interface to NetworkManager and what you'll use most often on servers. You'll learn to create new connections, modify existing ones, and control which connections are active. Second, we'll configure static IP addressing. Servers typically need predictable IP addresses, so you'll learn to set IPv4 and IPv6 addresses, default gateways, and DNS servers. We'll also cover when to use DHCP versus static configuration. Third, we'll manage hostnames. A server's hostname is its identity on the network, and proper hostname configuration affects everything from logging to application behavior. You'll understand the different hostname types and how to configure them. Fourth, we'll understand the underlying configuration files. While nmcli is the preferred tool, knowing where settings are stored helps you troubleshoot and understand what's happening under the hood.

NetworkManager Architecture

NetworkManager is a daemon that manages network connections dynamically. It uses connection profiles that define network settings and can be activated on network devices.

nmcli / nmtui

→

NetworkManager

→

Connection Profiles

→

Network Devices

nmcli

Command-line interface for scripting and server administration

nmtui

Text-based UI for interactive configuration

nm-connection-editor

Graphical interface (desktop systems)

Configuration Files

Stored in /etc/NetworkManager/

NetworkManager is the central component of network configuration in modern RHEL. Understanding its architecture helps you work with it effectively. NetworkManager runs as a system daemon. It monitors network devices, manages connections, and applies configuration. It handles both wired and wireless networks, VPNs, and various connection types. Connection profiles are configuration sets that define how to set up a network connection - IP addresses, DNS servers, routes, etc. A profile can exist without being active. When you activate a connection on a device, NetworkManager applies those settings. You interact with NetworkManager through several interfaces. nmcli is the command-line tool - powerful, scriptable, and what you'll use on servers. nmtui provides a text-based menu interface - easier for interactive use when you don't remember exact nmcli syntax. nm-connection-editor is the graphical tool on desktop systems. All these tools modify the same underlying configuration. Connection profiles are stored as files in /etc/NetworkManager/system-connections/ (keyfile format in RHEL 9) or /etc/sysconfig/network-scripts/ (older ifcfg format). You can edit these files directly, but using nmcli ensures proper syntax and immediately notifies NetworkManager of changes.

Connections vs Devices

Connection (Profile)

Configuration template
Defines IP, DNS, gateway, etc.
Can exist without being active
Multiple connections per device possible
Stored in configuration files
Has a NAME and UUID

Device (Interface)

Physical or virtual network interface
ens33, eth0, wlan0, etc.
Can have 0 or 1 active connection
State: connected, disconnected, unmanaged
Detected by kernel/udev
Has a NAME (interface name)

# List connections (profiles)
[student@server ~]$ nmcli connection show
NAME    UUID                                  TYPE      DEVICE
ens33   a1b2c3d4-e5f6-7890-abcd-ef1234567890  ethernet  ens33
Home    b2c3d4e5-f6a7-8901-bcde-f23456789012  wifi      --

# List devices (interfaces)
[student@server ~]$ nmcli device status
DEVICE  TYPE      STATE         CONNECTION
ens33   ethernet  connected     ens33
lo      loopback  unmanaged     --

Understanding the difference between connections and devices is crucial for working with NetworkManager. A device is a network interface - physical hardware like an Ethernet port, or virtual like a bridge or VPN tunnel. Devices are detected by the kernel and have names like ens33 or eth0. A device can be connected (has an active connection), disconnected (no active connection), or unmanaged (NetworkManager isn't controlling it). A connection is a configuration profile - a saved set of network settings. It specifies everything: IP addressing method, addresses, DNS servers, routes, etc. Connections have names and UUIDs. The UUID is a globally unique identifier that never changes; the name is human-readable and can be changed. The key insight: you can have multiple connections for one device. You might have "Office" and "Home" profiles for a laptop's Ethernet, with different static IPs. Only one connection can be active on a device at a time, but you can switch between them. Conversely, a connection might not be active on any device - it's just a saved configuration waiting to be used. In the example output, "ens33" connection is active on ens33 device. "Home" is a saved WiFi profile but not currently active (DEVICE is --).

nmcli Command Structure

nmcli [OPTIONS] OBJECT { COMMAND | help }

# Objects:
nmcli general       # NetworkManager status
nmcli networking    # Overall networking control
nmcli connection    # Manage connections (con)
nmcli device        # Manage devices (dev)

Command	Description
nmcli con show	List all connections
nmcli con show "name"	Show details of specific connection
nmcli con up "name"	Activate a connection
nmcli con down "name"	Deactivate a connection
nmcli con add ...	Create a new connection
nmcli con mod "name" ...	Modify connection settings
nmcli con del "name"	Delete a connection
nmcli dev status	Show device status

nmcli follows a consistent structure that becomes natural with practice. The general pattern is nmcli, then an object type, then a command for that object type. The main objects you'll work with are: "general" for overall NetworkManager status and operations, "networking" for enabling/disabling all networking, "connection" (or "con" for short) for managing connection profiles, and "device" (or "dev") for managing network interfaces. For connections, the common commands are: "show" lists connections or shows details, "up" activates a connection, "down" deactivates it, "add" creates new connections, "mod" modifies existing connections, "del" deletes connections. For devices, "status" shows all interfaces, "show" gives details, "connect" and "disconnect" control connections on specific devices. You can abbreviate: "nmcli con show" equals "nmcli connection show". You can also use "c" for connection and "d" for device. Tab completion works with nmcli, making it easier to explore options and complete connection names. When specifying connections, you can use the name or UUID. Names are more readable; UUIDs are guaranteed unique if you have similarly-named connections.

Viewing Connection Details

# Show all settings for a connection
[student@server ~]$ nmcli connection show ens33
connection.id:                          ens33
connection.uuid:                        a1b2c3d4-e5f6-7890-abcd-ef1234567890
connection.type:                        802-3-ethernet
connection.interface-name:              ens33
connection.autoconnect:                 yes
ipv4.method:                            auto
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.dns:                               --
ipv6.method:                            auto
...

# Show only active connection settings (runtime values)
[student@server ~]$ nmcli -g ipv4.addresses connection show ens33
192.168.1.100/24

# Show specific fields
[student@server ~]$ nmcli -f ipv4 connection show ens33

# Compare configured vs active values
[student@server ~]$ nmcli connection show ens33 | grep ipv4
[student@server ~]$ nmcli device show ens33 | grep IP4

Viewing connection details reveals all the settings that define how a connection behaves. "nmcli connection show name" displays every setting for that connection. There are many settings, organized by category: connection (basic info), ipv4, ipv6, ethernet, and more depending on connection type. Key settings to understand: connection.id is the connection name, connection.uuid is the unique identifier, connection.interface-name binds to specific interface (or empty to bind to any compatible), connection.autoconnect controls automatic activation at boot. ipv4.method can be "auto" (DHCP), "manual" (static), or "disabled". When manual, ipv4.addresses lists the static addresses. ipv4.gateway is the default gateway, ipv4.dns lists DNS servers. The -g flag gets a specific value - useful in scripts. The -f flag filters to show only certain field groups. There's an important distinction: "nmcli connection show" shows the saved configuration - what will be used when the connection activates. "nmcli device show" shows current runtime values - what's actually in use now. For DHCP connections, the saved config shows "auto" but the device shows the actual assigned address. This difference matters when troubleshooting - is the problem in the configuration or did something change at runtime?

Creating Connections: DHCP

# Create a new DHCP connection
[root@server ~]# nmcli connection add \
    con-name "Office-DHCP" \
    type ethernet \
    ifname ens33

# Connection created - let's see it
[student@server ~]$ nmcli connection show
NAME         UUID                                  TYPE      DEVICE
Office-DHCP  c3d4e5f6-a7b8-9012-cdef-345678901234  ethernet  --
ens33        a1b2c3d4-e5f6-7890-abcd-ef1234567890  ethernet  ens33

# Activate the new connection
[root@server ~]# nmcli connection up Office-DHCP
Connection successfully activated

# Verify - note the new active connection
[student@server ~]$ nmcli device status
DEVICE  TYPE      STATE      CONNECTION
ens33   ethernet  connected  Office-DHCP

Default Settings: New Ethernet connections default to DHCP (ipv4.method auto), autoconnect enabled, and IPv6 auto-configuration.

Let's create our first connection. The simplest case is a DHCP connection - the server gets its IP address automatically from the network. The "nmcli connection add" command creates new connections. Required parameters are: con-name (the name you want to give it), type (ethernet, wifi, etc.), and usually ifname (which interface to use). For DHCP, that's all you need! The defaults are sensible: ipv4.method is "auto" meaning DHCP, autoconnect is "yes" meaning it'll activate at boot, and IPv6 is also auto-configured. After creating, the connection exists but isn't active - notice DEVICE is "--" in the listing. The original "ens33" connection is still active on the ens33 device. "nmcli connection up" activates the new connection. Since both connections are configured for ens33, activating the new one deactivates the old one - only one connection per device at a time. The device status now shows ens33 connected with "Office-DHCP". The previous connection still exists; it's just not active. This is the workflow: create the connection configuration, then activate it. You can create connections for interfaces that don't exist yet, or create multiple connections for the same interface to switch between later.

Creating Static IP Connections

# Create connection with static IPv4 configuration
[root@server ~]# nmcli connection add \
    con-name "Server-Static" \
    type ethernet \
    ifname ens33 \
    ipv4.method manual \
    ipv4.addresses 192.168.1.50/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "8.8.8.8,8.8.4.4"

# Create with multiple IP addresses
[root@server ~]# nmcli connection add \
    con-name "Multi-IP" \
    type ethernet \
    ifname ens33 \
    ipv4.method manual \
    ipv4.addresses "192.168.1.50/24,192.168.1.51/24" \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "8.8.8.8"

# Activate the static connection
[root@server ~]# nmcli connection up Server-Static

⚠ Remote Access: When changing IP on a remote server, ensure you have console access or the new IP is correct - wrong settings can lock you out!

Servers typically need static IP addresses so clients can reliably find them. Here's how to create a static IP connection. The key difference from DHCP is ipv4.method "manual" instead of "auto". Once you specify manual, you must provide the IP address details. ipv4.addresses takes the IP address in CIDR notation (192.168.1.50/24). The /24 subnet mask is essential - without it, NetworkManager might assume /32 (single host). You can specify multiple addresses separated by commas for servers that need multiple IPs on one interface. ipv4.gateway is your default gateway - where traffic goes when not destined for the local network. Without this, you can reach local hosts but not the Internet or other networks. ipv4.dns specifies DNS servers. Multiple servers can be comma-separated and are used in order. Consider what happens if you're connected remotely via SSH when you change IP addresses. The moment you activate the new connection, your SSH session uses the old IP and will disconnect. If the new configuration is wrong, you've locked yourself out. Always verify settings before activating, and have console access (physical, IPMI, or virtual) when making network changes on remote systems.

Modifying Connections

# Change from DHCP to static
[root@server ~]# nmcli connection modify ens33 \
    ipv4.method manual \
    ipv4.addresses 192.168.1.100/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "8.8.8.8"

# Add additional DNS server
[root@server ~]# nmcli connection modify ens33 +ipv4.dns "8.8.4.4"

# Remove a DNS server
[root@server ~]# nmcli connection modify ens33 -ipv4.dns "8.8.4.4"

# Add another IP address to existing connection
[root@server ~]# nmcli connection modify ens33 +ipv4.addresses "192.168.1.101/24"

# Disable autoconnect
[root@server ~]# nmcli connection modify ens33 connection.autoconnect no

# Changes saved but not active until reload
[root@server ~]# nmcli connection up ens33     # Reactivate to apply
[root@server ~]# nmcli connection reload        # Or reload all connections

+ and - prefixes: Use + to add to existing values (like adding DNS) and - to remove specific values without replacing everything.

Modifying existing connections is a common task - you might need to change IP addresses, add DNS servers, or adjust other settings. "nmcli connection modify" changes saved settings. The syntax is: nmcli con mod "connection-name" setting value. You can change multiple settings in one command. A crucial concept is the + and - prefixes. Without a prefix, setting a value replaces the existing value entirely. With + prefix, you add to the existing values. With - prefix, you remove a specific value. For example, setting ipv4.dns without prefix replaces all DNS servers. Using +ipv4.dns adds another server to the existing list. Using -ipv4.dns removes just that server. This matters for any setting that can have multiple values: addresses, DNS servers, routes, etc. Important: modifications are saved to the connection file but don't immediately affect a running connection. To apply changes to an active connection, either: reactivate it with "nmcli connection up name" (brief interruption), or use "nmcli connection reload" then "nmcli device reapply device" for less disruption. For the RHCSA exam and real-world work, remember this distinction between saved configuration and active state. Changes aren't applied until you explicitly activate them.

IPv6 Configuration

# Create connection with static IPv6
[root@server ~]# nmcli connection add \
    con-name "IPv6-Static" \
    type ethernet \
    ifname ens33 \
    ipv6.method manual \
    ipv6.addresses "2001:db8::10/64" \
    ipv6.gateway "2001:db8::1"

# Add IPv6 to existing connection (dual-stack)
[root@server ~]# nmcli connection modify ens33 \
    ipv6.method manual \
    ipv6.addresses "2001:db8::100/64" \
    ipv6.gateway "2001:db8::1"

# Disable IPv6 on a connection
[root@server ~]# nmcli connection modify ens33 ipv6.method disabled

# Enable IPv6 SLAAC (auto-configuration)
[root@server ~]# nmcli connection modify ens33 ipv6.method auto

# IPv6 with link-local only (no global address)
[root@server ~]# nmcli connection modify ens33 ipv6.method link-local

Dual-Stack: Modern servers should support both IPv4 and IPv6. Configure both on the same connection for full compatibility.

IPv6 configuration follows similar patterns to IPv4 but with some different options. IPv6 addresses use the ipv6.* settings. The method options differ slightly from IPv4. "auto" enables SLAAC (Stateless Address Auto-Configuration) where the host generates its own address based on the network prefix advertised by routers. This is like DHCP but without a central server assigning addresses. "manual" requires you to specify static addresses, just like IPv4. "disabled" completely disables IPv6 on the connection - no addresses at all. "link-local" configures only a link-local address (fe80::...) with no global address. Link-local is always present when IPv6 is enabled at all. "dhcp" uses DHCPv6 for address assignment - similar to IPv4 DHCP but less common than SLAAC. Most servers today should be dual-stack - configured for both IPv4 and IPv6. You can have both ipv4.method and ipv6.method configured on the same connection. They operate independently. IPv6 addresses are specified in standard notation with CIDR prefix: "2001:db8::10/64". Remember IPv6 addresses are 128 bits, so common prefixes are /64 for subnets, /128 for single hosts. If you're disabling IPv6 for security or compatibility reasons, use ipv6.method disabled. Simply not configuring an address still allows link-local addresses.

DNS Configuration

# Set DNS servers for a connection
[root@server ~]# nmcli connection modify ens33 ipv4.dns "8.8.8.8 8.8.4.4"

# Set DNS search domain
[root@server ~]# nmcli connection modify ens33 ipv4.dns-search "example.com lab.local"

# Prevent DHCP from overwriting DNS settings
[root@server ~]# nmcli connection modify ens33 ipv4.ignore-auto-dns yes

# View current DNS configuration
[student@server ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search example.com lab.local
nameserver 8.8.8.8
nameserver 8.8.4.4

# Check which connection provides DNS
[student@server ~]$ nmcli device show ens33 | grep DNS

Don't edit /etc/resolv.conf directly! NetworkManager regenerates it. Use nmcli to set DNS, or use /etc/hosts for local overrides.

DNS configuration determines how your system resolves hostnames to IP addresses. NetworkManager manages /etc/resolv.conf - the system's DNS configuration file. ipv4.dns sets the nameservers. You can specify multiple servers separated by spaces or commas. They're used in order - if the first doesn't respond, the system tries the second. ipv4.dns-search sets the search domains. When you look up an unqualified name like "server1", the system appends each search domain and tries "server1.example.com", then "server1.lab.local". This is convenient for internal hostnames. By default, DHCP connections also accept DNS servers from the DHCP server. These can override or supplement your manual settings. If you want to use only your specified servers, set ipv4.ignore-auto-dns to yes. NetworkManager generates /etc/resolv.conf automatically based on active connections. You shouldn't edit it directly - your changes will be overwritten. If you need persistent DNS settings, configure them in the connection with nmcli. For static hostname mappings that bypass DNS entirely, use /etc/hosts. Entries there take precedence over DNS lookups (configurable in /etc/nsswitch.conf). The DNS servers shown in /etc/resolv.conf come from whatever connection is currently active. "nmcli device show" shows the runtime DNS values actually in use.

Managing Connection State

# Activate a connection
[root@server ~]# nmcli connection up ens33

# Activate connection on specific device
[root@server ~]# nmcli connection up ens33 ifname ens33

# Deactivate a connection
[root@server ~]# nmcli connection down ens33

# Disconnect a device (deactivates whatever connection is on it)
[root@server ~]# nmcli device disconnect ens33

# Reconnect a device (activates its default connection)
[root@server ~]# nmcli device connect ens33

# Reload connection files (after manual edits)
[root@server ~]# nmcli connection reload

# Reapply connection settings without full reconnect
[root@server ~]# nmcli device reapply ens33

# Delete a connection
[root@server ~]# nmcli connection delete "Old-Connection"

Managing connection state is about controlling which connections are active and when. "nmcli connection up" activates a connection. If the connection specifies an interface (ifname), it uses that. If not, NetworkManager finds a suitable interface. If another connection was active on that interface, it's deactivated. "nmcli connection down" deactivates a connection. The interface remains but has no IP configuration. Note: if autoconnect is enabled, NetworkManager might immediately reactivate a connection! "nmcli device disconnect" is a more forceful way to ensure a device has no active connection. It won't auto-reconnect until you explicitly connect or reboot. "nmcli device connect" tells NetworkManager to activate the best available connection for that device - useful after a disconnect. "nmcli connection reload" rereads all connection files. Use this after manually editing files in /etc/NetworkManager/system-connections/. Without this, NetworkManager uses cached configurations. "nmcli device reapply" applies configuration changes to a device without fully deactivating and reactivating. This can be less disruptive for some changes, though not all changes can be reapplied - some require full reactivation. "nmcli connection delete" removes a connection entirely - the configuration file is deleted. This is permanent; the connection is gone.

Using nmtui

nmtui (NetworkManager Text User Interface) provides a menu-driven interface for network configuration - useful when you don't remember exact nmcli syntax.

# Launch nmtui
[root@server ~]# nmtui

Edit a connection

Create, modify, or delete connection profiles

Activate a connection

Turn connections on or off

Set system hostname

Change the system hostname

Navigation

Tab, arrows, Enter, Esc to navigate

When to use nmtui: Quick interactive changes, when you don't remember nmcli syntax, or when teaching networking concepts. For scripting and automation, use nmcli.

nmtui provides a text-based graphical interface for NetworkManager. It's perfect when you need to make changes interactively but don't remember the exact nmcli syntax. Launch it with just "nmtui". You'll see a menu with three options. "Edit a connection" lets you create new connections, modify existing ones, or delete them. You'll see a list of existing connections and can navigate through settings with a form-based interface. "Activate a connection" shows connections and their current state, letting you activate or deactivate them with a simple interface. "Set system hostname" changes the system hostname. Navigation uses keyboard: Tab moves between fields and buttons, arrow keys navigate within lists and menus, Enter selects or confirms, Escape goes back or cancels. nmtui makes the same changes as nmcli - it's just a different interface to NetworkManager. Changes made in nmtui appear in nmcli and vice versa. For the RHCSA exam, both nmcli and nmtui are valid ways to configure networking. nmcli is faster for simple commands and essential for scripting. nmtui is helpful when exploring options or making complex changes where you want to see all settings at once. In practice, you'll use both depending on the situation.

Hostname Configuration

The hostname identifies a system on the network. RHEL has three hostname types: static, transient, and pretty.

# View current hostname
[student@server ~]$ hostname
server.example.com

# View all hostname types
[student@server ~]$ hostnamectl
 Static hostname: server.example.com
       Icon name: computer-vm
         Chassis: vm
      Machine ID: a1b2c3d4...
         Boot ID: e5f6a7b8...
  Virtualization: vmware
Operating System: Red Hat Enterprise Linux 9.0
     CPE OS Name: cpe:/o:redhat:enterprise_linux:9::baseos
          Kernel: Linux 5.14.0-70.el9.x86_64
    Architecture: x86-64

# Set hostname (persistent)
[root@server ~]# hostnamectl set-hostname server.example.com

# Set just the static hostname
[root@server ~]# hostnamectl set-hostname server.example.com --static

# Set pretty hostname (human-friendly)
[root@server ~]# hostnamectl set-hostname "Web Server 01" --pretty

Hostname configuration is important for system identity, logging, and network services. A properly configured hostname helps identify systems in logs and makes management easier. RHEL has three hostname types. The static hostname is persistent, stored in /etc/hostname, and survives reboots. This is the primary hostname you should configure. The transient hostname is set by the kernel at runtime and can be changed by DHCP or other services. It's not persistent. The pretty hostname is a free-form, human-readable name that can include spaces and special characters - useful for display purposes. The "hostname" command shows the current effective hostname. "hostnamectl" shows all hostname types plus additional system information like virtualization, OS version, and architecture. "hostnamectl set-hostname" sets the hostname. Without flags, it sets all three types to versions of the specified name. Use --static, --transient, or --pretty to set specific types. For servers, use a fully qualified domain name (FQDN) like server.example.com. This helps with proper DNS resolution, SSL certificates, and application configuration. After setting the hostname, you may want to update /etc/hosts to include the new name mapped to 127.0.0.1 or your server's IP, ensuring local resolution works correctly.

Configuration Files

File/Directory	Purpose
/etc/NetworkManager/system-connections/	Connection profiles (keyfile format in RHEL 9)
/etc/sysconfig/network-scripts/	Legacy ifcfg connection files (RHEL 8 and earlier)
/etc/hostname	Static hostname
/etc/hosts	Local hostname to IP mappings
/etc/resolv.conf	DNS resolver config (managed by NM)
/etc/NetworkManager/NetworkManager.conf	NetworkManager daemon configuration

# View a connection file (RHEL 9 keyfile format)
[root@server ~]# cat /etc/NetworkManager/system-connections/ens33.nmconnection
[connection]
id=ens33
type=ethernet
interface-name=ens33

[ipv4]
method=manual
address1=192.168.1.100/24,192.168.1.1
dns=8.8.8.8;

Understanding where configuration is stored helps with troubleshooting and backup. In RHEL 9, connection profiles are stored in /etc/NetworkManager/system-connections/ using the "keyfile" format - INI-style files with .nmconnection extension. These are what nmcli creates and modifies. In RHEL 8 and earlier, the default was ifcfg format in /etc/sysconfig/network-scripts/. These files (ifcfg-*) use a different format. NetworkManager in RHEL 9 can still read ifcfg files but prefers keyfile. /etc/hostname contains just the static hostname - a single line with the FQDN. hostnamectl modifies this. /etc/hosts maps hostnames to IP addresses locally, bypassing DNS. Critical for systems that need to resolve names before DNS is available, or for local overrides. /etc/resolv.conf is managed by NetworkManager based on active connections. Don't edit directly - your changes will be lost. /etc/NetworkManager/NetworkManager.conf configures the NetworkManager daemon itself - plugins, DNS handling, and other global settings. You can edit connection files directly with a text editor, then run "nmcli connection reload" to make NetworkManager read the changes. This is useful for scripted deployments or complex configurations. However, nmcli is generally safer as it validates syntax.

Keyfile Format

[connection] id=Server-Static uuid=a1b2c3d4-e5f6-7890-abcd-ef1234567890 type=ethernet interface-name=ens33 autoconnect=true [ethernet] mac-address=00:0C:29:4E:66:A1 [ipv4] method=manual address1=192.168.1.100/24,192.168.1.1 dns=8.8.8.8;8.8.4.4; dns-search=example.com; [ipv6] method=auto

[connection] - Basic settings, name, type

[ethernet] - Ethernet-specific (MAC, MTU)

[ipv4] - IPv4 configuration

[ipv6] - IPv6 configuration

Note: address1 format is IP/prefix,gateway. Multiple addresses use address1, address2, etc. DNS entries end with semicolons.

The keyfile format is RHEL 9's default for storing connection profiles. Understanding this format helps you read configurations and make manual edits when needed. The file is organized into sections marked by brackets. [connection] contains basic information: id (the connection name), uuid (unique identifier - don't change this), type (ethernet, wifi, etc.), interface-name (which device to use), and autoconnect (whether to activate at boot). [ethernet] has Ethernet-specific settings. mac-address binds to a specific NIC - useful when interface names might change. You can also set MTU and other link-layer settings here. [ipv4] handles IPv4 configuration. method is "auto" for DHCP or "manual" for static. Addresses use a special format: address1=IP/prefix,gateway. The gateway is optional on the address line. Multiple addresses use address1, address2, etc. DNS servers are semicolon-separated and end with a semicolon. [ipv6] is similar but for IPv6. Other sections exist for other connection types: [wifi] for wireless, [vpn] for VPN connections, [802-1x] for 802.1X authentication, etc. Files must be owned by root with 600 permissions (for security - they might contain passwords). After manual edits, run "nmcli connection reload" to apply changes.

Testing and Verification

# Verify interface configuration
[student@server ~]$ ip addr show ens33
[student@server ~]$ nmcli device show ens33

# Verify routing
[student@server ~]$ ip route
[student@server ~]$ ip route get 8.8.8.8

# Verify DNS
[student@server ~]$ cat /etc/resolv.conf
[student@server ~]$ dig google.com

# Test connectivity
[student@server ~]$ ping -c 3 192.168.1.1      # Gateway
[student@server ~]$ ping -c 3 8.8.8.8          # Internet (IP)
[student@server ~]$ ping -c 3 google.com       # Internet (DNS)

# Verify hostname
[student@server ~]$ hostnamectl
[student@server ~]$ hostname -f                 # FQDN

# Check NetworkManager logs for issues
[student@server ~]$ journalctl -u NetworkManager --since "5 minutes ago"

After making network configuration changes, verification is essential. Always test before assuming changes worked. For interface configuration, "ip addr show" displays the actual runtime configuration - IP addresses, netmask, and state. "nmcli device show" shows both runtime values and additional NetworkManager-specific information. For routing, "ip route" shows the full routing table. Verify the default gateway is present and points to the correct address. "ip route get" tests routing to a specific destination - useful for troubleshooting. For DNS, check /etc/resolv.conf to see which servers are configured, then test actual resolution with dig or host. If the file shows unexpected servers, check which connection is active and its DNS settings. Test connectivity in layers: first ping the gateway (tests local network), then ping an external IP like 8.8.8.8 (tests routing), then ping a hostname (tests DNS). This sequence helps isolate where problems occur. Verify hostname with hostnamectl and "hostname -f" for the fully qualified domain name. The FQDN is what many applications use for identification. If something isn't working, check the NetworkManager journal with journalctl. It logs connection activations, failures, and details about why things might not work as expected.

Common Tasks

# Task: Change server from DHCP to static IP
[root@server ~]# nmcli con mod ens33 ipv4.method manual \
    ipv4.addresses 192.168.1.100/24 \
    ipv4.gateway 192.168.1.1 \
    ipv4.dns "8.8.8.8 8.8.4.4"
[root@server ~]# nmcli con up ens33

# Task: Add a second IP address
[root@server ~]# nmcli con mod ens33 +ipv4.addresses 192.168.1.101/24
[root@server ~]# nmcli con up ens33

# Task: Set hostname and update /etc/hosts
[root@server ~]# hostnamectl set-hostname server.example.com
[root@server ~]# echo "192.168.1.100 server.example.com server" >> /etc/hosts

# Task: Disable IPv6
[root@server ~]# nmcli con mod ens33 ipv6.method disabled
[root@server ~]# nmcli con up ens33

# Task: Use custom DNS, ignore DHCP DNS
[root@server ~]# nmcli con mod ens33 ipv4.dns "10.0.0.53" ipv4.ignore-auto-dns yes
[root@server ~]# nmcli con up ens33

Let's cover common configuration tasks you'll encounter in real-world administration. Converting from DHCP to static is frequent for servers. Change the method to manual and specify the address, gateway, and DNS. Remember to reactivate to apply changes. If you're connected remotely, ensure the new IP is correct! Adding a second IP address to an interface is common for servers hosting multiple services. Use the + prefix to add an address without removing existing ones. Both addresses will be active on the interface. Setting the hostname properly involves both hostnamectl and usually updating /etc/hosts. The hosts file entry ensures the system can resolve its own name even before network-based DNS is available. Many applications check this at startup. Disabling IPv6 might be needed in environments that don't support it, or for troubleshooting. Set ipv6.method to disabled and reactivate. Note that some applications may behave unexpectedly without IPv6. Using custom DNS while ignoring DHCP-provided DNS is common in enterprise environments with internal DNS servers. Set your preferred servers and enable ignore-auto-dns to prevent DHCP from overriding them. All these tasks follow the same pattern: modify the connection settings, then reactivate to apply. This pattern becomes second nature with practice.

Troubleshooting

# Problem: Connection won't activate
[root@server ~]# journalctl -u NetworkManager -n 50    # Check logs
[root@server ~]# nmcli connection show "con-name"       # Verify settings

# Problem: IP address not assigned
[student@server ~]$ nmcli device status                  # Is device connected?
[student@server ~]$ ip link show ens33                   # Is link UP?

# Problem: Can't reach gateway
[student@server ~]$ ip route                             # Is gateway in table?
[student@server ~]$ ip addr                              # Correct IP/subnet?

# Problem: Can reach IP but not hostnames
[student@server ~]$ cat /etc/resolv.conf                 # DNS configured?
[student@server ~]$ dig @8.8.8.8 google.com              # DNS server working?

# Problem: Changes not taking effect
[root@server ~]# nmcli connection reload                # Reload files
[root@server ~]# nmcli connection up ens33              # Reactivate

# Problem: Connection auto-activates when you don't want it
[root@server ~]# nmcli connection modify ens33 connection.autoconnect no

Network troubleshooting follows a systematic approach. Here are common problems and their solutions. Connection won't activate: Check NetworkManager logs first - they usually explain why. Common causes include incorrect interface names, conflicting connections, or invalid settings. Verify the connection configuration with nmcli connection show. IP address not assigned: Check if the device is connected (nmcli device status) and if there's physical link (ip link show). For DHCP, ensure the server is reachable and responding. For static, verify the address format is correct. Can't reach gateway: Ensure the gateway is in the routing table (ip route). Verify your IP address and subnet mask are correct - a wrong subnet mask can prevent gateway communication. Check that your IP and gateway are on the same subnet. Can reach IP but not hostnames: This is DNS. Check /etc/resolv.conf for configured servers. Test DNS directly with dig @server to see if the server responds. If using custom DNS, check ignore-auto-dns isn't preventing your settings. Changes not taking effect: Remember that modifications are saved but not applied until the connection is reactivated. Use reload if you edited files directly, then up to activate. Unwanted auto-activation: If a connection keeps activating when you don't want it, disable autoconnect. This is common when testing multiple configurations.

Best Practices

✓ Do

Use static IPs for servers
Document all network changes
Have console access before changes
Test configuration before production
Use meaningful connection names
Configure both IPv4 and IPv6
Set proper hostnames (FQDN)
Backup configs before modifying

✗ Don't

Edit /etc/resolv.conf directly
Make remote changes without backup access
Use duplicate IP addresses
Forget to reactivate after changes
Leave default connection names
Ignore IPv6 configuration
Skip verification after changes
Forget to set autoconnect appropriately

RHCSA Exam Tip: On the exam, verify networking works after each configuration change. Lost network connectivity can prevent you from completing other tasks!

Following best practices prevents problems and makes administration easier. Use static IPs for servers. DHCP is convenient but addresses can change. Servers need predictable addresses for DNS, firewall rules, and client configuration. Document changes. Note what you changed, when, and why. This helps troubleshooting and handoff to other administrators. Always have console access before making network changes on remote systems. A wrong IP configuration can lock you out, and there's no remote way to fix it. Test configurations in non-production first if possible. Even simple changes can have unexpected effects. Use meaningful connection names. "ens33" doesn't tell you anything; "Production-Network" or "Backup-VLAN" describes the purpose. Configure both IPv4 and IPv6 for future compatibility, even if IPv6 isn't actively used yet. Set proper fully qualified hostnames. Many applications and services expect this for proper operation. Don't edit resolv.conf directly - NetworkManager will overwrite it. Don't make changes remotely without backup access. Don't use duplicate IPs on the network. Don't forget to reactivate connections after modifications. Don't skip verification - always test that changes work as expected. For the RHCSA exam, working networking is crucial. Many tasks require network access, so verify connectivity works after any network changes before moving on.

Key Takeaways

nmcli: Primary tool for network config; connection add/modify/up/down for managing connections

Static IP: ipv4.method manual, specify addresses, gateway, and DNS; reactivate to apply

Hostname: Use hostnamectl set-hostname; update /etc/hosts for local resolution

Files: Connections in /etc/NetworkManager/system-connections/; verify with ip addr and ping

Let's summarize the essential network configuration skills covered in this module. nmcli is your primary tool for network configuration. Master the connection commands: add to create, modify to change, up and down to control state, delete to remove. Use nmtui for interactive configuration when you need it. Static IP configuration requires ipv4.method manual, then specifying addresses (in CIDR notation), gateway, and DNS servers. Remember changes are saved but not applied until you reactivate the connection. This is a critical point that catches many people. Hostname configuration uses hostnamectl. Always use a fully qualified domain name for servers. Update /etc/hosts so the system can resolve its own name locally. Connection files are stored in /etc/NetworkManager/system-connections/ in keyfile format. You can edit these directly but nmcli is safer. Always verify with ip addr and connectivity tests after changes.

Graded Lab

Create a new connection with DHCP, activate it, and verify
Modify the connection to use static IP, gateway, and DNS
Add a second IP address to the connection
Configure system hostname to a FQDN and update /etc/hosts
View and understand the keyfile configuration format
Practice activating/deactivating connections and verify changes

Next: Configuring and Securing SSH