Linux Networking: Interfaces & Configuration

Intermediate40 min5 steps

What you'll learn

Picture a network conversation as four layers — link, address, route, name — and diagnose by walking them in order
Tell runtime state (ip) from persistent config (NetworkManager/nmcli), and know why the split exists
Read interfaces, addresses, and routes with ip and nmcli
Configure a static IP that survives a reboot, and switch back to DHCP
Set the hostname and control client-side DNS resolution

The four layers of "can't reach the network"
Build the diagnosis ladder every networking task walks
"The network is down" is never one problem — it's four possible problems wearing the same symptom. For a Linux box to talk to the world, four things must be true, in order, and holding this ladder in your head turns vague panic into a checklist:
1. Link — is the interface physically/virtually up? (The cable, the virtual NIC.)
2. Address — does the interface have an IP address and netmask?
3. Route — does the box know where to send traffic that isn't local? (The default gateway.)
4. Name — can it turn example.com into an address? (DNS.)
Each layer depends on everything below it. DNS can't work without a route; a route is useless without an address. So diagnosis always walks bottom-up: link, then address, then route, then name. "I can ping 8.8.8.8 but not google.com" instantly means layers 1–3 are fine and the problem is layer 4 — that one sentence is half of network troubleshooting.
Now the second idea, the one exams test hardest. On a modern RHEL-family system, networking has two sources of truth:
- `ip` — a live dashboard: what addresses and routes are active right now, in the kernel. You can change things with it (ip addr add ...) and they take effect instantly — but they live only in the kernel's memory. Reboot, and they're gone.
- `nmcli` — the CLI of NetworkManager, the service that owns persistent config. It edits saved connection profiles (files under /etc/NetworkManager/system-connections/) that are reapplied at every boot.
One more vocabulary pair and the model is complete: a device (eth0) is the hardware; a connection is a named, saved settings profile attached to a device — and a device can have several profiles ("office", "home") with one active. So the discipline is: observe with `ip`, configure with `nmcli`.
One caveat before you type along: nmcli is the RHEL-family answer. Ubuntu Server — including this lesson's lab box — persists network config with netplan instead (a YAML file under /etc/netplan/) and doesn't ship nmcli at all. The runtime-vs-persistent model is identical; only the configure-side tool changes. The interfaces lesson teaches the netplan side in full — including how the same static-IP task below is written as YAML.
Why the runtime/persistent split bites so hard
The classic incident: an admin fixes connectivity at 2 a.m. with ip addr add, tests it, works, goes to bed. Three weeks later a kernel update reboots the box — and the fix evaporates, because it only ever lived in kernel memory. Nobody remembers the 2 a.m. command. Graded labs simulate exactly this: they reboot before grading, so only nmcli-persisted config earns the points. The same discipline as systemctl start vs enable — runtime and persistent are always separate questions in Linux.
Check yourself
A server can ping 8.8.8.8 but curl https://example.com fails with 'could not resolve host'. Which layer of the ladder is broken?
Read the current state
Inspect interfaces, addresses, routes, and connections — the ladder's bottom three rungs
First task on any box, always: read before you touch. Two ip commands cover the ladder's bottom three rungs — ip addr for link + address, ip route for routing — and learning to read their output precisely is the actual skill.
```
$ ip addr show; ip route show
```
```
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 192.168.1.50/24 brd 192.168.1.255 scope global eth0
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50
```
ip a
shorthand for ip addr show — you'll type this constantly
ip r
shorthand for ip route show
ip -brief addr
one line per interface: name, state, address — the compact survey
Read it as the ladder. Link: UP,LOWER_UP in the angle brackets means the interface is administratively up AND has carrier — both matter. Address: inet 192.168.1.50/24 — the /24 is CIDR notation for the netmask (first 24 bits are the network, so this box's local world is 192.168.1.0–255). Route: the 'default via 192.168.1.1' line is the gateway — where ALL non-local traffic goes. A missing default line is the signature of "I can reach my subnet but nothing beyond it."
That's the runtime. Now the persistent side — what NetworkManager intends the network to look like. Two commands, one for each half of the device/connection vocabulary:
Example — not runnable on your lab box
```
$ nmcli connection show; nmcli device status
```
```
NAME                UUID      TYPE      DEVICE
Wired connection 1  3b2f...   ethernet  eth0

DEVICE  TYPE      STATE      CONNECTION
eth0    ethernet  connected  Wired connection 1
lo      loopback  unmanaged  --
```
connection show lists the saved profiles (the DEVICE column shows where each is active — '--' means saved but inactive); device status flips the view: hardware first, with the profile currently riding it. When runtime (ip) and intent (nmcli) disagree — an address in ip that no profile declares — you've found a temporary hand-edit that will vanish on reboot. To dump one profile's full settings: nmcli con show "Wired connection 1".
Check yourself
ip addr shows 10.0.0.99 on eth0, but nmcli con show for the active profile declares only DHCP. What does the mismatch tell you, and what happens on reboot?
Configure a static IP (that survives reboot)
Set address, gateway, and DNS persistently — then switch to DHCP
Persistent configuration is a two-beat rhythm you'll repeat forever: modify the profile, then bring it up. con mod writes settings to the profile file on disk — and does nothing to the live network. con up (re)applies the profile to the device. Forget the second beat and you're staring at an unchanged network wondering why your command "didn't work" — it did; you just never applied it.
Example — not runnable on your lab box
```
$ sudo nmcli con mod "Wired connection 1" ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 1.1.1.1" ipv4.method manual
sudo nmcli con up "Wired connection 1"
```
```
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
```
ipv4.addresses
the static IP with CIDR mask — 192.168.1.50/24, never a bare IP
ipv4.gateway
default gateway — becomes the 'default via' route
ipv4.dns
DNS servers, space-separated and quoted
ipv4.method
manual = use the statics; auto = DHCP. The master switch.
One con mod sets all four fields: the address WITH its CIDR mask, the gateway (ladder rung 3), the DNS servers (rung 4), and — the make-or-break field — ipv4.method manual. Method is the master switch: set every address correctly but leave method on auto, and NetworkManager ignores your statics and keeps asking DHCP. It's the #1 cause of "my static IP didn't take." Then con up applies it. (Prefer a fresh profile instead of modifying? nmcli con add con-name static-eth0 type ethernet ifname eth0 ip4 192.168.1.50/24 gw4 192.168.1.1.)
Example — not runnable on your lab box
```
$ sudo nmcli con mod "Wired connection 1" ipv4.method auto ipv4.addresses "" ipv4.gateway ""
sudo nmcli con up "Wired connection 1"
```
```
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
```
Back to DHCP: method auto is the switch, and setting the static fields to "" clears the stale values out of the profile (leaving them is harmless today and confusing in six months when someone reads the profile). Same two-beat rhythm — mod, then up.
You're probably SSH'd into the box you're reconfiguring
nmcli con up re-activates the connection — which at minimum blips your SSH session, and with a wrong address or gateway locks you out entirely: the misconfigured network is the only road back in. Working remotely: triple-check values before the con up, know your out-of-band access (console, cloud serial port) exists, and consider nmcli con mod +ipv4.addresses (the + adds a second address instead of replacing) so the old address keeps working while you verify the new one. This is also why the practice step below is read-only.
Check yourself
You set ipv4.addresses and ipv4.gateway correctly, ran con up, but the box still pulls a DHCP address. What did you forget?
Hostname and client-side DNS — the name layer
Name the host and control how names resolve
Top of the ladder: names. Two directions matter — what this box calls itself (its hostname), and how it turns other names into addresses (resolution). Both have a persistent/runtime story, because of course they do.
```
$ sudo hostnamectl set-hostname server01.example.com
hostnamectl status | head -3
```
```
 Static hostname: server01.example.com
       Icon name: computer-vm
         Chassis: vm 🖴
```
hostnamectl set-hostname sets the static hostname persistently — it writes /etc/hostname and applies it live, both halves in one command. (The legacy hostname command only changed it until reboot — the same runtime trap in older clothing.) status shows the three name flavors: static (the persistent one you set), transient (a runtime override, e.g. from DHCP), and pretty (free-form display text).
hostnamectl needs systemd
hostnamectl talks to systemd — on a container or minimal box where PID 1 isn't systemd (your lab box included) it fails with "Failed to connect to bus". The portable pair that works everywhere: read the name with hostname, persist it by writing /etc/hostname. Same runtime/persistent split, done by hand.
```
$ getent hosts db01; cat /etc/resolv.conf
```
```
192.168.1.60    db01
# Generated by NetworkManager
nameserver 8.8.8.8
nameserver 1.1.1.1
```
getent hosts NAME
resolve exactly as the system does — /etc/hosts first, then DNS
dig NAME / dig -x IP
query DNS directly (forward / reverse) — bypasses /etc/hosts
Resolution order: /etc/hosts is consulted BEFORE DNS — a static line there (192.168.1.60 db01) answers instantly, no server needed, and overrides whatever DNS says. Then come the nameservers in /etc/resolv.conf. Read that file's first line carefully: 'Generated by NetworkManager' means hand-edits get OVERWRITTEN on the next network event — change DNS via nmcli con mod ... ipv4.dns, never by editing this file. And note the tool choice: getent hosts follows the system's real resolution order (hosts file, then DNS); dig queries DNS servers directly, skipping /etc/hosts. Different tools answer different questions.
The hand-edited resolv.conf that keeps reverting
A recurring mystery ticket: "I fixed DNS in /etc/resolv.conf, it worked, and an hour later it broke again." NetworkManager regenerated the file — as its header line says it will. The symptom (a fix that silently un-fixes itself) is the fingerprint of editing a generated file. The durable fix is one layer up, in the profile: nmcli con mod NAME ipv4.dns "..." && nmcli con up NAME.
Check yourself
getent hosts app01 returns 10.0.0.5, but dig app01 returns 10.0.0.99. What explains the disagreement?
Now do it — walk the whole ladder, read-only
Diagnose the sandbox's network layer by layer without cutting your own connection
Your terminal reaches this sandbox over the network you'd be reconfiguring — the exact SSH-lockout scenario from the warning above. So this practice is deliberately read-only: walk the full four-layer ladder, bottom to top, saying each verdict out loud. This read-first sweep is genuinely what you'd do in the first two minutes of any real networking task.
```
$ ip -brief link; ip -brief addr
```
Rungs 1 and 2: every interface's link state (UP?) and address in two compact tables. -brief is the survey view you'll reach for first on any unfamiliar box; drop it when you need the full detail.
```
$ ip route show
```
Rung 3: find the 'default via' line and read the gateway address off it. If this table had no default line, you'd already know exactly which symptom to expect — local subnet reachable, everything else dark.
Example — not runnable on your lab box
```
$ cat /etc/netplan/*.yaml 2>/dev/null || echo 'no /etc/netplan here — netplan.io is not installed on this sandbox; on Ubuntu Server (and in the netplan labs) this is where interface config persists'
```
Now the intent side. This box persists with netplan, so its YAML is the saved story — compare it against the ip output from the previous rungs: on a healthy box they agree, and a mismatch is your first clue that someone's been hand-editing runtime state. (On a NetworkManager distro this same rung is nmcli connection show; nmcli device status — the tool changes, the question doesn't.)
```
$ hostname; getent hosts localhost; cat /etc/resolv.conf
```
Rung 4: the box's own name (read with hostname — portable everywhere, unlike hostnamectl, which needs systemd and fails on this box), a resolution test through the real lookup order, and the active nameservers — noting any 'Generated by' header that tells you where DNS changes must really be made. Ladder complete: you've read every layer of this machine's network without touching one bit of it.

Recap

Diagnose bottom-up on the four-layer ladder: link (UP,LOWER_UP) → address (inet + CIDR) → route (default via) → name (DNS). "Pings the IP but not the name" = layer 4, instantly.
ip is the live dashboard (kernel state, gone on reboot); nmcli edits NetworkManager's saved profiles (reapplied at boot). Observe with ip, configure with nmcli — graded labs reboot before grading.
A device is hardware (eth0); a connection is a named saved profile. When ip and nmcli disagree, someone hand-edited runtime state that will evaporate.
Static IP is a two-beat rhythm: con mod (ipv4.addresses/gateway/dns AND ipv4.method manual — the master switch) then con up. DHCP = method auto. mod without up changes nothing live.
Resolution checks /etc/hosts before DNS; resolv.conf is GENERATED (set DNS via nmcli, never by hand-editing); getent hosts follows the real order, dig queries DNS alone.

Task → command
Task	Command
Survey link + addresses	`ip -brief link` · `ip -brief addr`
Show routes / gateway	`ip route` (find `default via`)
List profiles / devices	`nmcli con show` · `nmcli device status`
Set static IP	`nmcli con mod NAME ipv4.addresses IP/CIDR ipv4.gateway GW ipv4.method manual`
Set DNS	`nmcli con mod NAME ipv4.dns "8.8.8.8 1.1.1.1"`
Apply profile change	`nmcli con up NAME` (never forget this beat)
Switch to DHCP	`nmcli con mod NAME ipv4.method auto`
Hostname / test resolution	`hostnamectl set-hostname NAME` · `getent hosts NAME`
Persist on a netplan distro (this lab)	edit `/etc/netplan/*.yaml`, then `netplan apply` — see the interfaces lesson

Linux Networking: Interfaces & Configuration

The four layers of "can't reach the network"

Read the current state

Configure a static IP (that survives reboot)

Hostname and client-side DNS — the name layer

Now do it — walk the whole ladder, read-only