Configure One Linux Interface with systemd-networkd

One misconfigured .network file is enough to knock an interface offline. This guide sets up systemd-networkd carefully, then verifies the address, route and file that actually won, following the systemd 255 manpages installed on the host, package version 255.4-1ubuntu8.17.

Allow 15 to 20 minutes, plus time to recover if you are connected over the interface being changed. You need a shell and root access for the configuration steps; the inspection commands are normally unprivileged. Keep an existing console, out-of-band console or second connection available before changing a remote machine's only network path.

1. Identify the interface and service

Start by recording the interface name. Do not copy the example name below into a file unless it really is the name you intend to manage:

$ networkctl --no-pager list
  IDX LINK        TYPE     OPERATIONAL SETUP
    2 enp0s31f6   ether    routable    configured

$ systemctl is-active systemd-networkd.service
active
$ systemctl is-enabled systemd-networkd.service
enabled

Your output will differ. Use the value in the LINK column as IFACE. If the interface is already managed by NetworkManager, netplan or another tool, stop here and settle ownership first: two network managers editing the same device produces confusing, and sometimes intermittent, results.

Checkpoint: run networkctl status IFACE and note the current Network File, address and gateway. Replace IFACE with the actual name; angle brackets are explanatory placeholders, not shell syntax.

2. Create a narrowly matching network file

Network files are read from /usr/lib/systemd/network, /usr/local/lib/systemd/network, /run/systemd/network and /etc/systemd/network. They are sorted together in alphanumeric order, and the first matching file wins, so a local file with a number below 70 is a practical starting point. Use sudoedit, which gives you a chance to check the file before saving:

$ sudoedit /etc/systemd/network/10-IFACE.network

Replace IFACE in both the filename and the Name= value. This example requests DHCP on one Ethernet interface:

[Match]
Name=IFACE

[Network]
DHCP=yes
IPv6AcceptRA=yes

DHCP=yes enables DHCPv4 and DHCPv6, and IPv6AcceptRA=yes accepts IPv6 Router Advertisements. If your network needs a fixed address instead, use a different [Network] section:

[Match]
Name=IFACE

[Network]
Address=192.0.2.20/24
Gateway=192.0.2.1
DNS=192.0.2.1

Those addresses are documentation values. Do not apply them to a real network without swapping in whatever was actually assigned to your host. A static address or gateway can cut off the current connection, so treat that change as service-disrupting.

Do not leave a broad file such as Name=* in place while testing a single interface. A file with no valid match settings matches every interface, and networkd will warn you about it. A specific name keeps the blast radius visible.

3. Check which file will win

Before reloading, ask networkctl to show the files and the effective configuration. Neither command changes network state:

$ networkctl --no-pager cat 10-IFACE.network
[Match]
Name=IFACE

[Network]
DHCP=yes
IPv6AcceptRA=yes

$ networkctl --no-pager status IFACE

The first command shows the file content if networkctl can resolve that name, and the status output should show your selected Network File once loaded. If an earlier file matches first, rename your file to a lower sort number or narrow the other file's match. Do not assume a file in /etc always wins: directory priority only resolves identical filenames, all distinct names still share the same alphanumeric ordering.

Checkpoint: confirm the interface name, the file's match, and the intended address method. Fix the file before reloading if any one of them is wrong.

4. Reload and verify the result

Reload the networkd configuration as root:

$ sudo networkctl reload

Reload reads the .network and .netdev files, but it does not by itself guarantee an already-configured interface gets reconfigured. To apply the selected file to one interface, use the more disruptive command below, and only once you have a recovery path ready:

$ sudo networkctl reconfigure IFACE
$ networkctl --no-pager status IFACE

Look for the expected Network File, State, Address, Gateway and DNS lines. A healthy DHCP example normally reports a configured or routable state, though the exact state depends on carrier, DHCP service and routing. Check routing separately:

$ ip address show dev IFACE
$ ip route show dev IFACE
$ resolvectl status IFACE

If the connection drops, use the console you kept open and restore the previous file from your editor, or just move the new file out of the way. Then reload and reconfigure again:

$ sudo mv /etc/systemd/network/10-IFACE.network /etc/systemd/network/10-IFACE.network.disabled
$ sudo networkctl reload
$ sudo networkctl reconfigure IFACE

That rename is reversible. Do not delete a working vendor or generated file while you diagnose a failure.

5. Understand global settings and virtual devices

Most interface work belongs in .network files. A .netdev file creates a virtual device such as a bridge, VLAN, bond or tunnel, with a separate .network file then configuring that device. This example creates a bridge; it does not attach a physical port or assign an address on its own:

[NetDev]
Name=bridge0
Kind=bridge

Save it as /etc/systemd/network/20-bridge0.netdev, then match bridge0 in a separate .network file. Creating or changing a bridge, bond or tunnel can interrupt traffic and may move where an address needs to live, so test those changes during a maintenance window.

Global networkd settings use /etc/systemd/networkd.conf and its drop-ins, not /etc/systemd/network/*.network. The installed manpage documents settings such as foreign route management and DHCP DUID selection. Local drop-ins under /etc/systemd/networkd.conf.d/ take precedence over vendor drop-ins, and later filenames win for single-valued options. Reach for a numbered drop-in only when you need a global policy, a deliberate DUID choice for example, never to solve a per-interface matching problem.

6. Diagnose the usual failure modes

Done means