RHEL Networking with NetworkManager, ip, ss and Routing

Anil Jalela · Published Sep 3, 2026 · 8 min read

A network symptom crosses several decisions: link state, NetworkManager profile, address, route, neighbor resolution, local socket, firewall, SELinux, upstream policy and application protocol. Ping answers only one narrow question and may be blocked or deprioritized. Current RHEL administration uses NetworkManager for persistent connection ownership, with ip and ss for kernel evidence.

Keep persistent configuration and runtime evidence distinct

ip address and ip route show kernel state. nmcli connection shows persistent profiles and activation. A one-off ip change may work until the profile reactivates or the host reboots. Make owned persistent changes through NetworkManager, then verify the resulting kernel state.

DNS success, TCP connection and application response are separate. Test the destination name through the configured resolver, route selection for the resolved address, local/upstream policy, TCP/TLS negotiation and application behavior.

Walk the packet path in order

Change a remote profile without losing management

1. Record console recovery, retained session and current profile UUID.
2. Capture addresses, routes, rules, DNS and an application test.
3. Create or clone a candidate NetworkManager profile rather than overwriting the only path blindly.
4. Use an approved NetworkManager checkpoint or timed rollback where supported.
5. Activate the candidate and test gateway, resolver, management and application paths.
6. Confirm persistent state after reconnect/reboot, then remove only the superseded profile.

Inspect profile, route and socket ownership

nmcli general status
nmcli device status
nmcli -f NAME,UUID,TYPE,DEVICE,AUTOCONNECT connection show
nmcli connection show --active
ip -brief link
ip -brief address
ip rule show
ip route show table all
ip route get 203.0.113.10
ip neigh show
ss -lntup
resolvectl status 2>/dev/null || nmcli dev show | grep -E 'DNS|DOMAIN'
tracepath 203.0.113.10

• Documentation address 203.0.113.10 is not a live test destination; replace it with an approved endpoint.
• ip route get predicts kernel selection, including source address; it does not prove upstream return routing.
• A wildcard listener may still be blocked by firewall, SELinux or application access policy.
• Packet capture can expose credentials and customer data; filter narrowly and protect evidence.

Evidence and acceptance criteria

Worked scenario: a host is reachable but the application is not

SSH works, so the team assumes networking is healthy. The application listens only on loopback after a configuration change. Firewall rules and routes are correct, but remote clients receive connection refused. Adding a broad firewall rule cannot create a listener.

The operator uses ss to prove the bind address, checks the service configuration and changes it to the approved private address. A local request to that address and an intended remote client succeed; an unapproved source remains denied. The correction is at the application bind layer.

Practical how-to cases

nmcli device status
sudo nmcli con add type ethernet ifname enp1s0 con-name lab-static ipv4.method manual ipv4.addresses 192.0.2.10/24 ipv4.gateway 192.0.2.1 ipv4.dns 192.0.2.53
sudo nmcli con up lab-static
ip -brief address show enp1s0
ip route

sudo nmcli con mod lab-static +ipv4.routes '198.51.100.0/24 192.0.2.254'
sudo nmcli con up lab-static
ip route get 198.51.100.10
nmcli -f ipv4.routes con show lab-static

nmcli dev show enp1s0 | grep -E 'IP4.DNS|IP4.DOMAIN'
getent ahosts example.com
dig example.com A
ip route get 1.1.1.1
ping -c 2 192.0.2.53

ss -lntp
ip -brief address
curl -v http://127.0.0.1:8080/
firewall-cmd --get-active-zones
tracepath 192.0.2.20
tcpdump -ni enp1s0 tcp port 8080

sudo nmcli con mod lab-static ipv6.method manual ipv6.addresses 2001:db8:10::10/64 ipv6.gateway 2001:db8:10::1
sudo nmcli con up lab-static
ip -6 address show dev enp1s0
ip -6 route
ip -6 route get 2001:db8:20::20

Independent practice tasks

1. Create DHCP and static profiles and switch safely between them.
2. Configure two routes with metrics and predict route selection.
3. Diagnose duplicate address symptoms from neighbor evidence.
4. Capture a TCP handshake and label SYN, SYN-ACK, ACK and teardown.

For this lesson on RHEL NetworkManager and Routing, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: deleting the active profile or default route over the only SSH path can strand the server. Keep console and timed rollback.
• Unsafe: broad packet capture can collect secrets and personal data. Filter, encrypt, restrict and retain only as authorized.
• Unsafe: forcing speed/duplex without matching peer design can create loss; verify negotiation and both link ends.

Rewritten knowledge checks

Guided lab and acceptance test

1. Create a second lab NetworkManager profile with a static private address.
2. Capture route selection before and after activation.
3. Run a loopback-only test listener and prove remote refusal, then bind to the approved lab address.
4. Permit only one lab source through the firewall and test allowed and denied paths.
5. Change DNS for the candidate profile and verify resolver ownership and answer.
6. Reactivate/reboot, prove persistence, then remove only the lab profile.

Primary references

• RHEL 10 configuring and managing networking
• RHEL 10 documentation
• RHEL 9 documentation