pressmaster - stock.adobe.com
Automatisierte Netzwerkverwaltung und SDN in Proxmox VE
SDN in Proxmox VE liefert klare Strukturen für virtuelle Netze im Cluster und schafft eine flexible Umgebung für LXC und VMs. Der Text zeigt praxisnahe Wege zu stabilen Abläufen.
Software-defined Networking (SDN) in Proxmox VE erleichtert die Kontrolle über virtuelle Netze in einem Cluster. Proxmox führt alle Netzdefinitionen zentral im Datacenter und verteilt die Konfiguration automatisch auf die Clusterknoten. Dadurch verwenden VMs und Container auf allen Hosts identische Netzstrukturen. Der Vorteil liegt in einer klaren Trennung von physischer Verkabelung und logischem Netzdesign. Administratoren verlieren dadurch weniger Zeit mit der Einzelfallpflege von Bridge-Dateien und behalten gleichzeitig eine konsistente Umgebung, in der Migrationen ohne Anpassungen der Gäste funktionieren.
Am Anfang steht eine funktionierende Clusterstruktur. Die Netzfunktionen von SDN liegen als Konfigurationsdateien unter /etc/pve/sdn und greifen auf den Linux-Netzstack zu. Proxmox verarbeitet die dort hinterlegten Vorgaben und überträgt sämtliche Einstellungen an die jeweiligen Knoten. Die Arbeitsweise ähnelt einem Kontrollzentrum, das konkrete Bridge-Interfaces erzeugt und die DHCP- sowie Routing-Komponenten auf jedem Host sauber zusammensetzt.
SDN auf Proxmox vorbereiten
Proxmox bringt viele SDN-Funktionen bereits seit Version 8.1 mit. Ein kurzer Blick in die Shell schafft Klarheit, ob die Grundlagen passen. Der Zugriff auf die Shell lässt sich mit der Weboberfläche starten und natürlich auch mit SSH. Das geht auch von Windows-Arbeitsstationen mit Windows 11 aus, da hier SSH bereits vorinstalliert ist. Der Administrator öffnet die Konsole auf einem Host und ruft apt update auf. Die Aktualisierung sorgt dafür, dass die Paketlisten korrekt vorliegen. Ein anschließender Aufruf von apt install libpve-network-perl stellt sicher, dass die Netzkomponenten für SDN aktiv sind. Diese Bibliothek ergänzt die Integration zwischen Proxmox und den Linux-Netzwerk-Tools. Eine weitere Kontrolle betrifft die Datei /etc/network/interfaces. Die Zeile source /etc/network/interfaces.d/* muss am Ende stehen, damit Proxmox alle automatisch erzeugten SDN-Fragmente in die aktive Netzstruktur einbindet. Ohne diese Zeile ignoriert das System die SDN-Definitionen.
DHCP und dnsmasq im SDN
Für DHCP verwendet Proxmox dnsmasq. daher ist die Installation von dnsmasq auf den Hosts sinnvoll. In Proxmox übernimmt dnsmasq die Ausgabe der DHCP-Leases und nutzt dafür die Vorgaben des internen IP-Adressmanagements. Die Software arbeitet leichtgewichtig, reagiert schnell und passt gut zu isolierten SDN-Netzen im Cluster. Proxmox bindet dnsmasq zonenweise ein und verwaltet alle zugehörigen Konfigurationsdateien selbst, sodass jede Zone einen klar definierten Adressraum erhält und VMs sowie Container konsistente, gültige IP-Adressen beziehen.
Durch diese Einbindung erhält das SDN-Modell eine stabile Grundlage für automatisierte Adressvergabe. Jede Zone folgt dadurch einer klaren Struktur, in der das Gateway, die gültigen Bereiche und alle DHCP-Pools exakt zu den Vorgaben des Subnetzes passen. Die Zuordnung zwischen MAC-Adresse und Lease bleibt nachvollziehbar, die Konfiguration bleibt auf allen Knoten identisch und der Cluster vergibt Adressen ohne Abweichungen. Zugleich ermöglicht diese Architektur eine Trennung der Netze, da jeder DHCP-Dienst ausschließlich auf die Zone zugreift, der er zugewiesen ist. Dadurch behalten LXC-Container und VMs in allen SDN-Bereichen eine zuverlässige Startumgebung, unabhängig davon, auf welchem Knoten sie laufen.
Der Befehl apt install dnsmasq lädt das Paket, anschließend deaktiviert systemctl disable dnsmasq die Standardinstanz, da Proxmox eigens konstruierte dnsmasq-Dienste pro Zone erzeugt. Diese Vorgehensweise gibt Proxmox die volle Kontrolle über die DHCP-Konfigurationen.
Routing mit FRRouting im SDN
Eine SDN-Struktur profitiert von klaren Routingfunktionen. Proxmox nutzt dafür FRRouting, ein flexibles Routingframework, das BGP und OSPF bereitstellt und damit komplexe Topologien im Cluster unterstützt. Die Software liest die SDN-Definitionen aus dem Proxmox-Konfigurationsbaum und setzt sie in konkrete Routingtabellen um. So bleibt die Kommunikation zwischen VNets nachvollziehbar und stabil, auch wenn mehrere Knoten beteiligt sind oder ein Overlay wie VXLAN oder EVPN im Einsatz ist.
FRRouting ergänzt dnsmasq an der Stelle, an der reine Adressvergabe nicht mehr ausreicht. Es kontrolliert die Wege zwischen den Netzen und sorgt dafür, dass jeder Knoten identische Entscheidungen trifft. Dadurch laufen VM- und LXC-Verbindungen sauber durch den Cluster und jede Zone erhält ein konsistentes Verhalten, unabhängig vom Standort des Gastes.
Die Installation erfolgt mit apt install frr-pythontools. Dieser Schritt fügt die BGP- und OSPF-Werkzeuge hinzu, die später in einer EVPN-Zone zum Einsatz kommen. Anschließend aktiviert systemctl enable frr.service den Routingdienst. Mit diesen Vorbereitungen besitzt der Cluster eine vollständige SDN-Grundlage.
Proxmox bietet mehrere Zonen im SDN an
Proxmox bietet am Anfang mehrere Zonentypen an. Jede Zone bildet eine Methode zur Isolation und zum Transport von Paketen. Simple trennt Netzbereiche voneinander ab und erlaubt SNAT (Source Network Address Translation). VLAN nutzt ein einzelnes Tag und bindet dadurch reale Switches in die Struktur ein. QinQ setzt zwei Tags übereinander. VXLAN kapselt Layer-2-Pakete über UDP ein. EVPN verbindet VXLAN mit BGP und schafft ein dynamisches Routing im Cluster. Die Konfiguration erfolgt in der Weboberfläche im Bereich Datacenter/SDN
Erstellen eines neuen SDN in einer Testumgebung
Um den praktischen Ablauf zu zeigen, legen wir zuerst eine Simple-Zone an. Diese Zone eignet sich für interne Testnetze und Netze ohne Durchgriff auf reale Switches. Die Navigation führt inDatacenter zur Unterseite SDN und weiter zum Abschnitt Zones (Abbildung2). Ein Klick auf Add öffnet das Dialogfenster. Als Namen verwenden wir in diesem Beispiel sdnzone und setzen IPAM auf pve. Diese Einstellung aktiviert die interne Proxmox-Adressverwaltung. Durch den Haken bei Automatic DHCP verteilt der Cluster später Adressen über dnsmasq.
Nach dem Speichern erfolgt die weitere Konfiguration bei VNets. Über Create wird ein neues VNet erstellt. Als Namen kommt sdnet zum Einsatz, als Zone wird die bereits erstellte Zone sdnzone ausgewählt. Ein VNet bildet die logische Bridge, an die VMs und Container andocken. Proxmox erzeugt später den anderen Knoten im Cluster identische Interfaces mit der Bezeichnung sdnet und legt die Eigenschaften der Zone zugrunde.
Ein Subnetz ergänzt die Zone an der Stelle, an der Proxmox die IP-Bereiche für ein VNet verwaltet. Die Einstellung liegt im Datacenter unter SDN im Abschnitt VNets. Nach dem Anlegen des VNets wählt man den Eintrag aus, öffnet die Detailansicht und fügt über den Bereich Subnets im rechten Fenster im Punkt Create einen neuen Bereich hinzu. Dort lassen sich CIDR, Gateway, DHCP-Bereich und SNAT definieren.
In diesem Aufbau liegt der interne Bereich bei 10.0.10.0/24, passend zum übergeordneten Netz 10.0.0.0/16. Das Gateway sitzt auf 10.0.10.1. Für die automatische Vergabe bietet sich ein Pool von 10.0.10.100 bis 10.0.10.200 an. SNAT leitet den Datenverkehr dieser Zone über die reale Adresse des jeweiligen Hosts nach außen und öffnet damit den Zugang zum Internet, ohne dass zusätzliche Routen notwendig sind.
Das Dialogfenster für ein neues Subnetz fasst alle Angaben zusammen, die Proxmox für ein funktionierendes SDN-Segment benötigt.
Der Eintrag Subnet legt den vollständigen Adressraum fest, den das VNet nutzt. Die Angabe erfolgt im CIDR-Format. Proxmox ordnet alle späteren DHCP-Leases und statischen Adressen exakt diesem Bereich zu. Ohne einen gültigen Bereich kann das VNet keine gültigen Konfigurationen an Gäste ausgeben.
Die Gateway-Adresse verweist auf den Zugangspunkt des Subnetzes. Proxmox setzt diese IP innerhalb der Bridge des VNets ein. Gäste richten ihre Routen auf diese Adresse aus. In SDN-Zonen mit NAT oder Routing stellt die IP die Verbindung in Richtung physisches Netz her.
Die Option SNAT aktiviert die Quelladressübersetzung für den ausgehenden Verkehr aus diesem Subnetz. Proxmox ersetzt in diesem Fall die interne Absenderadresse eines Gastes durch die reale IP des Hosts. Container und VMs erreichen dadurch externe Netze ohne eigene Routen. Für isolierte Testumgebungen oder interne Service-Netze ist das oft der einfachste Weg.
Die Zeile DNS Zone Prefix ergänzt Host-Namen beim Eintrag in ein externes DNS-System. SDN kann Namen und Adressen automatisch an einen DNS-Server weitergeben. Ein Prefix erweitert den Namen jedes Eintrags in diesem Subnetz um eine zusätzliche Ebene. Ein Container mit dem Namen ct10 lässt sich dadurch im DNS als ct10.prefix.domain auflösen. So entsteht eine klare Zuordnung zwischen Netzbereichen und DNS-Strukturen. Ein Prefix eignet sich für größere Umgebungen mit vielen VNets und steigert die Übersicht, weil sich jeder Eintrag sofort einem bestimmten Subnetz zuordnen lässt.
Anschließend legt Proxmox die Bridge sdnet auf den anderen Knoten im Cluster an, hinterlegt die DHCP-Dateien und bindet das definierte Gateway auf jedem Knoten ein. Nach dem Speichern zeigt Proxmox alle neuen Einträge als an. Ein Klick auf Apply im SDN-Hauptfenster setzt die Konfiguration aktiv. Dabei legt Proxmox die Bridge sdnet auf allen Knoten an, hinterlegt die zugehörigen DHCP-Dateien und richtet das definierte Gateway auf jedem Knoten ein.
SDN-Bridges prüfen und verstehen
Die neue Bridge lässt sich zum Beispiel auf dem ersten Knoten in der Shell oder per SSH prüfen:
ip link show sdnet
Eine Simple-Zone besitzt keinen physischen Uplink, Proxmox legt die Bridge daher erst an, wenn sie tatsächlich gebraucht wird. Sie können beim Einsatz einer Simple Zone im Terminal überprüfen, ob die Konfiguration hinterlegt wurde. Das geht mit:
cat /etc/network/interfaces.d/sdn
Die Ausgabe listet die Bridge mit einer eindeutigen Kennung. Proxmox koppelt das Interface nicht an eine reale Netzwerkkarte, da Simple-Zonen als reine Logiknetze laufen. LXC-Container und VMs erhalten trotzdem Zugriff, da die Bridge intern Pakete annimmt, weiterleitet und über SNAT ausgibt.
Für den ersten Praxistest kann man einen Container anlegen. Im Netzwerkteil des Assistenten wird in diesem Beispiel sdnet als Bridge ausgewählt und die Adresskonfiguration auf DHCP gesetzt. Der Container startet und bezieht sofort eine IP aus dem Bereich. Die Shell liefert die Details. Wir gehen nachfolgend von der ID 100 für den Container aus. Die Prüfung kann ebenfalls in der Shell erfolgen:
pct exec 100 -- ip a
Die Ausgabe im Container zeigt eine Adresse aus dem Bereich 10.0.10.0/24. Auf einem anderen Host im Cluster folgt ein weiterer Container mit derselben Bridge. Auch dieser Gast erhält eine Adresse aus dem definierten DHCP-Pool. Ein kurzer Test zeigt die interne Verbindung, indem Sie die IP-Adresse des anderen Containers anpingen.
pct exec 100 -- ping -c 3 10.0.10.101
Die Antwort kommt sofort zurück und bestätigt die funktionierende Kommunikation innerhalb der Simple-Zone. Ein externer Ping aus dem Container zeigt zusätzlich, dass SNAT aktiv arbeitet.
pct exec 100 -- ping -c 3 1.1.1.1
Die Rückmeldung zeigt den Zugang über das Gateway 10.0.10.1.
Dieses Prinzip gilt auch für VMs. Als Test wählt man beim Erstellen einer VM ebenfalls sdnet aus und setzt eine statische Adresse im Gast. Die Konfiguration im VM-System sieht zum Beispiel so aus:
auto eth0
iface eth0 inet static
address 10.0.10.20/24
gateway 10.0.10.1
Die VM kommuniziert nun ebenfalls mit allen Containern und erreicht das Internet.
VLANs und VXLAN im SDN nutzen
Ein Cluster benötigt oft mehr als isolierte Testnetze. Produktive Netze liegen häufig auf VLANs. Proxmox bildet VLANs in einer eigenen Zone ab und bindet die VLAN-Tags an vmbr0. Legt man eine VLAN-Zone mit der Bezeichnung vlanzone an, kann vmbr0 in diesem Beispiel als Bridge dienen. Ein VNet nutzt Tag 110 und verknüpft die VLAN-Struktur mit dem Cluster. Der Administrator erzeugt das VNet vlan110 und weist vlanzone zu. Das lässt sich auf den Hosts auch prüfen:
ip -d link show vlan110
Die Ausgabe zeigt Details zum Tag 110. Gäste in vlan110 können über alle Proxmox-Server hinweg miteinander kommunizieren.
VLANs reichen in vielen Umgebungen nicht aus. Manche Strukturen benötigen Overlay-Netze. Ein VXLAN sitzt auf UDP und kapselt Layer-2-Pakete. Proxmox bildet diese Struktur als VXLAN-Zone ab. Auch diese Einstellungen finden sich im Bereich Datacenter/SDN. Hier lässt sich zum Beispiel eine Zone mit der Bezeichnung vxlab anlegen und die Cluster-Adressen der Proxmox-Knoten in die Peer-Liste eintragen.
Ein VNet mit der Bezeichnung vx100 nutzt die Zone. Der Administrator vergibt den VXLAN-Tag 100000 und klickt auf Apply. Jetzt transportiert vx100 den Verkehr über ein Overlay. Gäste benötigen eine reduzierte MTU:
auto eth0
iface eth0 inet static
address 10.0.60.10/24
mtu 1450
Ein Ping zwischen den Knoten bestätigt die Verbindung innerhalb dieses Overlay-Netzes.
Erweitertes Routing im SDN
Für erweitertes Routing setzt Proxmox auf EVPN. Das Routing-Framework FRRouting liefert dafür die nötigen BGP-Funktionen und verarbeitet die Angaben aus der SDN-Konfiguration. Ein EVPN-Controller bündelt die Parameter, die alle drei Knoten nutzen. Die AS-Nummer 65000 passt gut in eine interne Umgebung. Als Peers dienen die Knoten im Proxmox-Cluster
Nach dem Einrichten des Controllers folgt die Zone für das EVPN-Netz. Als Name eignet sich evpnzone, als VRF-VXLAN-Tag der Wert 9000. Die Cluster-Knoten dienen als Exit-Knoten und übernehmen damit die Verbindung zum physischen Netz. Die Knoten kündigen die relevanten Routen an und nehmen Datenverkehr aus den VNets entgegen.
Ein VNet mit der Bezeichnung evpn100 nutzt die Zone und führt die VXLAN-ID 9100. Das Subnetz liegt bei 10.0.70.0/24. Der Gatewaypunkt liegt auf 10.0.70.1. Eine VM im EVPN-Netz nutzt eine statische Konfiguration, die sich an die Vorgaben des VNets hält:
auto eth0
iface eth0 inet static
address 10.0.70.50/24
gateway 10.0.70.1
mtu 1450
Der Datenverkehr fließt über die Knoten in das reale Netz. Die Server nutzen identische Routinginformationen und leiten den Verkehr entsprechend der EVPN-Regeln von FRRouting zuverlässig in das physische Netz. Die Entscheidung läuft innerhalb des EVPN-Routings und folgt den BGP-Regeln, die FRRouting auf allen Knoten verwaltet.
Die Firewall des Clusters nutzt die SDN-Daten direkt. Proxmox erzeugt für jedes VNet eigene IP-Sets, die die Adressräume und Gateway-Punkte bündeln. vnet-all enthält die Adressbereiche eines VNets, vnet-gateway fasst die Gateway-IPs zusammen und vnet-dhcp bildet die DHCP-Segmente ab. Diese Sets passen sich automatisch an Veränderungen im Subnetz an und erleichtern den Aufbau klarer Regeln, ohne dass zusätzliche Listen nötig sind.
Durch die enge Verzahnung von VNets, Zonen, DHCP, Routing und Firewall erhält der Cluster eine nachvollziehbare Netzarchitektur. Alle Knoten greifen auf dieselben Vorgaben zu und verarbeiten die SDN-Einstellungen konsistent. Dadurch bleibt die Umgebung übersichtlich, stabil und gut steuerbar, selbst wenn VMs und Container häufig zwischen den Servern wechseln.
