Wann SDN sinnvoll ist – und wann es nur Komplexität hinzufügt
Für ein einzelnes VLAN reicht eine klassische Linux-Bridge mit VLAN-Tag völlig aus – dafür braucht es kein SDN. Proxmox SDN lohnt sich erst, wenn Netzwerke dynamisch pro Kunde/Projekt/Mandant entstehen sollen, wenn Overlay-Netzwerke über mehrere Standorte nötig sind (VXLAN), oder wenn Netzwerkkonfiguration zentral über die API statt manuell auf jedem Node gepflegt werden soll. Wer nur "VLAN 100 für Produktion, VLAN 200 für DMZ" braucht, ist mit einer normalen VLAN-Bridge schneller fertig und hat weniger, das kaputtgehen kann.
Proxmox SDN aktivieren
apt install -y libpve-network-perl
pvesh get /cluster/sdn
VLAN Zone und VNets
pvesh create /cluster/sdn/zones \
--zone vlan-zone --type vlan --bridge vmbr0
# Produktionsnetz VLAN 100
pvesh create /cluster/sdn/vnets \
--vnet vnet-prod --zone vlan-zone --tag 100
# DMZ VLAN 200
pvesh create /cluster/sdn/vnets \
--vnet vnet-dmz --zone vlan-zone --tag 200
pvesh set /cluster/sdn
Der letzte Befehl (pvesh set /cluster/sdn) ist kein Tippfehler und keine Formsache – ohne ihn bleibt die Konfiguration im "pending"-Zustand und wird nie tatsächlich angewendet. Das ist der häufigste Grund, warum frisch angelegte SDN-Zonen scheinbar nicht funktionieren.
VXLAN für Multi-Host-Overlays
VXLAN kapselt Layer-2-Traffic in UDP-Pakete und erlaubt so ein virtuelles Netzwerk, das über mehrere physische Hosts (auch über Standortgrenzen) gespannt wird, ohne dass die physische Netzwerk-Infrastruktur dazwischen VLANs durchreichen muss.
pvesh create /cluster/sdn/zones \
--zone vxlan-overlay --type vxlan \
--peers "192.168.1.10,192.168.1.11,192.168.1.12"
pvesh create /cluster/sdn/vnets \
--vnet vnet-overlay --zone vxlan-overlay --vlanid 1000
pvesh set /cluster/sdn
Wichtig für die Praxis: VXLAN erhöht die MTU-Anforderung (Encapsulation-Overhead, üblicherweise +50 Byte). Wird die MTU im physischen Netz nicht angepasst, kommt es zu schwer diagnostizierbaren Fragmentierungsproblemen bei größeren Paketen – Symptome sind oft "kleine Requests funktionieren, große Downloads brechen ab".
DHCP im SDN
pvesh create /cluster/sdn/vnets/vnet-prod/subnets \
--subnet 10.100.0.0/24 \
--gateway 10.100.0.1 \
--snat 1 \
--dhcp-range start-address=10.100.0.100,end-address=10.100.0.200
pvesh set /cluster/sdn
--snat 1 aktiviert Source-NAT für das Subnetz – VMs im VNet bekommen darüber Internetzugang über den Proxmox-Host, ohne dass jede VM eine öffentliche Route braucht. Für produktive Setups mit eigener Firewall/Router-VM sollte das bewusst deaktiviert bleiben, sonst gibt es zwei NAT-Punkte, die sich gegenseitig ins Gehege kommen.
VMs mit VNet verbinden
qm set 100 --net0 virtio,bridge=vnet-prod
pct set 200 --net0 name=eth0,bridge=vnet-prod,ip=dhcp
Wo SDN in der Praxis öfter Probleme macht als erwartet
EVPN-Zonen (für komplexere Multi-Node-Overlay-Szenarien) brauchen zusätzlich FRRouting als Routing-Daemon und eine sauber geplante BGP-Konfiguration – das ist kein Nachmittagsprojekt, sondern eigenständige Netzwerk-Architektur. Wer damit noch keine Erfahrung hat, sollte für den Einstieg bei VLAN- oder einfachen VXLAN-Zonen bleiben.
Fazit
Proxmox SDN vereinfacht Netzwerksegmentierung erheblich – aber erst ab einer gewissen Komplexität im Setup. Für simple Ein-Standort-VLANs ist es oft mehr Konfigurationsaufwand, als es einspart.
Als IT-Ingenieur aus Heidelberg übernehme ich Proxmox-Virtualisierung für Unternehmen in der Metropolregion Rhein-Neckar. Kontakt aufnehmen.