Configuring networking

Before you read. Somebody sets a static address on a server. They test it, everything works, they close the ticket. The machine reboots six weeks later during patching and comes back with a completely different address, or none.

Nothing was deleted. The change was made correctly and it worked.

Where did it go?

It was never written anywhere. ip addr add changes what the kernel is doing right now and touches no file, so the next boot starts from whatever the configuration says, which is what it said before anyone touched it.

That distinction between the running state and the configuration runs through this entire lesson. Getting it wrong is the single most common networking mistake in this exam’s scope, and it produces a failure delayed by weeks.

Some words you will need

running state

What the kernel is doing now. Changed with ip. Gone at reboot.

configuration

What a file says should happen. Applied at boot by whichever system is in charge.

connection profile

NetworkManager's unit of configuration: a named set of settings that can be applied to a device.

DHCP

Ask a server on the network for an address, mask, gateway, and DNS. The default nearly everywhere.

DHCP reservation

The DHCP server always giving one machine the same address, based on its MAC.

What breaks without this

Changes that vanish. Described above, and the delay between making the change and discovering it did not persist is what makes it expensive.

You edit a file nothing reads. Three systems can own networking, and each ignores the others’ files. Editing the wrong one produces no error and no effect.

You lock yourself out. Changing the address of the interface you are connected over drops your session, and if the change was wrong you have no way back except console access.

udevadm info /sys/class/net/enp0s1 | grep ID_NET_NAME
udevadm test-builtin net_id /sys/class/net/enp0s1 2>/dev/null

# /etc/systemd/network/10-wan.link
[Match]
MACAddress=5a:94:ef:e4:0c:ee

[Link]
Name=wan0

Which system is in charge

This is the first question on any unfamiliar machine, and it decides everything else.

Find out in one command:

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ command -v nmcli netplan resolvectl dig host nslookup ss; echo "--- NetworkManager? ---"; systemctl is-active NetworkManager systemd-networkd systemd-resolved 2>&1
/usr/bin/nmcli
/usr/bin/resolvectl
/usr/bin/dig
/usr/bin/host
/usr/bin/nslookup
/usr/bin/ss
--- NetworkManager? ---
active
inactive
inactive

nmcli exists, netplan does not, and systemctl is-active says NetworkManager is running while systemd-networkd is not. So NetworkManager owns this machine and its files are the ones that matter.

Run that check before editing anything. Two seconds, and it prevents the entire category of “I edited a file and nothing happened”.

netplan is a special case worth understanding: it is not a network system at all. It is a translator that reads YAML and generates configuration for either NetworkManager or systemd-networkd, which then does the work. So on Ubuntu server you edit netplan’s YAML and systemd-networkd is what actually applies it. That is why systemctl status systemd-networkd on Ubuntu shows something running that you never configured directly.

Temporary changes, and why they do not last

An interface is created and given an address. No route is added, the command list contains no ip route add.

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ sudo ip link add demo0 type dummy; sudo ip addr add 10.99.0.5/24 dev demo0; sudo ip link set demo0 up; ip addr show demo0; echo "--- and the route it created ---"; ip route | grep 10.99; sudo ip link del demo0
65: demo0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether ce:ef:97:9b:b3:be brd ff:ff:ff:ff:ff:ff
    inet 10.99.0.5/24 scope global demo0
       valid_lft forever preferred_lft forever
    inet6 fe80::ccef:97ff:fe9b:b3be/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
--- and the route it created ---
10.99.0.0/24 dev demo0 proto kernel scope link src 10.99.0.5 

A whole interface created, addressed, and brought up, on a dummy device, so nothing real was disturbed. Note the route appeared automatically the moment the address was assigned: proto kernel again, exactly as in the last lesson.

Every one of these is forgotten at reboot. No file was written. That is not a flaw: it makes them ideal for testing a theory before committing to it, which is exactly how the previous lesson’s worked example ended.

The workflow worth adopting: prove it with ip, then write it down with the machine’s own configuration system.

NetworkManager: nmcli

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ nmcli device status; echo; nmcli connection show
DEVICE  TYPE      STATE                   CONNECTION         
enp0s1  ethernet  connected               Wired connection 1 
lo      loopback  connected (externally)  lo                 

NAME                UUID                                  TYPE      DEVICE 
Wired connection 1  21725c5d-26b2-3063-92eb-636dec679a5e  ethernet  enp0s1 
lo                  c29d0687-8931-44b5-81d5-cada3828b494  loopback  lo     

Devices and connections are different things, and the distinction is the one piece of NetworkManager vocabulary that matters.

A device is the hardware: enp0s1. A connection is a named profile of settings: Wired connection 1. A device can have several profiles defined and one active, which is how a laptop switches between office and home settings on the same card.

nmcli device status answers “what hardware is there and is it connected”. nmcli connection show answers “what profiles exist”.

Look inside a profile:

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns connection show "Wired connection 1" 2>/dev/null || nmcli connection show --active | tail -2
ipv4.method:                            auto
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.dns:                               --

ipv4.method: auto means DHCP, and the other three are empty because the DHCP server supplies them. manual would mean static, and then those fields would be populated.

Switching this profile to a static address is four settings and an apply:

sudo nmcli connection modify "Wired connection 1" \
  ipv4.method manual \
  ipv4.addresses 192.168.1.50/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "1.1.1.1 9.9.9.9"

sudo nmcli connection up "Wired connection 1"

ipv4.method manual is the setting people forget. Set the address without it and NetworkManager keeps asking DHCP as well, so you end up with two addresses and behaviour that depends on which the routing table prefers.

connection up is what applies it. modify writes the profile and changes nothing that is running. Without the second command it works after a reboot and not before, which is the reverse of the usual mistake and equally confusing.

Useful ones to have:

nmtui is worth knowing about for the exam and for a bad day. It is a text-mode interface that walks you through the same settings, and it is far harder to get subtly wrong at 2am than a long nmcli modify.

[connection]
id=static-mgmt
type=ethernet
interface-name=enp0s1
autoconnect=true
autoconnect-priority=100

[ipv4]
method=manual
address1=192.168.1.50/24,192.168.1.1
dns=1.1.1.1;9.9.9.9;

netplan: Ubuntu server

netplan is YAML in /etc/netplan/, and YAML means indentation is syntax:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s1:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 9.9.9.9]

Then:

sudo netplan try      # applies it, and rolls back after 120s unless confirmed
sudo netplan apply    # applies it permanently

netplan try is the best safety feature in any of these systems. It applies the configuration and, unless you press Enter to confirm, reverts after two minutes. Which means a mistake that would have locked you out of a remote machine undoes itself while you are still watching. Use it every time.

Two details that catch people:

• gateway4: is deprecated in favour of the routes: block shown above. Older documentation uses it, newer netplan warns about it, and eventually it goes.
• Files are applied in lexical order and later ones override earlier. A cloud image ships 50-cloud-init.yaml, so a file named 99-mine.yaml wins and one named 10-mine.yaml does not.

The Ubuntu container image used for these captures has no netplan in it at all:

# Ubuntu 24.04 LTS, x86_64
$ command -v netplan; ls /etc/netplan/ 2>&1; cat /etc/os-release | head -2
ls: cannot access '/etc/netplan/': No such file or directory
PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"

Which is worth showing rather than hiding: container images are not servers. A container gets its network from the container runtime, so nothing that configures networking is installed. The netplan examples above come from Canonical’s documentation rather than from a capture, and the reference is in the sources.

Debian: /etc/network/interfaces

Debian without netplan uses the older ifupdown system:

auto enp0s1
iface enp0s1 inet static
    address 192.168.1.50/24
    gateway 192.168.1.1
    dns-nameservers 1.1.1.1 9.9.9.9

auto means bring it up at boot. inet static means IPv4, statically configured; inet dhcp is the alternative and needs none of the other lines.

sudo ifdown enp0s1 && sudo ifup enp0s1

Never run ifdown on the interface you are connected over unless you have console access. The && will not save you: ifdown succeeds, your session dies, and ifup never runs. Use systemctl restart networking, or better, test the change with ip first.

DHCP or static

DHCP reservations are the answer most people should reach for. The client uses DHCP, and the DHCP server is told to always give that MAC address the same IP. You get a predictable address and central control, so a network renumbering is one change in one place instead of a visit to forty machines.

Static configuration on the host is right when the machine must work even when the DHCP server does not, which includes, notably, the DHCP server.

Across distributions

RHEL 9 and later dropped /etc/sysconfig/network-scripts/ as the source of truth. Those ifcfg- files are still read for compatibility on some releases and are not where NetworkManager writes any more, so editing one and finding it ignored is a real and current confusion. nmcli is the answer on that family.

Prove it

After any change, in this order:

# Is it live now
ip -brief addr
ip route | grep default

# Does the configuration agree with reality
nmcli connection show "name" | grep ipv4        # RHEL family
sudo netplan get                                 # Ubuntu
cat /etc/network/interfaces                      # Debian

# Does it still work end to end
ping -c 2 <gateway>
ping -c 2 1.1.1.1

And the only test that really counts: reboot the machine. Everything above can pass on a machine whose configuration is wrong, because you are looking at the running state. If a reboot is genuinely impossible, systemctl restart NetworkManager (or networking) is the nearest approximation and it is not the same thing.

What trips people up

1. The change was lost at reboot

ip addr add and ip route add modify the running kernel and write nothing.

Use them to test, then commit the change with nmcli, netplan, or /etc/network/interfaces. The whole lesson, really.

2. You edited the wrong file

Three systems, three sets of files, and each ignores the others’. Editing /etc/network/interfaces on a RHEL machine does nothing at all, and there is no error to tell you.

systemctl is-active NetworkManager systemd-networkd first, every time.

3. Setting an address without setting the method

nmcli connection modify ... ipv4.addresses 192.168.1.50/24 without ipv4.method manual leaves the profile on DHCP. You get the static address and a DHCP one, and which is used depends on route metrics.

Set the method. nmcli connection show "name" | grep ipv4.method confirms it.

4. Locking yourself out

Covered in the prediction. Test with ip first, use netplan try where you have it, and arrange a scheduled rollback for anything remote and risky.

5. Two systems both managing one interface

NetworkManager and systemd-networkd both running and both interested in the same device produces flapping: an address that appears, disappears, and changes.

Pick one. nmcli device set enp0s1 managed no hands the interface over, or disable the service you are not using.

Work it through

A monitoring server has a static address configured through NetworkManager. It was patched and rebooted overnight. This morning it is reachable, but at a different address, and half the systems that report to it have stopped.

nmcli connection show lists two profiles for the same device: Wired connection 1 and monitoring-static.

Reason it out before reading on.

Two profiles, one device. That is legal and it is the whole story. A device can have many profiles defined; exactly one is active at a time.

Which one is active? nmcli device status shows the CONNECTION column, the profile currently applied. If it says Wired connection 1, the machine came up on the auto-generated DHCP profile and the static one was never activated.

Why would the wrong one win? NetworkManager activates a profile at boot based on connection.autoconnect and, when several are eligible, connection.autoconnect-priority. The default profile is created automatically with autoconnect on. If monitoring-static was created and brought up manually but never had autoconnect set, it works until the next boot and then loses to the one that does.

Confirm it:

nmcli -f connection.autoconnect,connection.autoconnect-priority connection show monitoring-static
nmcli -f connection.autoconnect,connection.autoconnect-priority connection show "Wired connection 1"

An autoconnect: no on the static profile is the finding.

The fix:

sudo nmcli connection modify monitoring-static connection.autoconnect yes
sudo nmcli connection modify monitoring-static connection.autoconnect-priority 100
sudo nmcli connection delete "Wired connection 1"
sudo nmcli connection up monitoring-static

Deleting the competing profile is the part worth doing. Leaving two profiles that could both claim the device is leaving the same problem in place with a different priority number in front of it.

Why did it work for weeks? Because nmcli connection up had been run by hand, and nothing since had restarted networking. The configuration and the running state disagreed for the entire time, and only a reboot could reveal it.

The habit worth taking: after any network change intended to be permanent, reboot the machine while you are still there. Not restart the service, reboot. It is the only test that exercises what actually happens at boot, and the alternative is finding out during a patch window when you are asleep.

Try it

Optional, on a virtual machine you can reach by console if you break it. Do not practise this over SSH on anything you care about.

1. systemctl is-active NetworkManager systemd-networkd and ls /etc/netplan. Say which system owns the machine.
2. nmcli device status and nmcli connection show, and name the difference between the two lists.
3. sudo ip link add demo0 type dummy, give it an address, check ip route, then sudo ip link del demo0. Nothing real was touched.
4. nmcli connection show "<your connection>" | grep ipv4 and read the method.
5. On Ubuntu: sudo netplan get, then sudo netplan try with no changes, and watch the countdown.
6. Change something harmless, reboot, and confirm it survived.

Verification step. You have it when you can set a static address on an unfamiliar machine, using the right tool for that machine, and be confident it will still be there next month.

Check yourself

References

• nmcli(1) - Debian Project. Accessed 2026-08-07.
• ip-link(8) - Linux man-pages project. Accessed 2026-08-07.
• Netplan YAML configuration reference - Canonical. Accessed 2026-08-07.
• interfaces(5) - Debian Project. Accessed 2026-08-07.
• systemd.network(5) - Linux man-pages project. Accessed 2026-08-07.
• systemd.link(5) - Linux man-pages project. Accessed 2026-08-07.

Command output was captured on the podman machine and on the pinned container images. The netplan configuration is from Canonical’s reference, because a container has no network configuration system in it to capture from. Blocks without a distribution and architecture header are illustrative.