Interfaces and Addressing

A network interface is the kernel's handle on a link — a physical NIC, a VLAN, a bridge, a tunnel, or the loopback. You attach addresses to it, bring it up or down, and the kernel routes packets through it. Addressing is the layer above: an IPv4 or IPv6 address plus a prefix length that tells the kernel which destinations sit directly on the link and which must go through a gateway. On a current Debian or Ubuntu server you manage both through the ip command from the iproute2 suite and a declarative config layer — Netplan on Ubuntu, systemd-networkd or ifupdown underneath.

The operational consequence is that runtime and persistence are two separate worlds, and confusing them costs you. An ip addr add takes effect instantly and survives nothing — one reboot and it is gone. The config files survive reboots but do nothing until a renderer or daemon applies them. Every "the network came back wrong after a reboot" incident lives in that gap.

Interface Naming and Types

Predictable Network Interface Names replaced the old eth0/eth1 scheme on Debian and Ubuntu years ago, because kernel probe order is non-deterministic and eth0 could land on a different card between boots. Names now encode the hardware path: enp3s0 is a PCI Ethernet device on bus 3 slot 0, eno1 is onboard NIC 1, ens5 is a hot-plug slot, and wlp2s0 is wireless. The loopback is always lo at 127.0.0.1/8 and ::1/128. The names stay stable across reboots and hardware reseating, which is exactly what a server needs.

Not every interface is a NIC. The kernel exposes virtual interfaces of several kinds, and a server host usually runs a fistful of them.

Inspecting State with iproute2

The iproute2 suite is the current interface. The deprecated net-tools commands — ifconfig, route, netstat — are not installed by default on a minimal Debian or Ubuntu and show an incomplete picture: ifconfig hides secondary addresses and IPv6 detail that ip addr prints in full. Learn the ip object model and you stop reaching for the old tools.

# list interfaces, addresses, and link state
ip addr show
ip -br addr            # one terse line per interface
ip link show enp3s0    # L2: MAC, MTU, UP/DOWN

# add a runtime address (gone on reboot)
sudo ip addr add 10.0.5.20/24 dev enp3s0
sudo ip link set enp3s0 up

# remove it again
sudo ip addr del 10.0.5.20/24 dev enp3s0

A field worth reading closely is link state versus carrier. ip link can report a link as administratively UP while NO-CARRIER shows in the flags — the interface is enabled but no cable or peer is detected. That distinction tells you instantly whether a dead link is your config or a physical fault upstream.

Addresses, Prefixes, and Scope

An address is meaningless without a prefix length. 10.0.5.20/24 means the first 24 bits are the network, so the host treats 10.0.5.0 through 10.0.5.255 as directly reachable on the link and sends everything else to a gateway. Get the prefix wrong — a /16 where the LAN is really a /24 — and the host tries to ARP for addresses that live behind a router, so they silently time out instead of routing. CIDR is not optional knowledge here; it is the difference between a host that talks and one that half-talks.

IPv6 changes the shape of the problem. An interface normally holds several addresses at once: a link-local fe80::/10 address the kernel auto-generates and uses for neighbor discovery, plus one or more global addresses from SLAAC or DHCPv6. There is no ARP — Neighbor Discovery over ICMPv6 replaces it — and the link-local address must stay reachable for the link to function, so never blanket-filter fe80::/10 in a host firewall. Dual-stack servers run both protocols side by side, and a service bound only to IPv4 is invisible to IPv6 clients.

# every address on every interface, with scope
ip -6 addr show
# scope global vs scope link tells you which is routable

Persistent Configuration with Netplan

On Ubuntu the persistence layer is Netplan: YAML files in /etc/netplan/ that a renderer compiles into the active backend — systemd-networkd on servers, NetworkManager on desktops. You write intent, not commands. netplan generate renders the backend config and netplan apply brings it live without a reboot. Debian without Netplan uses either /etc/network/interfaces (ifupdown) or systemd-networkd unit files directly; the YAML below is the Ubuntu default. On Red Hat the equivalent role belongs to NetworkManager keyfiles managed with nmcli.

# /etc/netplan/01-netcfg.yaml  (mode 0600 — it can hold secrets)
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      addresses: [10.0.5.20/24, "2001:db8:5::20/64"]
      routes:
        - to: default
          via: 10.0.5.1
      nameservers:
        addresses: [10.0.5.1, 1.1.1.1]

Two Netplan habits make a config change survivable. First, netplan try applies the new config and automatically rolls back after 120 seconds unless you confirm — so a mistake that kills your SSH session repairs itself instead of stranding the box. Second, before you make a risky change on a remote host with no console, queue a delayed safety net: sudo sh -c 'sleep 300 && netplan apply' from the last known-good file, so a lockout self-heals in five minutes.