Debian 13: Network doesn’t come up after reboot — a no-fluff systemd-networkd checklist

The mental model: what “network is up” actually means

People say “the network is down” like it’s one thing. On a Debian 13 box using systemd-networkd, “network is up” is a chain of separate conditions:

• Hardware link: the NIC sees carrier, autoneg is done, the driver is happy.
• Interface exists and is named: your config matches the actual interface name after udev predictable naming.
• Addressing: DHCP succeeds (or static addresses apply) and the address is actually bound to the interface.
• Routing: you have a default route (or relevant policy routes) and the kernel picks what you expect.
• DNS: resolv.conf points somewhere real, or systemd-resolved is configured correctly, or you provided explicit nameservers.
• Firewall: local firewall isn’t quietly eating DHCP replies, ARP, or your own SSH.
• Dependencies: services that start “after network” aren’t accidentally gating network itself (yes, this happens).

systemd-networkd only owns parts of this. It configures links, addresses, and routes, and can push DNS settings into systemd-resolved. It does not negotiate with your switch. It also won’t fix your kernel module deciding to be temperamental after a firmware update.

So the rule is simple: don’t “restart networking” and hope. Pin down which link in the chain is broken. Fix that, then confirm the next link.

Fast diagnosis playbook (first/second/third)

First: is it a naming/config mismatch or a service conflict?

Fastest failures are boring: the interface name changed, or two network stacks are fighting. Confirm the interface name and who owns it.

• Check actual NIC names and state (ip link).
• Check whether systemd-networkd is enabled and running.
• Check for NetworkManager, ifupdown leftovers, or a container bridge config stepping on things.
• Check /etc/systemd/network/*.network matches the correct interface (by name or MAC).

Second: is the link up and is DHCP/static addressing applying?

If the NIC has no carrier or DHCP never completes, you’ll waste hours chasing routes and DNS.

• Confirm carrier and negotiated speed/duplex (ethtool).
• Check networkctl status for “configured” vs “configuring” vs “failed”.
• Read the systemd-networkd journal for explicit DHCP errors and timeouts.

Third: routing and DNS, in that order

Routing is the difference between “I can ping my gateway” and “I can reach anything.” DNS is the difference between “I can reach 1.1.1.1” and “I can reach anything by name.” Don’t invert those.

• Verify default route and selected source IP (ip route, ip route get).
• Verify resolver path (resolvectl status and the actual /etc/resolv.conf symlink).
• Only then test outbound and name resolution.

Operational advice: When you’re on the console at 3 a.m., you want a single narrative: “Link good → address present → route present → DNS correct.” Anything else is vibes.

Interesting facts and historical context (you’ll stop making the same mistakes)

1. Predictable interface names weren’t always default. Older Linux systems used eth0/eth1; modern udev-based naming tries to be stable across reorders, but firmware/PCI topology changes can still rename interfaces.
2. Debian historically used ifupdown. For years, /etc/network/interfaces drove networking. Many “mystery” breakages are just leftover config assumptions from that era.
3. systemd-networkd is intentionally minimal. It’s designed for servers and containers: fewer moving parts, more declarative config, less desktop magic.
4. systemd-resolved changed what “DNS config” means. A lot of people still edit /etc/resolv.conf directly, then wonder why it gets overwritten or points to a stub resolver.
5. DHCP is not just “get an IP.” Leases include routes, MTU, DNS, NTP, and can be affected by client identifiers and DUIDs—details that surface after reboots or reinstalls.
6. wait-online is a policy decision, not a requirement. systemd-networkd-wait-online can prevent services from starting before the network is usable, but it can also block the boot if you misuse it.
7. Netplan popularized declarative network config elsewhere. Debian doesn’t require it; some admins copy/paste mental models from other distros and end up configuring nothing.
8. Carrier doesn’t guarantee connectivity. A link can be “up” while VLAN tagging is wrong, the switchport is in the wrong VLAN, or your bonding mode doesn’t match the switch configuration.

Practical tasks: commands, expected outputs, and decisions

These are real tasks you can run on a Debian 13 system. For each one: command, what you’re looking for, and what decision you make next.

Task 1 — Confirm which services are actually running

cr0x@server:~$ systemctl status systemd-networkd --no-pager
● systemd-networkd.service - Network Configuration
     Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-12-28 01:07:14 UTC; 2min 11s ago
       Docs: man:systemd-networkd.service(8)

Meaning: If it’s not “active (running)”, stop guessing. If it’s disabled, your boot won’t configure anything.

Decision: If inactive/failed, jump to the journal (Task 6) and configuration validation (Task 8). If running, continue.

Task 2 — Check for conflicting network managers

cr0x@server:~$ systemctl is-enabled NetworkManager 2>/dev/null; systemctl is-active NetworkManager 2>/dev/null
enabled
active

Meaning: If NetworkManager is active on a server you intended to be networkd-managed, you’re in “two captains steering one boat” territory.

Decision: Pick one. For servers, I usually disable NetworkManager unless you have a specific reason. If you keep it, stop configuring networkd for the same interfaces.

Task 3 — Identify the interface names that exist right now

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp6s0           DOWN           3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST>
enp7s0           UP             3c:fd:fe:dd:ee:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

Meaning: You now know what names you can match in .network files. Also note which has LOWER_UP (carrier).

Decision: If your config references eth0 but you have enp7s0, that’s your bug. Fix matching (Task 9).

Task 4 — Ask networkd what it thinks is happening

cr0x@server:~$ networkctl status enp7s0 --no-pager
● 2: enp7s0
             Link File: /usr/lib/systemd/network/99-default.link
          Network File: /etc/systemd/network/10-lan.network
                  Type: ether
                 State: routable (configured)
          Online state: online
                Address: 192.0.2.10/24
                         fe80::3efd:feff:fedd:eeff/64
                Gateway: 192.0.2.1
                    DNS: 192.0.2.53

Meaning: “routable (configured)” is what you want. “configuring” means DHCP or link negotiation isn’t done. “failed” means your config didn’t apply or a lower layer failed.

Decision: If not configured, go to DHCP logs and link diagnostics (Tasks 5–7).

Task 5 — Verify physical link and negotiation

cr0x@server:~$ ethtool enp7s0 | sed -n '1,25p'
Settings for enp7s0:
	Supported ports: [ TP ]
	Supported link modes:   1000baseT/Full
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Meaning: If Link detected: no, stop blaming DHCP. You have a cable/switchport/VLAN/driver issue. If speed is 10Mb/s unexpectedly, you might have cabling problems causing intermittent DHCP timeouts.

Decision: Fix L1/L2 first. If link is good, proceed to DHCP/addresses.

Task 6 — Read networkd logs from this boot (the truth, not vibes)

cr0x@server:~$ journalctl -u systemd-networkd -b --no-pager -n 80
Dec 28 01:07:15 server systemd-networkd[412]: enp7s0: DHCPv4 client: started
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired
Dec 28 01:07:18 server systemd-networkd[412]: enp7s0: Gained carrier

Meaning: You’re looking for hard errors: “no carrier”, “DHCPv4 lease lost”, “could not set address”, “link is not managed”.

Decision: If you see “link is not managed”, your matching is wrong (Task 9). If DHCP times out, continue with Tasks 7 and 11.

Task 7 — Verify DHCP client state and lease details

cr0x@server:~$ networkctl status enp7s0 --no-pager | sed -n '1,120p'
● 2: enp7s0
                 State: configuring (configuring)
          Online state: unknown
                Address: fe80::3efd:feff:fedd:eeff/64

Meaning: Only a link-local IPv6 address typically means IPv4 DHCP didn’t succeed and no static IPv4 exists.

Decision: If it’s stuck configuring, capture DHCP traffic (Task 11) and check firewall/bridge/vlan correctness.

Task 8 — Validate your networkd config files exist and are sane

cr0x@server:~$ ls -l /etc/systemd/network
total 8
-rw-r--r-- 1 root root 210 Dec 27 22:10 10-lan.network
-rw-r--r-- 1 root root 120 Dec 27 22:10 10-lan.link

Meaning: If this directory is empty, networkd will do very little unless you rely on default DHCP behavior (which is not a plan; it’s a vibe).

Decision: Open the files and confirm the match criteria and DHCP/static settings (Task 9).

Task 9 — Confirm your match rules actually match the NIC you have

cr0x@server:~$ sed -n '1,120p' /etc/systemd/network/10-lan.network
[Match]
MACAddress=3c:fd:fe:dd:ee:ff

[Network]
DHCP=yes
IPv6AcceptRA=yes

Meaning: Matching by MAC is robust against interface renames. Matching by Name=enp7s0 is fine until a BIOS/PCI change renames it. Pick your poison.

Decision: If your match doesn’t match, networkd ignores the file. Fix the match, then restart networkd (Task 10).

Task 10 — Restart networkd and watch it apply config live

cr0x@server:~$ systemctl restart systemd-networkd
cr0x@server:~$ journalctl -u systemd-networkd -n 30 --no-pager
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: Link UP
Dec 28 01:10:02 server systemd-networkd[615]: enp7s0: DHCPv4 client: started
Dec 28 01:10:05 server systemd-networkd[615]: enp7s0: DHCPv4 address 192.0.2.10/24, gateway 192.0.2.1 acquired

Meaning: If restart fixes it, you likely have a boot ordering race (firmware init delay, driver readiness, or wait-online misuse) rather than a permanent config error.

Decision: If it only fails at boot, address ordering with wait-online policy and driver/firmware stability (see checklist section).

Task 11 — Capture DHCP packets to prove whether replies exist

cr0x@server:~$ timeout 15 tcpdump -ni enp7s0 -vvv 'udp port 67 or udp port 68'
tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 42121, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 3c:fd:fe:dd:ee:ff, length 300, xid 0x6a2c9f10, Flags [none]
IP (tos 0x0, ttl 64, id 1242, offset 0, flags [none], proto UDP (17), length 342)
    192.0.2.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, xid 0x6a2c9f10, yiaddr 192.0.2.10, length 314

Meaning: If you see requests but no replies, the issue is upstream (switch VLAN, DHCP relay, firewall, port security). If you see replies but networkd still doesn’t configure, it’s local (firewall, conflicting manager, or lease parsing).

Decision: No replies: escalate to network team with evidence. Replies present: focus on host configuration and logs.

Task 12 — Check addresses and routes as the kernel sees them

cr0x@server:~$ ip -4 addr show dev enp7s0
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.0.2.10/24 brd 192.0.2.255 scope global dynamic enp7s0
       valid_lft 86368sec preferred_lft 86368sec
cr0x@server:~$ ip route
default via 192.0.2.1 dev enp7s0 proto dhcp src 192.0.2.10 metric 1024
192.0.2.0/24 dev enp7s0 proto kernel scope link src 192.0.2.10

Meaning: No default route means “local LAN only.” A wrong default route means “connectivity roulette.” Metrics matter if you have multiple uplinks.

Decision: If default route is missing, fix DHCP options or set a static gateway in the .network file. If wrong, check multiple DHCP clients or multiple network configs applying.

Task 13 — Confirm DNS resolver path (and stop editing the wrong file)

cr0x@server:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Dec 27 22:10 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
cr0x@server:~$ resolvectl status | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53

Meaning: If resolvectl shows no DNS servers, you have routing but no name resolution. If /etc/resolv.conf points to an old static file while systemd-resolved is enabled, you’re likely debugging the wrong path.

Decision: Decide whether you want resolved or not. If you do, feed it DNS via networkd. If you don’t, disable it and manage /etc/resolv.conf explicitly.

Task 14 — Confirm what “online” means on your system (wait-online)

cr0x@server:~$ systemctl status systemd-networkd-wait-online --no-pager
● systemd-networkd-wait-online.service - Wait for Network to be Configured
     Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2025-12-28 01:07:19 UTC; 3min ago

Meaning: If this service hangs or times out during boot, you may end up with delayed services or a boot that “completes” without usable networking depending on unit dependencies.

Decision: If you don’t need strict gating, disable it. If you do need it, configure it precisely (which interface, which state) and avoid waiting on links that are intentionally absent at boot.

Task 15 — Verify you’re not missing the driver/firmware after updates

cr0x@server:~$ dmesg -T | grep -Ei 'firmware|enp7s0|link up|link down|renamed' | tail -n 30
[Sun Dec 28 01:07:13 2025] r8169 0000:07:00.0 enp7s0: renamed from eth0
[Sun Dec 28 01:07:14 2025] r8169 0000:07:00.0 enp7s0: Link is Up - 1Gbps/Full - flow control off

Meaning: Firmware load failures, driver resets, and renames show up here early. A rename line is your warning that matching by name might be fragile.

Decision: If firmware is missing, install the right firmware package. If the driver flaps link, consider pinning a known-good kernel/firmware combination until you can test.

Task 16 — Check firewall rules that break DHCP or ARP (yes, really)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport 22 accept
	}
}

Meaning: A default-drop input policy with no explicit DHCP allowance can break DHCP (UDP 67/68) depending on how you structure rules and hooks. Also watch for raw table weirdness and bridge filtering.

Decision: If DHCP is blocked, allow it on the relevant interface during boot, or run static addressing. Keep it explicit; “it works most of the time” is not a security strategy.

Joke #1: DHCP is like a hotel concierge—helpful, but if you show up at 2 a.m. and the desk is locked, you’re sleeping in the lobby.

Three corporate-world mini-stories (how this fails in real life)

Incident #1: The outage caused by a wrong assumption

The environment was boring on purpose: a small fleet of Debian servers behind a top-of-rack switch, DHCP reservations keyed by MAC, and systemd-networkd managing everything. The team had one strong assumption: “interface names are stable on servers.” They matched on Name=enp3s0 everywhere.

Then a batch of hosts got a BIOS update. It changed PCI enumeration just enough that the NIC moved from one slot identity to another. The kernel didn’t break; it did what it always does. The interface name changed.

On reboot, networkd came up cleanly, read the .network file, and applied it to exactly zero interfaces. No errors that screamed on the console. No DHCP. No routes. Monitoring showed the hosts down; remote hands insisted the link lights looked fine.

The fix was technically trivial: match by MAC in [Match], and optionally add a .link file to pin a stable name if the team cared. But the real fix was procedural: stop relying on “stable enough.” If a match rule can go stale without a config change, it will—usually during maintenance windows when everyone is tired.

Incident #2: The optimization that backfired

A different org chased boot time. They wanted app services up faster after reboot, so they removed anything that looked like waiting. systemd-networkd-wait-online got disabled across the board, and some units got rewritten to start earlier.

Boots did get faster. So did failures.

A few services assumed the network was routable when they started. On cold boots, DHCP took a few seconds longer because the switchport used a security feature that delayed forwarding while it verified the MAC. The services launched, failed to connect to upstream dependencies, and entered crash loops. The network came up moments later—too late for the app that already decided the world was broken.

The postmortem was painful because everything looked fine when engineers logged in: network was up, DHCP leased, routes correct. The failure was timing. The “optimization” removed a synchronization point without replacing it with something correct.

They eventually reintroduced gating, but selectively: only for hosts and services that truly needed network at startup, and with tighter scoping (wait for a specific interface, not “any link ever”). The boot time penalty was small. The reliability improvement was not.

Incident #3: The boring practice that saved the day

This one is my favorite because it’s aggressively unsexy. The team ran systemd-networkd with two rules: match by MAC, and keep a minimal “known good” static config ready to drop in via automation for each rack.

One morning, after a planned power maintenance, a set of switches came back with a partial config. DHCP relay was broken on one VLAN. Servers rebooted, link came up, DHCP requests went out, and nothing came back. The network wasn’t “down”; it was just refusing to assign addresses on that segment.

The on-call didn’t waste time. They used console access to run a 15-second tcpdump on DHCP ports, saw no replies, and applied the pre-defined static fallback (address, gateway, DNS). That got the hosts reachable immediately, which allowed the network team to fix the relay without also fighting the “I can’t even reach the box” problem.

The key wasn’t heroics. It was having a tested escape hatch. When you already know what “good” looks like, you stop treating outages like mysteries.

Common mistakes: symptom → root cause → fix

1) “Interface is UP but has no IPv4 address”

Symptom: ip link shows UP,LOWER_UP, but ip -4 addr has nothing.

Root cause: DHCP not running, DHCP replies blocked, or the interface isn’t managed by networkd due to match failure.

Fix: Confirm networkctl status and networkd journal. Run DHCP tcpdump. Fix [Match] rules or allow DHCP through firewall.

2) “networkctl shows ‘link is not managed’”

Symptom: networkctl status enp7s0 says not managed.

Root cause: No matching .network file, or another manager took over.

Fix: Add a .network file with correct match; disable the conflicting manager for that interface.

3) “DHCP succeeds but there’s no default route”

Symptom: You have an address, but ip route lacks default via.

Root cause: DHCP server not providing router option, policy routing rules overriding, or multiple interfaces competing.

Fix: Set Gateway= explicitly for static setups, or fix DHCP scope. If multi-homed, define metrics and routing policy intentionally.

4) “Can ping gateway, can’t resolve names”

Symptom: ping 192.0.2.1 works, ping deb.debian.org fails.

Root cause: DNS not configured, systemd-resolved stub miswired, or stale /etc/resolv.conf.

Fix: Use resolvectl status. Decide resolved on/off. Ensure DNS is set in networkd or static resolv.conf is owned by the right tool.

5) “Network works after manual restart, fails only at boot”

Symptom: systemctl restart systemd-networkd brings it up; reboot doesn’t.

Root cause: Boot race: driver not ready, link comes up late, VLAN device created after networkd config attempt, or wait-online mis-specified.

Fix: Use deterministic match rules; consider adding a small RequiredForOnline= policy, adjust wait-online to wait for the right interface, and investigate driver/firmware in dmesg.

6) “SSH dead only after reboot, local console OK”

Symptom: Host is running, but remote access fails until someone touches networking.

Root cause: Firewall loads before addresses/routes exist, or policy drop blocks DHCP/ARP/neighbor discovery during early boot.

Fix: Make firewall rules explicitly allow required bootstrapping traffic, or stage firewall activation after network is configured (carefully, with clear dependencies).

Joke #2: The phrase “works on my machine” is less comforting when your machine is a server in a locked rack you’re not allowed to touch.

Checklists / step-by-step plan (from broken to boring)

Checklist A — Immediate triage on console (10 minutes, no ideology)

1. List interfaces and carrier: ip -br link. If no LOWER_UP, fix physical/switch/VLAN/driver first.
2. Confirm owner: systemctl is-active systemd-networkd and check NetworkManager/ifupdown conflicts.
3. Ask networkd: networkctl status. Find “not managed”, “configuring”, or “failed”.
4. Read logs: journalctl -u systemd-networkd -b. Look for DHCP timeouts, match failures, link flaps.
5. Verify kernel state: ip -4 addr and ip route. If no default route, fix that before DNS.
6. DNS check: resolvectl status and ls -l /etc/resolv.conf. Make sure you understand who owns DNS.
7. If DHCP is stuck: run a 15-second tcpdump for DHCP. Prove whether replies exist.

Checklist B — Make your networkd config resilient

1. Match by MAC (usually): In [Match], prefer MACAddress= for physical NICs. Name matching is fine for virtual interfaces you fully control.
2. Keep one interface per file: Avoid “wildcard match” that accidentally configures management and storage NICs the same way.
3. Be explicit about DHCP vs static: Don’t leave “default DHCP behavior” as an accident. If you want DHCP, say it. If you want static, write it fully (Address, Gateway, DNS).
4. Define routing intent on multi-homed hosts: Set metrics, policy routing rules, and avoid two default routes unless you really mean it.
5. Decide your DNS model: Either run systemd-resolved and integrate with it, or disable it and own /etc/resolv.conf. Mixed ownership is how you get heisenbugs.

Checklist C — Boot ordering without self-inflicted pain

1. Only use wait-online when it’s a requirement. If nothing needs network on startup, don’t block the boot just to feel safe.
2. If you need wait-online, scope it. Waiting for “any interface” on a host with optional links is a boot hang generator.
3. Stop writing services that assume network is instantly ready. Add retries/backoff. Services should survive a slow DHCP lease without sulking.
4. Watch for driver/firmware regressions. If network breaks after kernel/firmware change, confirm in dmesg and don’t be afraid to roll back while you validate.

A reliability quote (one, and only one)

Hope is not a strategy. — James Cameron

It’s not “ops theory.” It’s the difference between reading logs and rebooting until it “works.”

FAQ

1) Should I use systemd-networkd on Debian servers?

If you value predictable behavior and simple config, yes. It’s excellent for servers, VMs, and anything you want to configure declaratively. If you need interactive Wi‑Fi roaming or GUI integration, that’s NetworkManager territory.

2) My interface name changed after reboot. How do I prevent this from breaking config?

Don’t match on the name for physical NICs. Match on MACAddress= in the [Match] section. If you truly need stable names, use a .link file to assign a name based on MAC.

3) DHCP sometimes works, sometimes doesn’t. What should I check first?

Carrier and switch behavior. Run ethtool and capture DHCP packets with tcpdump. If your host sends requests but sees no replies, it’s almost never a “Linux problem.”

4) Why does restarting systemd-networkd fix it?

That typically points to timing: link comes up late, VLAN devices appear after networkd’s initial pass, or another service races. The fix is to remove the race (better match rules, correct dependencies), not to schedule a restart hack.

5) Should I enable systemd-networkd-wait-online?

Only if you have services that genuinely require the network to be configured before they start. If you do enable it, configure your units to wait for what they need—ideally a specific interface and state—rather than “network in general.”

6) DNS is broken but routes are fine. Where should I look?

Start with resolvectl status and ls -l /etc/resolv.conf. Confirm whether you’re using systemd-resolved (stub mode) or a static resolv.conf. Fix ownership; then fix nameservers.

7) Can nftables break DHCP?

Yes. Especially with default-drop policies and incomplete allowances. DHCP uses UDP 67/68 and broadcasts; some overly tight rulesets block it. Prove it with tcpdump and adjust rules explicitly.

8) How do I debug a missing default route on multi-NIC hosts?

Use ip route and ip route get 1.1.1.1 to see the chosen path and source address. Then define metrics or policy routing so the kernel stops “choosing” and starts obeying.

9) Is “link up” enough to call the network healthy?

No. Link up just means electrical/optical carrier. You still need correct VLAN tagging, correct addressing, correct routes, and working DNS. “LOWER_UP” is step one, not the finish line.

Conclusion: next steps you’ll thank yourself for

When Debian 13 networking doesn’t come up after reboot, the fastest path out is discipline: verify link, verify addressing, verify routing, verify DNS, in that order. Read the networkd journal like it owes you money. Don’t guess.

Next steps that pay off:

• Update your .network files to match by MAC (or another stable property), not by interface name unless you control naming.
• Decide whether you’re a systemd-resolved shop or not, and configure DNS accordingly. No hybrids.
• Audit for conflicts: only one network manager should configure a given interface.
• If boot races are real in your environment, use wait-online selectively and design services with retries instead of magical ordering.
• Keep a tested static fallback plan for management access. “We can’t reach the box” is not a fun problem to debug while the box is unreachable.