Network Interfaces

A Linux network interface connects a network namespace to a physical device, loopback path, bridge, tunnel, virtual device, or other link. Interface state, addresses, routes, DNS, and persistent configuration are related but distinct.

Discovering Interfaces

Use the modern iproute2 tools:

$ ip -brief link show
$ ip -brief address show

Interface names can be predictable hardware-derived names such as enp1s0, traditional names such as eth0, or administrator-defined names. Never assume eth0 exists or identifies a particular adapter.

CheckWhy should a script discover rather than assume eth0?

Every interface is required to be named lo. Linux systems can use several interface naming schemes. Interface names are always remote passwords.

Administrative and Operational State

UP means the interface is administratively enabled. LOWER_UP commonly indicates that the lower layer reports operational readiness, such as Ethernet carrier. Either flag alone does not prove an IP address, route, DNS, firewall, or application path works.

$ ip -details link show dev enp1s0
$ ip -s link show dev enp1s0

The statistics view can reveal errors, drops, and counters, but counters need a time interval and baseline to become meaningful.

CheckWhat does administrative UP fail to prove?

That end-to-end connectivity works. That the administrator enabled the interface. That the interface has a kernel object.

Changing Runtime State

Runtime commands include:

$ sudo ip link set dev enp1s0 up
$ sudo ip address add 192.0.2.10/24 dev enp1s0

These changes affect current kernel state and can conflict with a network manager that later reapplies its profile. Bringing down a remote-management interface can immediately end access. Before changing it, verify the exact device, preserve console access, record current state, and prepare a timed or tested rollback.

CheckDoes ip address add by itself guarantee persistence after reboot?

No; the active configuration system must also store the setting. Yes, because every kernel change edits all manager profiles. Only when the address is private IPv4.

Identifying Configuration Ownership

Persistent paths differ across distributions and installations. Possibilities include NetworkManager profiles, systemd-networkd units, netplan input, /etc/network/interfaces, cloud-init, or orchestration. Determine which service manages the device before editing files:

$ systemctl --type=service --state=running | grep -E 'NetworkManager|networkd|networking'
$ networkctl status
$ nmcli device status

Use only commands present for the identified manager. Two managers controlling the same link can race and overwrite each other's state.

CheckWhat should precede a persistent interface change?

Edit every possible network configuration file. Identify which network manager owns the interface. Delete all current routes before inspection.

Verifying a Change

Verify link state, assigned addresses and lifetimes, selected routes, resolver state, neighbor reachability, and the actual application. For a persistent change, test a controlled service restart or reboot only when a recovery path exists.

CheckWhat provides better evidence than seeing the new address in ip address?

The interface name contains a digit. The shell prompt still has the same color. Routes, resolver state, and the intended application also work.

Summary

You can now inspect and change an interface without confusing runtime state with persistent policy.

1. Discover real interface names and addresses.
2. Separate administrative state from operational connectivity.
3. Treat direct ip changes as current kernel state.
4. Identify the active configuration owner before persistence changes.
5. Verify routing, resolution, and application behavior afterward.