Proxmox SDN: VXLAN und EVPN für die Mandantentrennung

/01Was Proxmox SDN ist und was es nicht ist

Proxmox SDN ist die Netzwerkverwaltung auf Cluster-Ebene: Sie legen im Rechenzentrums-Knoten der Oberfläche Zonen und virtuelle Netze (VNets) an, und Proxmox VE erzeugt daraus auf jedem Knoten die passenden Linux-Bridges, VLAN-Interfaces, VXLAN-Tunnel oder FRRouting-Konfigurationen. Die Definition liegt in /etc/pve/sdn und wandert über das Cluster-Dateisystem auf alle Knoten. Ein VNet heißt auf jedem Knoten gleich, und eine VM, die daran hängt, findet ihr Netz nach der Migration wieder.

Was SDN nicht ist: ein Ersatz für die physische Verkabelung, für den Switch oder für die Firewall am Übergang ins Internet. Proxmox setzt nach eigener Aussage so weit wie möglich auf Standard-Linux-Netzwerkfunktionen, es gibt keinen eigenen virtuellen Switch und keinen zentralen Controller-Dienst. Für die Overlay-Zonen VXLAN und EVPN müssen Sie das Trägernetz zwischen den Knoten selbst bereitstellen, mit UDP-Erreichbarkeit auf Port 4789 und ausreichender MTU. SDN nimmt Ihnen die Konfiguration auf den Knoten ab, nicht das Netzdesign.

Der Reifegrad ist geteilt, und Proxmox schreibt das in die Doku: Das Kern-SDN mit Zonen und VNets ist voll unterstützt. IPAM einschließlich DHCP für Gäste sowie die Routing-Integration über FRRouting und die Controller gelten mit Stand 9.2 als Tech Preview. Wer EVPN produktiv fährt, fährt also einen Teil der Plattform, den der Hersteller noch nicht in die volle Unterstützung entlassen hat. Das ist kein Ausschlusskriterium, aber ein Punkt für die Risikobewertung.

/02Fünf Zonentypen, drei davon brauchen Sie selten

Eine Zone definiert, mit welcher Technik der Verkehr getrennt wird. Sie lässt sich auf bestimmte Knoten beschränken und mit Berechtigungen versehen, so dass ein Nutzer nur die VNets seiner Zone sieht. Für den Alltag im Mittelstand zählen zwei Typen: VLAN und EVPN. Die übrigen drei haben ihren Platz, aber selten in einem Kundencluster.

Die Simple-Zone ist wichtiger, als der Name vermuten lässt: Sie ist die einzige, für die Proxmox mit Stand 9.2 automatisches DHCP über dnsmasq bereitstellt. Für schnelle Testnetze mit NAT über den Knoten ist sie deshalb die bequemste Wahl. Über die Knotengrenze kommt sie nicht.

/03VNets, Subnetze, IPAM und DHCP

Ein VNet ist die Bridge, an die Sie die Netzwerkkarte einer VM oder eines Containers hängen. Der Name darf höchstens acht Zeichen lang sein, weil er als Linux-Interface auftaucht. Je nach Zone trägt das VNet ein Tag (VLAN-ID oder VXLAN Network Identifier), kann VLAN-aware sein, damit der Gast selbst weitere Tags setzt, und kann seit Proxmox VE 8.3 mit „Isolate Ports" verhindern, dass Gäste auf demselben Knoten direkt miteinander sprechen.

Subnetze beschreiben den Adressraum eines VNets in CIDR-Schreibweise. In den Layer-3-Zonen Simple und EVPN wird das Gateway direkt auf dem VNet konfiguriert, in EVPN als Anycast-Adresse, die auf jedem Knoten gleich ist. Eine VM nutzt also immer das Gateway auf dem Knoten, auf dem sie gerade läuft, und behält es bei der Live-Migration. SNAT auf Subnetz-Ebene lässt Gäste über die Adresse des Knotens nach außen; in EVPN übernehmen das die Exit Nodes.

IPAM verwaltet die Adressen: Der eingebaute Plugin „pve" führt Buch in einer Statusdatei im Cluster-Dateisystem, alternativ binden Sie NetBox oder phpIPAM über deren API an. Das DHCP setzt darauf auf. Beim Anlegen einer Netzwerkkarte reserviert Proxmox eine Adresse im IPAM, beim Start des Gastes landet die Zuordnung aus MAC und IP in einer dnsmasq-Instanz je Zone, die als Dienst dnsmasq@<zone> läuft und ihre Leases unter /var/lib/misc/dnsmasq.<zone>.leases ablegt. Die Standard-Instanz von dnsmasq muss nach der Installation abgeschaltet werden, sonst kollidieren beide. DHCP-Bereiche setzen Sie in der Oberfläche oder per Kommandozeile:

pvesh set /cluster/sdn/vnets/kunde-a/subnets/kunde-a-10.20.1.0-24 \
    -dhcp-range start-address=10.20.1.100,end-address=10.20.1.199

In der Praxis bleibt das IPAM bei uns die Referenz für die Firewall-Regeln (dazu in /07 mehr) und weniger die Quelle für DHCP. Für Kundennetze in VLAN- oder EVPN-Zonen kommt das DHCP ohnehin aus der Firewall oder dem Domänencontroller des Kunden, weil Proxmox das automatische DHCP dort noch nicht anbietet.

/04Wann ein VLAN genügt

Die VLAN-Zone ist SDN ohne Overlay: Proxmox legt für jedes VNet ein VLAN-Interface auf der angegebenen Bridge an, meist vmbr0, und die Trennung erledigt der Switch, wie er es seit zwanzig Jahren tut. Kein Controller und kein Tunnel, und jeder Netzwerker im Haus versteht, was passiert. Gegenüber dem händischen Eintragen der VLAN-ID an jeder VM gewinnen Sie drei Dinge: einen sprechenden Namen statt einer Zahl, Berechtigungen auf Zonenebene und eine Konfiguration, die auf allen Knoten identisch ist.

Das genügt, solange drei Bedingungen gelten. Alle Knoten hängen am selben Switch-Verbund, so dass jedes VLAN überall als Trunk ankommt. Die Zahl der Netze bleibt im Rahmen dessen, was Sie auf dem Switch pflegen wollen; der Standard erlaubt 4094 IDs, die Pflege wird lange vorher unhandlich. Und das Routing zwischen den Netzen darf zentral auf der Firewall stattfinden, mit dem Umweg über den Switch, den das mit sich bringt.

Für einen Cluster mit drei bis fünf Knoten im Rechenzentrum in Coburg, einer OPNsense davor und einem Dutzend Netzen ist das der Normalfall. Wir bauen dort VLAN-Zonen und keine EVPN-Zonen, obwohl EVPN technisch reizvoller ist. Die Fehlersuche um drei Uhr nachts entscheidet, nicht das Datenblatt.

/05Wann VXLAN und EVPN nötig werden

Die Grenze der VLAN-Zone ist der Switch-Verbund. Sobald Knoten an verschiedenen Standorten stehen oder ein Netz zwischen Clustern gespannt werden soll, endet das VLAN am Router, und ein Overlay muss den Layer 2 über das geroutete Netz tragen. Genau das tut VXLAN: Es packt Ethernet-Frames in UDP-Pakete und stellt sie beim Peer wieder zu. Proxmox braucht dafür nur die Liste der Peer-Adressen oder seit 9.0 eine Fabric, die diese Liste selbst erzeugt.

VXLAN allein ist aber nur ein flaches Layer-2-Netz mit Flooding. Es lernt MAC-Adressen wie ein Switch, kennt kein Routing und trennt nichts außer dem, was die VNI trennt. Für zwei Rechenzentren mit einem gemeinsamen Verwaltungsnetz reicht das. Für Mandanten reicht es nicht, denn dort geht es um mehr als Trennung auf Layer 2: Jeder Mandant braucht eigene Subnetze, ein eigenes Gateway, eigenes Routing zwischen seinen Netzen und einen definierten Ausgang ins physische Netz, ohne dass sich Adressräume der Mandanten in die Quere kommen.

Das ist die Aufgabe der EVPN-Zone. Sie legt je Zone eine VRF an, also eine eigene Routingtabelle, verbindet die VNets der Zone darin über eine Transit-VNI und verteilt MAC- und IP-Adressen über BGP statt über Flooding. Zwei Mandanten, beide mit 10.0.1.0/24, laufen in zwei Zonen nebeneinander, ohne sich zu sehen. Die Exit Nodes kündigen der Zone eine Default-Route an und leiten den Verkehr ins reale Netz; über rt-import lassen sich Route Targets fremder EVPN-Netze einbinden, was Proxmox für die Kopplung von Rechenzentren vorsieht. Seit 9.2 darf ein Cluster mehrere EVPN-Controller tragen, und die Peers dürfen IPv6-Adressen sein.

Für die Kopplung Coburg und Neustadt heißt das: Das Trägernetz zwischen den Standorten bleibt geroutet, ein VXLAN-Tunnel braucht keine Layer-2-Strecke zwischen den Häusern. Proxmox schreibt dazu einen Satz, den man nicht überlesen darf: VXLAN verschlüsselt nichts. Zwischen zwei Standorten gehört darunter ein Site-to-Site-VPN, entweder ein bestehender IPsec-Tunnel der Firewalls oder seit Proxmox VE 9.2 eine Wire­Guard-Fabric, die Proxmox selbst aufbaut und deren Schlüssel es im Cluster verwaltet. Die Ceph-Replikation und das Corosync-Netz laufen davon getrennt; wie empfindlich Corosync auf geteilte Leitungen reagiert, haben wir im Beitrag über nächtliche Cluster-Neustarts beschrieben.

/06Eine EVPN-Zone, wie sie in /etc/pve/sdn steht

Die Oberfläche schreibt vier Dateien, und es lohnt sich, sie einmal gelesen zu haben: controllers.cfg, zones.cfg, vnets.cfg und subnets.cfg. Dazu kommen .running-config und .version, über die Proxmox den ausgerollten Stand verfolgt. Änderungen sind zunächst nur „pending" und werden erst mit dem Knopf „Apply" in der SDN-Übersicht auf alle Knoten übernommen, als ein atomarer Schritt. Ein Cluster mit drei Knoten, Controller, einer Zone für einen Mandanten und zwei VNets sieht so aus:

# /etc/pve/sdn/controllers.cfg
evpn: evpnctl
        asn 65000
        peers 10.10.0.11,10.10.0.12,10.10.0.13

# /etc/pve/sdn/zones.cfg
evpn: kundea
        controller evpnctl
        vrf-vxlan 10000
        exitnodes pve01,pve02
        exitnodes-primary pve01
        advertise-subnets 1
        ipam pve
        mtu 1450

# /etc/pve/sdn/vnets.cfg
vnet: kalan
        alias kunde-a-lan
        zone kundea
        tag 11000

vnet: kadmz
        zone kundea
        tag 12000

# /etc/pve/sdn/subnets.cfg
subnet: kundea-10.20.1.0-24
        vnet kalan
        gateway 10.20.1.1

subnet: kundea-10.20.2.0-24
        vnet kadmz
        gateway 10.20.2.1

Zu den Werten: Die ASN 65000 liegt im privaten Bereich 64512 bis 65534, den Proxmox ausdrücklich empfiehlt, damit niemand aus Versehen globales Routing stört. Alle EVPN-Controller eines Knotens müssen dieselbe ASN tragen. Die Transit-VNI 10000 der VRF muss sich von den VNet-Tags unterscheiden; die VNI ist 24 Bit breit, FRRouting erlaubt Werte von 1 bis 16777215. Der zweite Exit Node ist die Redundanz, der primäre erzwingt den Weg über einen Knoten, was nötig wird, sobald SNAT im Spiel ist oder der Router davor kein ECMP kann. Und advertise-subnets kündigt das ganze Subnetz an, damit auch stille Gäste erreichbar sind, deren Adressen das Anycast-Gateway noch nie gesehen hat.

Vorher müssen auf jedem Knoten frr-pythontools installiert und frr.service aktiviert sein, und in /etc/network/interfaces muss die Zeile source /etc/network/interfaces.d/* stehen, sonst bleibt die erzeugte Konfiguration wirkungslos. Beim Apply generiert Proxmox aus den Controllern /etc/frr/frr.conf; eigene Ergänzungen gehören nach /etc/frr/frr.conf.local, das angehängt wird. Ein von Hand editiertes frr.conf überlebt den nächsten Apply nicht. Seit 9.2 gibt es einen Dry-Run, der die Unterschiede zwischen laufender und anstehender FRR- und Interface-Konfiguration zeigt, bevor etwas passiert.

Wer mehr als einen Exit Node betreibt, setzt außerdem rp_filter auf null, weil Pakete an einem Knoten ankommen und über den anderen hinausgehen können. Proxmox nennt dafür eine Drop-in-Datei unter /etc/sysctl.d/. Ohne diesen Schritt läuft die Zone scheinbar, verliert aber asymmetrisch gerouteten Verkehr.

/07Zusammenspiel mit der Proxmox-Firewall

Trennung ohne Regelwerk ist die halbe Miete. Seit Proxmox VE 8.3 vom 21. November 2024 greifen SDN und Firewall ineinander: Für jedes VNet erzeugt die Firewall automatisch IPsets im SDN-Bereich, nämlich vnet-all mit allen Subnetzen, vnet-gateway mit den Gateway-Adressen, vnet-no-gateway mit den Subnetzen ohne Gateways und vnet-dhcp mit den DHCP-Bereichen. Für jeden Gast mit Einträgen im PVE-IPAM kommt ein guest-ipam-<vmid> dazu. Ändern Sie ein Subnetz, wandern die Sets mit; die Regeln bleiben stehen.

Damit lassen sich Mandantenregeln schreiben, ohne Adressen zu wiederholen: Erlaubt ist Verkehr aus kalan zum Gateway und zurück, alles andere im VNet wird verworfen. Diese Regel auf VNet-Ebene mit der Richtung „forward" gibt es allerdings nur mit der nftables-basierten Firewall, die seit 8.2 als Tech Preview neben der klassischen iptables-Firewall steht und pro Knoten eingeschaltet wird. Die Roadmap führt ihren Ausbau zur Produktionsreife als offenes Ziel. Wer heute VNet-Firewalls einsetzt, sollte das wissen und die Regeln nach jedem größeren Update einmal gegenprüfen.

Die Port-Isolation am VNet ergänzt das auf dem einzelnen Knoten: Gäste dürfen dann nur noch mit der Bridge selbst sprechen, nicht untereinander. Proxmox weist darauf hin, dass diese Isolation lokal bleibt und die VNet-Firewall nötig ist, um sie über Knotengrenzen hinweg durchzusetzen. Für ein Kundennetz mit fünfzig Servern, die alle nur mit dem Gateway reden sollen, ist die Kombination aus Isolate Ports und einer Drop-Regel im VNet ein sauberes Zero-Trust-Segment, ohne dass eine physische Firewall jeden Frame anfassen muss.

/08Fallstricke: MTU, FRR, Migration, Fehlersuche

MTU

VXLAN kostet 50 Byte je Paket. Auf einem Trägernetz mit 1500 Byte MTU müssen die Gäste deshalb mit 1450 fahren, und zwar im Gast selbst, nicht nur am VNet. Proxmox setzt 1450 als Vorgabe der Zone, aber ein Windows-Server mit Standardwerten weiß davon nichts. Das Symptom ist tückisch: Ping geht, SSH-Login geht, große Dateien hängen. Liegt darunter noch IPsec, werden es 1370, weil Proxmox für die Verschlüsselung weitere 80 Byte bei IPv6 und 60 bei IPv4 rechnet. Der saubere Weg ist der umgekehrte: Jumbo Frames auf dem Trägernetz, dann bleiben die Gäste bei 1500. Das setzt voraus, dass jeder Switch und jeder Router auf der Strecke mitspielt, auch der zwischen den Standorten.

FRRouting

Der EVPN-Controller schreibt frr.conf, aber er betreibt FRR nicht. Ist der Dienst auf einem Knoten nicht aktiviert oder nach einem Update nicht wieder hochgekommen, fehlt dieser Knoten in der BGP-Sitzung, und VMs dort erreichen niemanden in der Zone. Ein zweiter Klassiker: Die VTEP-Adresse leitet Proxmox aus der Route zum ersten Peer ab. Kommt diese Route dynamisch aus einer Fabric und steht sie beim Apply noch nicht in der Kernel-Tabelle, wird die falsche Quelladresse eingetragen. Also erst die Fabric prüfen, dann den Controller anwenden.

Live-Migration

Eine Zone gilt nur auf den Knoten, die in ihrer Knotenliste stehen. Auf allen anderen existiert das VNet nicht, und eine Migration dorthin scheitert mit der Meldung, dass die Bridge fehlt. Das ist aus unserer Erfahrung die häufigste Ursache, wenn HA-Gruppen und Zonenlisten nicht deckungsgleich gepflegt sind. Bei EVPN kommt hinzu, dass nach der Migration der neue Knoten die MAC- und IP-Adresse der VM per BGP ankündigen muss; das dauert im Normalfall Sekundenbruchteile, bei gestörter BGP-Sitzung aber unbegrenzt. Wer Floating-IPs zwischen VMs verschiebt, etwa mit keepalived, schaltet außerdem die ARP/ND-Unterdrückung der Zone ab, sonst hält das Netz an der alten Zuordnung fest.

Fehlersuche

Der Blick von oben beginnt bei pvesh, der Blick in die Zone bei vtysh:

# Definierte Zonen und anstehende Änderungen
pvesh get /cluster/sdn/zones
pvesh get /cluster/sdn/dry-run

# Was auf diesem Knoten tatsächlich ausgerollt ist
pvesh get /nodes/pve01/sdn/zones/kundea/content

# BGP-Sitzungen zu den Peers, dann die EVPN-Routen
vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn route"

# Welche VNIs der Knoten kennt und welche MACs er darin gelernt hat
vtysh -c "show evpn vni"
vtysh -c "show evpn mac vni 11000"

# MTU und VXLAN-Parameter des erzeugten Interfaces
ip -d link show vxlan_kalan

Steht in show bgp summary ein Peer auf „Active" statt auf einer Zahl empfangener Präfixe, ist die Sitzung nicht aufgebaut; dann ist meist FRR auf der Gegenseite nicht aktiv oder die Peer-Adresse nicht erreichbar. Fehlt in show evpn mac vni die MAC einer VM, hat der Knoten sie nie angekündigt, und die Ursache liegt lokal. Seit Proxmox VE 9.1 zeigt auch die Oberfläche je EVPN-Zone die gelernten IPs und MACs und je Fabric Routen und Nachbarn, was die erste Runde der Fehlersuche ohne Konsole erlaubt.

/09Wann SDN die falsche Wahl ist

Nüchtern betrachtet lohnt sich das Overlay erst, wenn eine von drei Bedingungen erfüllt ist: Knoten an mehr als einem Standort, Mandanten mit überlappenden oder eigenverwalteten Adressräumen, oder Netze, die so häufig kommen und gehen, dass der Weg über den Switch-Administrator zum Engpass wird. Trifft nichts davon zu, ist EVPN eine zusätzliche Schicht mit eigener Fehlerklasse, die im Störungsfall jemanden braucht, der BGP lesen kann.

Konkret raten wir ab, wenn der Cluster aus drei bis fünf Knoten an einem Standort besteht und die Netze auf dem Switch bereits sauber getrennt sind. Dann ist die VLAN-Zone, oder schlicht die VLAN-ID an der VM, die richtige Antwort. Wir raten ebenfalls ab, wenn niemand im Haus FRRouting kennt und kein Dienstleister im Rücken steht; ein Tech-Preview-Bestandteil, den keiner warten kann, ist kein Fundament für Kundennetze. Und wir raten ab, wenn das Trägernetz zwischen den Standorten die MTU nicht hergibt und niemand sie ändern darf, denn dann leben Sie dauerhaft mit 1450 in jedem Gast und jedem Ticket, das daraus folgt.

Umgekehrt gibt es Fälle, in denen SDN die einzige praktikable Wahl ist: ein Cluster, der Kunden voneinander trennen muss, ohne für jeden ein eigenes VLAN durch fremde Switches zu ziehen; ein Ausweichstandort, an dem VMs mit unveränderter Adresse wieder anlaufen sollen; oder ein Betrieb, der Kubernetes-Knoten, Datenbanken und Verwaltungsnetz je Projekt sauber schneiden will. Dort bezahlen Sie die Komplexität einmal und sparen sie bei jedem weiteren Netz.

/10Häufige Fragen