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

Record the starting state: ip a, ip r, and nmcli connection show.
Add an address the temporary way: ip addr add 192.0.2.10/24 dev eth0. Confirm it appears in ip a.
Reboot, and confirm it is gone. State in one sentence why.
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.
Reboot and confirm it survived.
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.
Deliberately set the wrong prefix length -- /16 instead of /24 -- and use ip route get to show that the kernel now believes a remote address is local.

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.2.1 | head -1        # via gateway, or "dev eth0 src ..." if local
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.