Proxmox SDN mit VXLAN-Overlay: Multi-Tenant-Netzwerke sauber aufsetzen

VLANs sind seit über zwanzig Jahren das Arbeitspferd der Netzwerk-Segmentierung. Sie funktionieren, sie sind überall verstanden und sie reichen für die meisten mittelständischen Umgebungen völlig aus. Aber sobald mehrere Mandanten auf dem gleichen Cluster laufen sollen, mehrere Standorte über Layer 2 verbunden werden müssen oder die 4094 nutzbaren VLAN-IDs knapp werden, stößt das klassische Modell an seine Grenzen. Genau an dieser Stelle setzt VXLAN an — und mit Proxmox SDN wird das Overlay-Netzwerk zu einem Werkzeug, das sich auch ohne Netzwerk-Spezialistenteam bedienen lässt.

Dieser Artikel zeigt, wie VXLAN in Proxmox VE 9 konkret funktioniert, wann sich der Umstieg vom reinen VLAN-Modell lohnt und wo die typischen Fallstricke beim produktiven Betrieb liegen. Grundlagen zu Zonen, VNets und Subnetzen haben wir bereits in unserem Beitrag zu Proxmox SDN als Konzept behandelt — hier geht es um die VXLAN-Zone und ihre Praxis.

Warum VXLAN, wenn VLAN doch funktioniert?

VLANs arbeiten auf Layer 2 und sind an die physische Switch-Infrastruktur gebunden. Jeder Trunk-Port muss die relevanten VLAN-IDs tragen, jeder beteiligte Switch muss die VLANs kennen, und jede Änderung berührt mindestens einen Netzwerk-Admin. Das ist für zehn oder zwanzig Netze unproblematisch — bei einem Hoster mit fünfzig Kunden, einem Software-Haus mit zwanzig Testumgebungen oder einem Cluster, der sich über zwei Rechenzentren erstreckt, wird es mühsam.

VXLAN (Virtual Extensible LAN) löst drei konkrete Probleme auf einmal:

• Statt 12 Bit VLAN-ID stehen 24 Bit VNI (VXLAN Network Identifier) zur Verfügung — rund 16 Millionen Netze statt 4094.
• Die Overlay-Pakete werden in UDP gekapselt und fließen über die normale IP-Infrastruktur. Die physischen Switches müssen nur IP routen können, nicht mehr jede Kunden-VLAN-ID kennen.
• Ein Overlay kann über Standorte hinweg aufgespannt werden, solange zwischen den Nodes IP-Konnektivität besteht. Das macht georedundante Cluster und Stretch-Setups technisch sauber möglich.

Der Preis dafür ist Overhead: VXLAN fügt jedem Frame einen 50-Byte-Header hinzu. Ohne MTU-Anpassung im Underlay zahlt man das in Form von fragmentierten Paketen und spürbarer Performance-Einbuße. Darauf kommen wir weiter unten zurück.

Proxmox SDN VXLAN im Detail: Zone, VNet, Subnet

Die SDN-Hierarchie in Proxmox VE 9 ist dreistufig und bleibt auch bei VXLAN gleich: Zone als Technologie-Container, VNet als virtuelles Netz innerhalb der Zone und Subnet als IP-Konfiguration dieses VNets. Für eine VXLAN-Zone kommt eine zusätzliche Eigenschaft hinzu — die Liste der Peers, also die IP-Adressen aller Cluster-Nodes, die an diesem Overlay teilnehmen.

Ein typisches Setup für drei Nodes sieht so aus:

Datacenter → SDN → Zones → Add → VXLAN
  ID:        vx-tenant-a
  Peers:     10.10.0.11, 10.10.0.12, 10.10.0.13
  MTU:       1450   (bei physischem MTU 1500)

Danach legt man unter VNets die einzelnen virtuellen Netze an. Jedes VNet erhält eine eigene VNI, die als Trennmerkmal zwischen den Overlays dient. Zwei VNets mit unterschiedlicher VNI in derselben Zone sind vollständig voneinander isoliert, obwohl sie dieselbe physische Infrastruktur nutzen.

VNets → Add
  ID:   kunde-a-prod
  Zone: vx-tenant-a
  Tag:  10001        (VNI)

Zum Schluss optional ein Subnet je VNet mit CIDR-Angabe und Gateway. Wer DHCP für die VMs im Overlay bereitstellen will, aktiviert pro Subnet den dnsmasq-Dienst — Proxmox verwaltet den dann automatisch auf den beteiligten Nodes.

Nach einem Apply auf Datacenter-Ebene legt Proxmox auf jedem Node die passenden Linux-Bridges und VXLAN-Interfaces an. Eine VM wird nicht mehr direkt an vmbr0 angeschlossen, sondern an die neue Bridge kunde-a-prod. Alles andere passiert transparent im Hintergrund.

Multi-Tenant-Trennung: ein Cluster, viele Kunden

Der klassische Anwendungsfall für VXLAN im Mittelstand ist das Hosten mehrerer Mandanten auf demselben Proxmox-Cluster. Jeder Kunde bekommt eine oder mehrere eigene VNIs, die untereinander keine Verbindung haben — selbst wenn die VMs auf demselben Hypervisor laufen. Die Isolation findet auf Netzwerk-Ebene statt und ist unabhängig von Firewall-Regeln.

Ein praktikables Namensschema erleichtert den Betrieb enorm. Wir verwenden bei Projekten typischerweise:

• Zone-ID: vx-<kurz> für die eigentliche VXLAN-Zone pro Standort oder Mandantengruppe
• VNet-ID: <kunde>-<zweck>, zum Beispiel mueller-dmz oder schmidt-prod
• VNI-Vergabe: nach Blöcken je Kunde, etwa 10001–10099 für Kunde A, 10100–10199 für Kunde B

Diese Trennung hat drei Konsequenzen für den Betrieb:

• VMs eines Kunden sehen keine Broadcasts anderer Kunden. ARP-Scans oder versehentliche DHCP-Server bleiben im eigenen VNet.
• Live-Migration zwischen Nodes funktioniert ohne Netzwerk-Umkonfiguration, weil das VNet überall gleich heißt.
• Beim Rückbau eines Kunden reicht das Entfernen seines VNets im GUI. Keine Switch-Konfiguration, keine VLAN-ID-Pflege.

Wichtig: Die Isolation ist eine Netzwerk-Isolation, keine vollständige Mandantenfähigkeit. Wer echte Multi-Tenant-Sicherheit braucht, kombiniert das mit Proxmox-Pools, getrennten Benutzern und — bei hohen Anforderungen — physisch getrennten Clustern.

MTU, Underlay und die Fallstricke, die niemand erzählt

Der häufigste Grund, warum VXLAN-Setups im ersten Anlauf merkwürdig performen, ist die MTU. VXLAN fügt 50 Byte Overhead hinzu: 14 Byte Ethernet, 20 Byte IP, 8 Byte UDP, 8 Byte VXLAN-Header. Bei einer physischen MTU von 1500 bleiben für das Overlay-Frame also 1450 Byte übrig. Diese MTU muss in der VXLAN-Zone exakt so eingetragen werden, sonst fragmentieren große Pakete oder werden stillschweigend verworfen.

Deutlich eleganter ist der Weg über Jumbo Frames im Underlay. Wenn das physische Netz MTU 9000 kann, konfiguriert man die VXLAN-Zone mit MTU 8950 und hat volle 8800 Byte für Nutzdaten im Overlay. Das lohnt sich besonders bei Storage- und Backup-Traffic. Wie wir unsere physischen Cluster-Netze dafür auslegen, haben wir im Beitrag Proxmox Cluster-Netzwerk richtig planen beschrieben.

Zwei weitere Punkte sind in der Praxis wichtig:

• Multicast ist optional, aber nicht trivial. Proxmox nutzt für Standard-VXLAN den sogenannten Head-End-Replication-Modus — jeder Node schickt Broadcast- und Multicast-Pakete als Unicast an alle anderen Peers. Das funktioniert ohne jegliche Switch-Konfiguration, skaliert aber nicht beliebig. Ab etwa einem Dutzend Nodes wird echtes Multicast-Underlay interessant.
• Firewall und Hairpinning. Wenn zwei VNets über eine externe Firewall miteinander reden sollen, muss der Traffic das Overlay verlassen. Das geht über eine Proxmox-Firewall-VM mit einem Bein in jedem VNet oder über eine physische Firewall mit entsprechender Routing-Konfiguration.

EVPN: wenn VXLAN alleine nicht mehr reicht

Für isolierte Overlays reicht die Standard-VXLAN-Zone. Sobald aber zwischen den VNets geroutet werden soll, mehrere Standorte beteiligt sind oder MAC-Adressen zentral verwaltet werden müssen, kommt EVPN (Ethernet VPN) ins Spiel. Proxmox SDN unterstützt EVPN seit Version 7 produktiv und bringt alle nötigen Komponenten mit — FRRouting als Controller und BGP als Signalisierungs-Protokoll.

Die wichtigsten Unterschiede in der Praxis:

• Statt Head-End-Replication tauschen die Nodes MAC- und IP-Informationen über BGP aus. Das reduziert Broadcast-Verkehr und skaliert deutlich besser.
• Eine EVPN-Zone kann mehrere VRFs (Virtual Routing and Forwarding Instances) führen. So lassen sich Routing-Tabellen pro Mandant trennen, während alle Overlays dasselbe Underlay nutzen.
• Zwischen Standorten funktioniert EVPN sauber über Layer-3-Links. Wer einen Stretched Cluster oder ein georedundantes Setup baut, kommt an EVPN mittelfristig nicht vorbei.

Der Preis: Die Konfiguration ist deutlich komplexer. ASN-Vergabe, Route-Reflector-Design, VRF-Mapping — das sind Themen, bei denen ohne Vorerfahrung schnell etwas schiefgeht. In unseren Projekten setzen wir EVPN gezielt dort ein, wo es wirklich gebraucht wird, und raten vom „EVPN by default” ab.

Ab wann lohnt sich der Aufwand?

Nicht jede Umgebung braucht VXLAN. Ein Dreier-Cluster mit fünf VLANs für Produktion, Backup, Management, Storage und Testing fährt mit klassischen VLANs auf einem konfigurierten Trunk-Port deutlich einfacher und performanter. VXLAN entfaltet seinen Nutzen in konkreten Konstellationen:

• Mehrere Mandanten auf demselben Cluster, bei denen Netzwerk-Isolation ein Kundenwunsch ist
• Viele kurzlebige Netze — zum Beispiel bei Software-Entwicklung mit automatisierten Testumgebungen
• Standortübergreifende Cluster, die Layer-2-Kontinuität brauchen
• Umgebungen, in denen die VLAN-ID knapp wird oder die Switch-Konfiguration zum Bottleneck geworden ist

Für klassische Mittelstands-Virtualisierung mit einem Rechenzentrum und überschaubarer Zahl von Netzen ist der SDN-VXLAN-Pfad eher Overkill — hier ist eine saubere VLAN-Trennung schlanker und wartungsärmer. Wer sich unsicher ist, auf welchem Weg der eigene Cluster am besten aufgestellt wird, kann im Rahmen eines IT-Service-Beratungstermins die konkrete Topologie mit uns durchgehen.

FAQ zu Proxmox SDN mit VXLAN-Overlay

Brauche ich spezielle Switches, um VXLAN in Proxmox einzusetzen?

Nein. Da VXLAN auf IP-Ebene läuft, reicht jeder Switch, der die Nodes in einem gemeinsamen IP-Segment verbindet. Weder VXLAN-Hardware-Offload noch Multicast-Konfiguration sind zwingend. Erst bei größeren Clustern oder beim Einsatz von EVPN mit vielen Routen werden Switches mit VXLAN- und BGP-Unterstützung interessant.

Was unterscheidet VXLAN von einem VLAN-Trunk im Alltag?

Im Alltagsbetrieb merkt man den Unterschied vor allem bei Änderungen. Ein neues Netz anlegen bedeutet bei VLANs: Switch-Konfiguration, Trunk-Port erweitern, Node-Bridge anlegen. Bei Proxmox SDN mit VXLAN sind es drei Klicks im Webinterface, und alle Nodes übernehmen die Änderung automatisch. Bei stabilen, selten geänderten Netzen ist der Unterschied gering, bei vielen Mandanten enorm.

Verliere ich Performance, wenn ich auf VXLAN umsteige?

Durch den zusätzlichen Header und die Kapselung kostet VXLAN etwas CPU-Zeit auf den Nodes. Moderne Server-CPUs und Netzwerkkarten mit VXLAN-Offload-Fähigkeit reduzieren das deutlich. Entscheidend ist die MTU-Konfiguration: Richtig eingestellt ist der Overhead im Praxisbetrieb kaum spürbar. Falsch eingestellt — zum Beispiel VXLAN-MTU 1500 bei Underlay-MTU 1500 — kommt es zu Fragmentierung mit sichtbaren Performance-Problemen.

Kann ich VLANs und VXLAN parallel betreiben?

Ja, das ist sogar die Regel. Management-Netz, Corosync, Storage und Backup bleiben typischerweise auf klassischen VLANs oder dedizierten physischen Interfaces, während VXLAN nur für die VM-Netze zum Einsatz kommt. Proxmox trennt das sauber: SDN-Zonen sind unabhängig von den physischen Bridges, die weiter genutzt werden können.

Wie steht VXLAN in Proxmox zu TrueNAS und NFS-Storage?

Storage-Traffic gehört aus Performance- und Stabilitätsgründen nicht ins Overlay. NFS zwischen Proxmox-Nodes und einem TrueNAS-System läuft bei uns immer über ein dediziertes Storage-VLAN auf separater Hardware oder zumindest separatem Interface. Die VXLAN-Isolation ist für VM-zu-VM-Verkehr gedacht, nicht für Hypervisor-zu-Storage. Welche Hardware dafür passt, lässt sich im TrueNAS-Konfigurator zusammenstellen.

Was passiert bei einem Node-Ausfall mit dem Overlay?

Die VXLAN-Konfiguration ist Teil des Proxmox-Cluster-Status und steht nach dem Ausfall auf allen überlebenden Nodes unverändert zur Verfügung. VMs lassen sich per HA auf andere Nodes verschieben, ohne dass Netzwerk-Umkonfiguration nötig wird — das VNet existiert dort ja bereits. Wichtig ist nur, dass die Peer-Liste der Zone alle potenziellen Ziel-Nodes enthält.