Change an address without losing the connection

short · 30 min · Objective 1.4

Task

Configure a network interface persistently, and learn the difference between a change that survives a reboot and one that does not -- by making both and rebooting. Then use the safety mechanisms that stop a remote change locking you out.

Steps

  1. Record the starting state: ip a, ip r, and nmcli connection show.
  2. Add an address the temporary way: ip addr add 192.0.2.10/24 dev eth0. (eth0 throughout stands for your interface; on RHEL 9 it is more likely enp1s0 or ens3 -- use the name ip a showed in step 1.) Confirm it appears in ip a.
  3. Reboot, and confirm it is gone. State in one sentence why.
  4. Add it persistently through the connection manager instead: nmcli connection modify <name> +ipv4.addresses 192.0.2.10/24, then nmcli connection up <name>. Note that the modify alone changed nothing until the connection was brought up.
  5. Reboot and confirm it survived.
  6. On a Netplan system, make an equivalent change and apply it with netplan try rather than netplan apply. Let the 120-second timer expire without confirming, and watch it revert.
  7. Deliberately set the wrong prefix length -- /16 instead of /24 -- and use ip route get 192.0.3.1 to show that the kernel now believes a remote address is local. Pick the address with care: 192.0.2.1 is on-link under /24 AND /16, so it cannot show the mistake; 192.0.3.1 is on-link only under the wrong /16.

Verify

ip -br a show eth0
nmcli -g ipv4.addresses connection show "$(nmcli -g NAME connection show --active | head -1)"
ip route get 192.0.3.1 | head -1        # "via <gateway>" with /24; "dev eth0 src ..." under the wrong /16
ip route show default

After step 5 the address must appear in both ip a and the connection profile. If it appears only in ip a, the change is temporary and will vanish -- which is exactly the situation people discover after a reboot months later.

Notes

netplan try is the model for every remote network change: apply, wait for confirmation, revert automatically if none arrives. firewall-cmd --timeout does the same job for firewall rules, and both exist because the person making the change is usually connected through the thing they are changing.

This is an independent study companion for CompTIA Linux+ and is not produced by or endorsed by CompTIA.