Proxmox SDN mit VXLAN — virtuelle Netze über mehrere Nodes

Hinweis: Dieser Beitrag enthält Affiliate-Links (mit * gekennzeichnet). Kaufst du über einen dieser Links, erhalten wir eine kleine Provision — für dich ändert sich der Preis nicht. Hardware wird vor jeder Empfehlung mindestens vier Wochen im eigenen Homelab getestet.

Bei kleinen Proxmox-Setups reicht die Standard-Bridge vmbr0 völlig aus — alle VMs hängen am gleichen LAN, fertig. Sobald aber ein Cluster aus mehreren Nodes entsteht oder du VMs in eigenen Subnetzen isolieren willst, wird es spannender. Genau dafür hat Proxmox seit Version 8 das integrierte Software Defined Networking (SDN) — eine Web-UI-getriebene Lösung, mit der du virtuelle Netze über mehrere Hosts hinweg spannen kannst. In diesem Guide bauen wir gemeinsam ein VXLAN-Setup und schauen uns an, wann sich der Sprung von der einfachen Bridge zur SDN-Welt wirklich lohnt.

Warum SDN — was die normale Bridge nicht kann

Die klassische Linux-Bridge ist großartig für einfache Setups: Du hängst VMs an vmbr0, sie reden mit deinem Heimnetz, fertig. Sobald aber mehrere Nodes ins Spiel kommen, taucht ein Problem auf: VMs auf Node A und Node B sind nicht ohne Weiteres im selben Layer-2-Netz. Du müsstest die VMs in unterschiedliche Subnetze stecken und das Routing dazwischen organisieren — oder eine getaggte VLAN-Kette über alle Nodes ziehen, was schnell unübersichtlich wird.

Genau hier kommt SDN ins Spiel. Die wichtigsten Vorteile in der Praxis:

• Knoten-übergreifende VNets: Eine VM auf Node 1 und eine auf Node 3 liegen im selben virtuellen Subnetz, obwohl die physischen Hosts in verschiedenen Räumen stehen können.
• Mandantenfähigkeit: Du kannst Zonen pro Kunde oder Projekt anlegen und Netze sauber voneinander trennen.
• Live-Migration über Subnetz-Grenzen: Eine VM bleibt in ihrem VNet, egal auf welchem Node sie gerade läuft.
• Weniger Pflege im interfaces-File: Jede Änderung läuft über die SDN-API und wird konsistent auf alle Nodes verteilt.
• Multi-Site-Cluster mit EVPN: Standorte werden über öffentliche IPs verbunden, VMs bleiben trotzdem im selben Layer-2-Netz.

SDN-Konzepte verstehen — Zonen, VNets, Subnetze

SDN in Proxmox arbeitet mit drei Bausteinen, die aufeinander aufbauen. Wenn du die einmal verstanden hast, ist der Rest Konfigurations-Routine:

• Zone: der oberste Container. Bestimmt, mit welcher Technik die virtuellen Netze umgesetzt werden — klassische VLAN-Zone, VXLAN, EVPN, QinQ oder einfache Linux-Bridge. Pro Zone ein Verfahren.
• VNet: ein virtuelles Netz innerhalb einer Zone. Kannst du dir vorstellen wie eine eigene Bridge, die über alle Cluster-Nodes verteilt ist. Eine VM hängt an einem VNet, nicht mehr direkt an einer physischen Bridge.
• Subnet: die IP-Konfiguration eines VNets — also IP-Range, Gateway, optional ein DHCP-Bereich. Pro VNet ein oder mehrere Subnets.

Der Charme ist die Trennung: Zonen-Definition machst du einmal pro Cluster. VNets sind dann die „Bridges, die über die Cluster-Grenzen hinaus existieren“. Subnets bringen die IP-Welt rein, ohne dass du in jeder VM einzeln IPs vergeben musst.

Voraussetzungen für ein VXLAN-Setup

• Proxmox VE 8.0 oder neuer — SDN ist erst dort vollständig im Web-UI integriert. Für Proxmox 7 gab es noch Tech-Preview-Pakete; wer aktuell ist, hat es ab Werk.
• Mindestens zwei Nodes im Cluster — SDN ergibt auf einem Single-Node-Host kaum Sinn, weil du dann genauso gut eine VLAN-aware Bridge nehmen könntest.
• Layer-3-Verbindung zwischen den Nodes — klingt komplex, ist aber meist gegeben: Wenn deine Nodes sich gegenseitig per IP erreichen, hast du Layer 3.
• MTU 9000 (Jumbo Frames) — empfohlen, damit VXLAN-Header nicht zu Fragmentation führen. Dein Switch muss Jumbo Frames unterstützen.
• Frei verfügbare VNI-Range — jeder VXLAN-Tunnel hat eine VNI (VXLAN Network Identifier). Üblich ist eine eigene Range im Bereich 10000-20000 für deine Nutzungs-Zwecke.

Für reines Homelab reicht ein managed Switch mit Jumbo-Frame-Unterstützung und 2,5- oder 10-GbE-Ports. SFP+-Hardware mit 10 GbE ist nicht zwingend, beschleunigt aber Live-Migrationen und Storage-Replikationen erheblich.

Schritt für Schritt: eine VXLAN-Zone aufsetzen

Schritt 1: Cluster-Vorbereitung prüfen

Bevor du SDN einschaltest, überprüfe einmal, ob dein Cluster wirklich rund läuft. Ein gesundes Quorum ist Voraussetzung — sonst pushen sich SDN-Konfigurationen nicht sauber auf alle Nodes durch:

pvecm status
# erwartet: "Quorate: Yes"

ping -M do -s 8972 <ip-anderer-node>
# Test, ob 9000-Byte-MTU durchkommt

Wenn der Ping mit 8972 Bytes ohne „Frag needed“ durchläuft, ist deine Jumbo-Frame-Konfiguration sauber. Falls nicht, im Switch und an den NICs MTU 9000 setzen, bevor du weitermachst.

Schritt 2: SDN aktivieren

SDN ist auf neueren Proxmox-Versionen bereits installiert, muss aber pro Cluster einmal aktiviert werden. Im Web-UI:

1. Datacenter → SDN → die einzelnen Bereiche werden sichtbar (Zones, VNets, Subnets, Options, IPAM).
2. Falls du Pakete nachinstallieren musst: auf jedem Node apt install libpve-network-perl ifupdown2.
3. Optional: Datacenter → Options → „SDN“ einschalten, falls die Sektion noch ausgeblendet ist.

Schritt 3: VXLAN-Zone anlegen

Datacenter → SDN → Zones → Add → VXLAN. Die wichtigsten Felder:

• ID: ein kurzer eindeutiger Name, z. B. vxhome.
• Peers Address List: Komma-separierte Liste der IP-Adressen aller Cluster-Nodes (die Adressen, mit denen sie sich gegenseitig sehen).
• MTU: 9000 lassen, wenn dein Netz das hergibt. Sonst 1450 setzen (Standard-Ethernet abzüglich VXLAN-Header).
• Nodes: alle Cluster-Nodes auswählen, auf die diese Zone ausgerollt werden soll.

Schritt 4: VNet hinzufügen

Datacenter → SDN → VNets → Create. Felder:

• Name: z. B. vmnet01.
• Zone: die eben angelegte VXLAN-Zone.
• Tag: die VNI — wähle eine freie Zahl, z. B. 10001.

Schritt 5: Subnet definieren (optional, aber empfohlen)

VNet anklicken → Subnets → Create. Hier konfigurierst du IP-Range, Gateway und optional einen DHCP-Bereich:

• Subnet: z. B. 10.10.10.0/24.
• Gateway: z. B. 10.10.10.1 — das wird auf dem Proxmox-Node als virtuelle IP angelegt.
• SNAT: aktivieren, damit VMs aus diesem VNet ins externe Netz NAT-en können.

Schritt 6: Konfiguration anwenden

Im SDN-Menü oben rechts auf Apply. Proxmox pusht die Konfiguration jetzt auf alle ausgewählten Nodes. Im Hintergrund läuft ifreload -a, das die neuen Bridges live einrichtet.

Schritt 7: VM ins VNet hängen

Bei jeder VM unter Hardware → Network Device → Bridge: das neu erstellte VNet erscheint als Auswahl-Option. Eintragen, VM neu starten, fertig. Die VM hängt jetzt im VXLAN und kann mit anderen VMs aus demselben VNet kommunizieren — egal auf welchem Cluster-Node sie gerade laufen.

Multi-Site mit EVPN — wenn der Cluster über mehrere Standorte geht

Reines VXLAN reicht innerhalb eines lokalen Clusters. Sobald die Nodes über öffentliche IPs verbunden sind oder du mehrere Standorte ins gleiche SDN holen willst, wird EVPN (Ethernet VPN) interessant. EVPN ist eine BGP-Erweiterung, die das Routing zwischen VXLAN-Tunneln dynamisch verteilt.

Im SDN-Menü kommt das in zwei Schritten: erst eine EVPN Controller-Definition (mit BGP-AS-Nummer), dann eine EVPN-Zone, die diesen Controller nutzt. Die Konfiguration ist deutlich anspruchsvoller als reines VXLAN — im Homelab brauchst du das eher nicht. Lohnen tut es sich erst, wenn du mehrere physische Standorte verbindest oder einen Multi-Tenant-Hoster betreibst.

Routing zwischen VNets — wenn VMs aus verschiedenen Subnetzen reden sollen

Eine häufige Frage nach dem ersten VNet-Setup: Wie kommen VMs aus VNet A in VNet B? Es gibt zwei saubere Wege:

• Layer-3-Routing über die Gateway-IPs der VNets. Jedes VNet hat ein Gateway auf dem Proxmox-Host. Die Hosts routen dann zwischen den Subnetzen — mit eigenen Firewall-Regeln, die du im Datacenter-Firewall-Menü pflegst.
• Eine dedizierte Router-VM, z. B. mit OPNsense oder pfSense. Die VM hängt mit jeweils einem virtuellen Interface in jedem VNet und macht das Routing inklusive Firewall-Policy. Empfohlen, sobald die Anzahl an VNets oder die Sicherheits-Anforderungen wachsen.

Häufige Fallstricke aus der Praxis

1. MTU vergessen: Wenn der Switch keine Jumbo Frames spricht, fragmentiert VXLAN. Du merkst das an mysteriösen Performance-Einbrüchen oder Verbindungsproblemen bei größeren Paketen. Vor dem Setup mit ping -M do -s 8972 testen.
2. Peers Address List unvollständig: Jeder Node muss in der Liste stehen, sonst sehen einzelne VMs nicht alle anderen. Bei Cluster-Erweiterung daran denken, die Liste zu aktualisieren.
3. Apply nicht geklickt: SDN-Änderungen werden erst beim „Apply“-Klick auf alle Nodes verteilt. Wenn ein Node die neuen VNets nicht kennt, war wahrscheinlich der Apply nicht erfolgreich.
4. Firewall-Default zu offen: SDN bedeutet nicht automatisch Sicherheit. Pro VNet eigene Firewall-Regeln definieren.
5. Ungetaggte VMs: VMs, die direkt an vmbr0 hängen, sehen keine SDN-VNets — und umgekehrt. Wer von Bridge auf SDN umzieht, muss die Network-Device-Konfiguration der VM anpassen.

Häufige Fragen

Lohnt sich SDN auf einem Single-Node-Homelab?

Selten. Auf einem Single-Node erreichst du mit einer VLAN-aware Linux-Bridge dasselbe Ergebnis bei deutlich weniger Komplexität. SDN spielt seine Stärke erst aus, wenn mehrere Nodes ins Spiel kommen.

VXLAN oder klassische VLAN-Trunks?

VLANs sind einfacher und auf Layer 2 begrenzt — gut für ein einzelnes Rechenzentrum mit getaggten Switches. VXLAN tunnelt Layer 2 über Layer 3 und ist dadurch flexibler, vor allem über mehrere Standorte. Wenn du im selben Schaltschrank bist, reicht VLAN. Sobald die Nodes routen müssen, wird VXLAN spannend.

Wie verhält sich SDN beim Cluster-Reboot?

Die Konfiguration ist persistent — SDN-Einstellungen liegen im Cluster-Filesystem und werden bei jedem Boot wieder hergestellt. Wichtig ist nur, dass die Nodes im Cluster Quorum haben, damit Änderungen sich propagieren können.

Kann ich SDN mit Ceph kombinieren?

Ja, sogar empfohlen. Ceph läuft am besten auf einem dedizierten Storage-Netz — das kann eine eigene VXLAN-Zone sein, getrennt von den VM-Netzen. Mehr zu Ceph in unserem Cluster-Tutorial.

Wie sichere ich SDN-Konfigurationen?

Die Konfiguration liegt in /etc/pve/sdn/ — wird beim normalen PBS-Backup der VMs nicht automatisch mitgesichert. Eine separate Sicherung von /etc/pve/ ist empfehlenswert, etwa als wöchentlicher rsync-Job.

Welche Performance-Einbußen hat VXLAN gegenüber Linux-Bridges?

Bei aktivierten Hardware-Offloads (VXLAN-Offload auf modernen NICs) liegt der Overhead bei wenigen Prozent. Ohne Offload kann es spürbarer werden — bis zu 10-15 % Bandbreitenverlust. Daher: NIC-Modelle mit VXLAN-Offload bevorzugen, vor allem bei 10 GbE und schneller.

Gibt es eine Alternative zu Proxmox SDN?

Im VMware-Lager ist NSX das Pendant — mit deutlich mehr Tiefe, aber auch mit Lizenzkosten. Im Linux-Bereich gibt es Calico oder Cilium für Kubernetes-Cluster. Wer ein eigenes SDN ohne Proxmox baut, findet mit OVN/Open vSwitch eine reine Open-Source-Variante. Ein direkter Vergleich zu VMware steht im Spoke Proxmox vs. VMware.

Wo es weitergeht

• Der komplette Proxmox-Guide — die Pillar mit Storage, Cluster, Backup, Netzwerk-Basics.
• Proxmox-Cluster mit Ceph — SDN passt perfekt zu HA-Cluster-Setups.
• LXC vs VM in Proxmox — was läuft im VNet, was nicht.
• Heimnetz mit VLANs absichern — klassische VLAN-Welt, gute Vorbereitung auf SDN.
• Proxmox vs. VMware 2026 — falls du den NSX-Vergleich suchst.

Externe Pflichtquellen:

• Proxmox-Wiki: Software Defined Network — offizielle Doku mit allen Details.
• RFC 7348 — VXLAN — das ursprüngliche Protokoll-Dokument.
• Proxmox-Community-Forum — viele SDN-Praxis-Threads.

Du planst gerade ein SDN-Setup und hängst an einer Stelle? Schreib uns eine Mail an admin@lapalutschi.de.