Configure network interfaces with NetworkManager and CLI tools

Network problems often start with one simple mistake: wrong interface settings. On Linux, you can configure interfaces through NetworkManager or directly with CLI tools like ip. Entry-level technicians should learn both. NetworkManager gives persistent, structured settings. Raw CLI commands are fast for testing and recovery. In production, mixing both without a plan can cause outages after reboot, because temporary and persistent settings do not always match.

Know what is managing the interface first

Before you change anything, confirm who owns the network configuration. If NetworkManager manages an interface, use nmcli for persistent changes. If you use ip addr add directly, that change is usually temporary and disappears on restart or link reset.

For beginners, this avoids confusion when "it worked five minutes ago" but fails after reboot. For operators, it avoids split-brain configuration where one tool overwrites another.

# See devices and state
nmcli device status

# Show connection profiles (persistent config)
nmcli connection show

# Show active connections only
nmcli -f NAME,DEVICE,TYPE connection show --active

# Check current kernel view of link and IP state
ip -br link
ip -br -4 addr

If a server has multiple NICs, map profile names to real devices before editing. On many systems, names like ens18 or enp1s0 are predictable but not human-friendly. A wrong target interface can cut remote access.

Configure a static IPv4 address with NetworkManager

This is the safe default path when NetworkManager is in use. You edit one connection profile, then reactivate it. The change persists across reboot.

# Example: set static IPv4 on profile "Wired connection 1"
sudo nmcli connection modify "Wired connection 1" \
  ipv4.addresses "192.168.10.25/24" \
  ipv4.gateway "192.168.10.1" \
  ipv4.dns "1.1.1.1 9.9.9.9" \
  ipv4.method manual

# Bring profile down and up to apply cleanly
sudo nmcli connection down "Wired connection 1"
sudo nmcli connection up "Wired connection 1"

# Verify applied values
nmcli -f GENERAL.DEVICE,IP4.ADDRESS,IP4.GATEWAY,IP4.DNS connection show "Wired connection 1"
ip route
resolvectl status

Production consequence: setting ipv4.method manual without a valid gateway can isolate the host from package mirrors, monitoring, and central logging. Always validate route and DNS immediately after activation.

If you need DHCP again, switch method back instead of deleting random fields:

sudo nmcli connection modify "Wired connection 1" ipv4.method auto
sudo nmcli connection up "Wired connection 1"

Use raw CLI tools for temporary testing and emergency rollback

The ip tool changes the running state in kernel memory. This is useful when testing a new subnet, proving a route problem, or restoring short-term access during incident response. Treat these as temporary unless you also update the NetworkManager profile.

# Add temporary address (does not survive reboot)
sudo ip addr add 192.168.10.99/24 dev ens18

# Add temporary default route
sudo ip route replace default via 192.168.10.1 dev ens18

# Test connectivity
ping -c 3 192.168.10.1
ping -c 3 1.1.1.1

# Remove temporary address when done
sudo ip addr del 192.168.10.99/24 dev ens18

This pattern is practical in maintenance windows. You can validate a new gateway before committing persistent changes. For beginners, the key point is simple: if you used ip, document it and convert it to profile settings, or it will vanish later.

Validate routing and DNS after every interface change

An interface can be "up" and still be wrong for production traffic. You need to check route selection and name resolution, not only link status.

# Route decision for public IP
ip route get 8.8.8.8

# Default route and metric
ip route show default

# Resolver path through libc
getent hosts example.com

# Resolver service status (systemd-resolved based systems)
resolvectl status

# Check if required service ports are still listening
ss -tulpen | grep -E ':22|:80|:443'

Real consequence in production: a bad DNS server can make applications look slow or broken even when the interface and gateway are correct. A bad route metric can send traffic out the backup link and trigger firewall drops. This is why post-change verification should be scripted in runbooks.

Compatibility notes for current distributions

The command logic is similar across major distributions, but the default network stack differs by installation type. These notes are useful for Debian 13.3, Ubuntu 24.04.3 LTS, Ubuntu 25.10, Fedora 43, RHEL 10.1, and RHEL 9.7.

• Debian 13.3: server installs may still use ifupdown and /etc/network/interfaces, while desktop or customized images may use NetworkManager. Confirm with systemctl is-active NetworkManager before changing method.
• Ubuntu 24.04.3 LTS and Ubuntu 25.10: Netplan is common on servers. Netplan can render to NetworkManager or systemd-networkd. If renderer is NetworkManager, nmcli is valid; otherwise edit Netplan YAML and apply carefully.
• Fedora 43: NetworkManager is standard on workstation and server profiles. nmcli keyfile-based workflow is the normal persistent path.
• RHEL 10.1 and RHEL 9.7: both rely on NetworkManager by default. Most nmcli procedures are compatible between 9.7 and 10.1, which helps teams operating mixed fleets.

# Quick check: who manages networking on this host?
systemctl is-active NetworkManager
networkctl status 2>/dev/null | head
ls /etc/netplan 2>/dev/null

# On RHEL/Fedora family, inspect keyfile location
sudo ls -l /etc/NetworkManager/system-connections/

When handling remote systems, keep console access ready (hypervisor console, iDRAC, iLO, or cloud serial console). One wrong default route can lock out SSH instantly.

Summary

Use NetworkManager for persistent interface configuration and use raw CLI tools for controlled temporary testing. After every change, verify address, route, DNS, and service reachability in that order. This workflow is easy for beginners to follow and reliable for production teams. It also stays consistent across Debian 13.3, Ubuntu 24.04.3 LTS and 25.10, Fedora 43, and RHEL 10.1 with strong overlap for RHEL 9.7.