systemd-networkd vs. NetworkManager: Wann was auf Servern

Auf modernen Linux-Distributionen konkurrieren zwei Netzwerkstacks um denselben Job: systemd-networkd und NetworkManager. Beide sind ausgereift, beide werden von Red Hat, SUSE, Canonical und Debian unterstützt — und trotzdem eignet sich nicht jeder Stack für jeden Anwendungsfall. Wer auf einem Proxmox-Host, einem TrueNAS-Anschluss oder einem OPNsense-Backend die falsche Wahl trifft, ärgert sich später mit MAC-Adress-Wechseln, verlorenen VLAN-Tags oder DHCP-Race-Conditions.

Dieser Beitrag ordnet die beiden Stacks in einer Server-Umgebung ein, zeigt Bridge- und VLAN-Konfigurationen in beiden Varianten und beschreibt, wie man sauber von einem Stack auf den anderen migriert.

Die zwei Philosophien im Überblick

Der Unterschied ist nicht rein technisch, sondern konzeptionell. systemd-networkd wurde 2014 als minimalistische, deklarative Ergänzung zu systemd eingeführt. Konfiguration liegt in statischen .network-, .netdev- und .link-Dateien unter /etc/systemd/network/. Der Daemon ist klein, hat wenige Abhängigkeiten und kennt keine Plugins.

NetworkManager stammt ursprünglich aus dem Fedora-Umfeld (2004) und wurde für Desktop-Nutzer entwickelt, die zwischen WLAN, Ethernet, Modems und VPNs wechseln. Er bringt einen D-Bus-Service, nmcli, nmtui, eine GNOME-Applet-Integration sowie ein umfangreiches Plugin-System für OpenVPN, WireGuard, Cisco AnyConnect und mehr.

Kriterium	systemd-networkd	NetworkManager
Konfig-Format	Deklarativ (.network/.netdev)	Keyfile oder D-Bus/nmcli
Speicher-Footprint	Sehr klein (~5 MB RSS)	Größer (~30-60 MB RSS)
VPN-Plugins	Nein (externe Tools)	Ja (OpenVPN, WireGuard, IPsec)
WLAN-Roaming	Über wpa_supplicant/iwd	Nativ integriert
Runtime-Änderungen	Neustart der Unit	Live über D-Bus/nmcli
Container/Cloud-Images	Standard in vielen Minimal-Images	Selten vorinstalliert
Reproduzierbarkeit (IaC)	Sehr gut (Textdateien in Git)	Möglich, aber aufwendiger

Für Server heißt das grob: Je näher ein System an “reine Infrastruktur” liegt, desto besser passt networkd. Je näher es an “wechselnde Nutzer-Sessions” liegt, desto eher NetworkManager.

Wann systemd-networkd die richtige Wahl ist

Für die meisten Server-Rollen, die wir bei Kunden aufbauen, ist systemd-networkd der pragmatische Default:

• Hypervisoren (Proxmox, KVM auf Debian, Nutanix-CE) mit statischen Bridges, Bonds und VLANs
• Container-Hosts (Docker, Podman, LXC) ohne komplexe Roaming-Anforderungen
• Storage-Server wie TrueNAS-Anschlussknoten, NFS-Gateways oder Backup-Targets
• Bare-Metal-Cloud-Instanzen aus Minimal-Images (Ubuntu Server, Debian Cloud, Fedora CoreOS)
• Embedded-/Edge-Systeme auf ARM-Hardware, wo jedes MB RAM zählt

Der große Pluspunkt: Alle Konfigurationsdateien sind kleine, versionierbare Textdateien. Ein Ansible-Playbook oder ein Git-Repo mit /etc/systemd/network/*.network reicht, um zehn identische Hypervisoren identisch zu provisionieren.

Ein typisches Bridge-Setup für einen Proxmox-Host mit LACP-Bond und VLAN-fähiger Bridge sieht so aus:

# /etc/systemd/network/10-bond0.netdev
[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer3+4
MIIMonitorSec=1s
LACPTransmitRate=fast

# /etc/systemd/network/20-bond0-slaves.network
[Match]
Name=enp1s0f0 enp1s0f1

[Network]
Bond=bond0

# /etc/systemd/network/30-vmbr0.netdev
[NetDev]
Name=vmbr0
Kind=bridge

[Bridge]
VLANFiltering=yes
STP=no

# /etc/systemd/network/40-vmbr0.network
[Match]
Name=vmbr0

[Network]
Address=10.20.10.5/24
Gateway=10.20.10.1
DNS=10.20.10.1
VLAN=vmbr0.100

[BridgeVLAN]
VLAN=100-199

Nach systemctl restart systemd-networkd steht die Konfiguration — und lässt sich per networkctl status vmbr0 prüfen.

Wann NetworkManager sinnvoll bleibt

NetworkManager ist nicht nur “das Ding für Laptops”. In folgenden Server-Szenarien ist er sogar die bessere Wahl:

• RHEL/Rocky/Alma ab 9: Red Hat hat networkd im RHEL-Kontext nie voll unterstützt, nmcli ist die offizielle Schnittstelle — inklusive Kickstart-Integration.
• Roaming-fähige Edge-Boxen mit Mobilfunk-Modems (LTE/5G) und Fallback auf Ethernet.
• VPN-Gateways mit Nutzer-Sessions: NetworkManager kann OpenVPN-, WireGuard- und IPsec-Profile pro Nutzer speichern und auf Login aktivieren.
• Workstation-artige Server: Entwicklungs- und Testmaschinen mit KVM, an denen auch mal ein USB-Ethernet steckt.
• Systeme mit häufigen Runtime-Änderungen: Ein nmcli con mod eth0 ipv4.addresses 10.20.30.5/24 && nmcli con up eth0 ist zur Laufzeit einfacher als eine Neu-Definition.

Dasselbe Bridge-Setup wie oben, aber in NetworkManager:

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,lacp_rate=fast,xmit_hash_policy=layer3+4,miimon=100"

nmcli con add type ethernet ifname enp1s0f0 master bond0 con-name bond0-slave1
nmcli con add type ethernet ifname enp1s0f1 master bond0 con-name bond0-slave2

nmcli con add type bridge ifname vmbr0 con-name vmbr0 \
  bridge.stp no bridge.vlan-filtering yes
nmcli con mod vmbr0 ipv4.addresses 10.20.10.5/24 ipv4.gateway 10.20.10.1 \
  ipv4.dns 10.20.10.1 ipv4.method manual

nmcli con add type bridge-slave ifname bond0 master vmbr0 con-name bond0-in-vmbr0
nmcli con up bond0-slave1 && nmcli con up bond0-slave2
nmcli con up vmbr0

Beide Wege führen ans Ziel — der Unterschied liegt in der Denkweise: networkd beschreibt einen Zielzustand, NetworkManager führt eine Serie von Kommandos aus, die einen Zielzustand ergeben.

Praxis: VLAN-Tagging auf einem Storage-Uplink

Ein häufiger Sonderfall in unseren Linux-Projekten ist der VLAN-getaggte Uplink zwischen Hypervisor und Storage. Das Muster ist überall gleich: physische NIC unverändert lassen, VLAN-Interface obendrauf, IP dort konfigurieren.

systemd-networkd:

# /etc/systemd/network/10-storage.network
[Match]
Name=enp2s0

[Network]
VLAN=storage.42

# /etc/systemd/network/20-storage-vlan.netdev
[NetDev]
Name=storage.42
Kind=vlan

[VLAN]
Id=42

# /etc/systemd/network/21-storage-vlan.network
[Match]
Name=storage.42

[Network]
Address=10.42.0.5/24

NetworkManager:

nmcli con add type vlan con-name storage.42 ifname storage.42 \
  dev enp2s0 id 42 \
  ipv4.method manual ipv4.addresses 10.42.0.5/24
nmcli con up storage.42

In beiden Fällen empfehlen wir, Jumbo-Frames (MTU 9000) am Storage-VLAN einzustellen, wenn der Switch sie durchreicht. Bei networkd über MTUBytes=9000, bei NetworkManager über 802-3-ethernet.mtu 9000 bzw. vlan.mtu 9000.

Migration in beide Richtungen

Wechsel zwischen den Stacks sind alltäglich — etwa wenn ein Proxmox-Host von ifupdown2 auf networkd umgestellt wird oder ein RHEL-Server nach einer Aufräumaktion nur noch networkd fahren soll.

Der Ablauf ist immer derselbe:

1. Inventarisieren: ip -o link, ip -o addr, ip -o -4 route, ip -o -6 route und nmcli -t con show bzw. networkctl list als Startpunkt.
2. Zielkonfiguration schreiben und in /etc/systemd/network/ bzw. als nmconnection ablegen. Vor dem Aktivieren als Text prüfen — Tippfehler in [Match] oder MAC-Adressen sind die häufigste Fehlerquelle.
3. Fallback vorbereiten: at now + 10 min <<< 'systemctl restart networking' oder ein serielles Konsolen-Fenster offen halten.
4. Alten Dienst deaktivieren: systemctl disable --now NetworkManager bzw. systemctl disable --now systemd-networkd systemd-networkd-wait-online.
5. Neuen Dienst starten und mit networkctl / nmcli con show --active prüfen.
6. DNS trennen: /etc/resolv.conf gehört bei beiden Stacks entweder systemd-resolved oder wird statisch überschrieben. Doppelte Verwaltung führt zu wechselnden Nameservern — ein klassischer, schwer zu debuggender Fehler.

Wichtig: NetworkManager kennt einen “unmanaged”-Modus. Interfaces, die von networkd verwaltet werden, sollten in /etc/NetworkManager/conf.d/10-unmanaged.conf explizit ausgeschlossen werden, damit sich beide Dienste nicht in die Quere kommen.

Empfehlung für typische Rollen

Als grobe Faustregel aus unserer Projekterfahrung:

Rolle	Empfehlung
Proxmox VE Host	systemd-networkd oder ifupdown2 (Proxmox-Default)
Debian/Ubuntu Container-Host	systemd-networkd
RHEL/Rocky Server	NetworkManager (offiziell unterstützt)
TrueNAS/SAN-Node (Debian-basiert)	systemd-networkd
OPNsense-Backend (FreeBSD)	Eigener Stack — hier nicht relevant
Edge-Box mit LTE-Modem	NetworkManager
VDI-/Terminal-Server	NetworkManager (VPN, User-Sessions)
Kubernetes-Node	systemd-networkd, CNI übernimmt Pod-Netz

Es gibt keinen “besseren” Stack — nur den passenden. Wer sich einmal für einen entscheidet und ihn konsequent per Konfigmanagement rollt, spart sich langfristig mehr Ärger als jede Mikro-Optimierung bringt.

---

DATAZONE unterstützt Sie beim Design und Betrieb Ihrer Linux-Server-Netzwerke — von der Migration einzelner Hosts bis zur Ansible-basierten Vereinheitlichung ganzer Cluster. Wenn Sie bei Proxmox-, TrueNAS- oder OPNsense-Projekten unschlüssig sind, welcher Netzwerkstack in Ihrer Umgebung sinnvoll ist, sprechen Sie uns an. Wir schauen gemeinsam auf Ihre Anforderungen und liefern eine Empfehlung, die auch in drei Jahren noch trägt.