You run `ip addr add 10.0.0.50/24 dev enp3s0` on a Linux server; the address works immediately, but it is gone after a reboot — and sometimes it disappears minutes later without one. What is happening, and where does the address actually belong?
answer
- the command edits memory, not a file
- something else has an opinion
- convergence on lease renewal or carrier
- find who owns the interface first
- one front end, two possible backends
basics
~20 sip only edits live kernel state, which is never written to disk, so a reboot discards it. Persistence belongs to whichever manager owns the interface — NetworkManager, systemd-networkd, or netplan rendering to one of them — and that manager can also overwrite your address while running.
solid answer
~50 s`ip addr add` talks to the kernel over rtnetlink and changes nothing but live state; there is no file behind it, so the address dies with the running kernel. The second symptom is the more interesting one: a userspace network manager owns that interface and periodically reasserts its own view of what should be configured. When NetworkManager reactivates a connection, a DHCP lease is renewed, or the carrier flaps, the manager reapplies its configured address set — and an address it does not know about is removed. So the correct place for the address is that manager's configuration: a NetworkManager connection profile, a systemd-networkd `.network` file, or a netplan YAML that renders to whichever of the two the distribution uses. Find out which one is actually running before editing anything, because writing a config for the manager that is not in charge changes nothing at all.
code
yaml · 11 linesnetwork:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: false
addresses:
- 10.0.0.50/24
routes:
- to: default
via: 10.0.0.1go deeper
Know that ip only changes the running kernel and nothing on disk, so any address you add that way is gone after a reboot. Say where persistent configuration lives on the distribution you use.
Explain that a network manager holds a desired address set and reapplies it on activation, lease renewal or carrier events, which is why a hand-added address can vanish mid-run. Name the three arrangements and which files each reads.
Demonstrate the discipline of identifying the owning manager before editing anything, verifying persistence across an actual reboot, and refusing to mix hand-applied and managed configuration on the same interface.
Own the fleet-level rule: network configuration is declarative and comes from one source of truth per host class, with imperative ip commands reserved for time-boxed diagnosis so that no machine's live state disagrees with what the repository says it should be.
## Two different disappearances The question bundles two failures that have different causes, and a good answer separates them. **Gone after a reboot.** `ip` is a thin client for the kernel's rtnetlink interface. `ip addr add` inserts an address into the kernel's in-memory list for that device and nothing else. No file is written, no service is notified to remember it. A reboot starts a fresh kernel with an empty list. This is the same reason `ip link set ... mtu`, `ip route add` and `sysctl -w` all evaporate: they are runtime operations by design. **Gone while the machine is still running.** This one surprises people. Something in userspace is *managing* that interface, and management means convergence: the manager holds a desired configuration and reapplies it on events. Those events include connection activation and reactivation, a DHCP lease renewal or rebind, a carrier down/up transition, and an explicit reload. When it reapplies, it sets the interface to exactly the address set it knows about, and yours — which appears in no profile — is removed. From the outside it looks random; it is actually deterministic, triggered by whatever event you did not see. ## Who owns the interface On current Linux distributions you will meet three arrangements, and the first job is identifying which is in play, because writing configuration for an inactive manager is a very common wasted afternoon. **NetworkManager** is the default on Red Hat–family systems and on desktop-oriented installations. Its unit of configuration is a *connection profile*, stored as keyfiles under `/etc/NetworkManager/system-connections/`, and normally edited through `nmcli` rather than by hand. A static address means setting the connection's IPv4 method to manual and giving it the address and prefix; leaving the method as automatic means DHCP. Profiles are activated against a device, and it is the activation that pushes addresses into the kernel. **systemd-networkd** is common on servers and minimal images. It reads `.network` files from `/etc/systemd/network/`, each with a `[Match]` section selecting the interface and an `[Network]` or `[Address]` section describing the configuration. It is declarative and file-driven with no CLI state of its own. **netplan** is not a third manager but a front end. On Ubuntu you write YAML under `/etc/netplan/`, declare a `renderer` of either `networkd` or `NetworkManager`, and `netplan` generates that backend's configuration files and asks it to apply them. Editing the generated backend files directly is a trap: the next netplan run overwrites them. There is also the case of *no* manager — an interface nothing owns. Then only the reboot symptom appears, since nothing is around to reassert anything. ## Doing it properly Establish which manager is running and active for that device. Put the address into that manager's configuration, along with everything else the interface needs, then apply — a connection reactivation for NetworkManager, a reload plus reconfigure for systemd-networkd, `netplan apply` for netplan. Verify by re-reading the live state, and ideally verify across a reboot, because a config that applies cleanly on demand can still fail to be selected at boot if its match is wrong. A related trap worth naming: mixing static and dynamic on one interface. Adding a static address by hand to an interface that is also running DHCP creates two authorities for the same device, and the DHCP client's next renewal is entitled to prune what it did not install. If an interface must carry both a lease and a fixed address, express that in the manager's configuration so it is the manager's own intent, not a bolt-on. ## Where `ip addr add` is still the right tool It is perfect for what it is: a temporary, reversible probe. Testing whether an address conflicts, standing up an address for a five-minute migration cutover, adding a service address inside a throwaway namespace or test topology. The failure is not using it; the failure is using it and then walking away as if you had configured something. One more detail that shows depth: modern Linux allows many addresses on one interface, and `ip addr` lists them all rather than inventing sub-interfaces. The old `eth0:0` "alias" notation was a compatibility fiction for tools that assumed one address per device; secondary addresses today are simply additional entries on the same interface, and configuration managers model them the same way — as a list. ## The one-sentence answer `ip` changes the kernel; configuration lives in userspace, and on a managed host the manager will win every argument you have with it.
- How would you work out which manager owns an interface on a server you have just been handed?Check which of the candidates is actually running and enabled — NetworkManager, systemd-networkd — rather than which is merely installed, and look for configuration that matches the device: a connection profile keyfile, a `.network` file whose match selects it, or netplan YAML in `/etc/netplan/`. If netplan is present, note its `renderer`, because that tells you which backend the generated files land in. Only then edit anything.
- Is there any legitimate use for `ip addr add` on a production host?Yes, as a deliberately temporary operation. Testing whether an address is already in use, floating a service address during a short cutover, or building a test topology in a throwaway namespace are all reasonable — the value is precisely that it leaves no trace. The rule is that it must be time-boxed and either reverted or promoted into the manager's configuration before you walk away, since a live state that no file describes is invisible to the next person.
- How does Linux handle multiple addresses on one interface, and what happened to the old `eth0:0` notation?Modern Linux simply keeps a list of addresses per device, and `ip addr` shows all of them on the one interface. The `eth0:0` alias form was a compatibility fiction for older tools that assumed a single address per device; it never created a separate interface. Configuration managers model this the same way — an address list on one connection — so secondary addresses are declared alongside the primary rather than on an invented alias device.
saying these in an interview costs you the question
- Believes ip addr add writes configuration somewhere on disk
- Edits netplan-generated backend files directly
- Writes a systemd-networkd file on a NetworkManager-managed host
- Blames a flapping bug when a manager reasserted its own config
- Adds a static address by hand to an interface also running DHCP