Proxmox SDN Cluster: VLAN Routing Best Practices für dein Homelab

Stell dir vor, du öffnest morgens dein Terminal und dein gesamtes Homelab-Netzwerk ist ein einziger großer Broadcast-Sturm. Jede VM redet mit jeder, jede LXC quatscht rein, und dein Raspberry Pi im Wohnzimmer fragt sich, warum die DNS-Auflösung drei Sekunden dauert. Du hattest VLANs eingerichtet — doch das Routing dazwischen hast du immer wieder aufgeschoben. Bis heute.

Dieser Artikel begleitet dich durch den Dschungel der VLAN-Routing-Architekturen in einem Proxmox-Cluster mit SDN. Du erfährst, welche Ansätze es gibt, wann du welchen wählst und wo die Fallstricke liegen, die dir in Foren niemand verrät.

Inhaltsverzeichnis

Warum VLAN-Routing im Cluster anders ist als auf einem Einzelhost
Proxmox SDN-Grundlagen: Simple Zone, VLAN Zone und VNets
Ansatz 1: Zentraler Router als VM — der Klassiker mit Tücken
Ansatz 2: Simple Zone Gateway — Routing im SDN-Stack
Ansatz 3: VLAN Zone mit Subnet-Gateways — verteilt und direkt
Ansatz 4: EVPN und VXLAN — wenn der Cluster wächst
Hochverfügbarkeit: Was passiert wenn ein Node ausfällt
Performance-Fallen und wie du sie vermeidest
Häufige Fragen (FAQ)
Fazit

Kurzantwort

Proxmox SDN im Cluster richtig konfigurieren: VLAN-Routing-Architekturen im Vergleich, vom Simple Zone Gateway bis zum verteilten EVPN-Routing. Praxisleitfaden mit konkreten Konfigurationsbeispielen. Kurz gesagt: ki tools praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Warum VLAN-Routing im Cluster anders ist als auf einem Einzelhost

Auf einem einzelnen Proxmox-Host ist die Sache überschaubar. Du erstellst einen Linux Bridge mit VLAN-Awareness, hängst deine VMs in die passenden VLANs, und der Rest passiert auf deinem physischen Switch oder Router. Der Hypervisor selbst muss sich um nichts kümmern — er tagged nur die Pakete.

Im Cluster ändert sich das schlagartig. Deine VMs und Container wandern via Live-Migration zwischen Nodes. Was passiert mit der VLAN-Konfiguration, wenn eine VM von Node A auf Node B zieht? Wie stellst du sicher, dass die Netzwerksegmentierung erhalten bleibt, ohne dass du auf jedem Node dieselben Bridges manuell pflegen musst?

Genau hier setzt das Proxmox SDN (Software Defined Networking) an. Es abstrahiert die Netzwerkkonfiguration von der physischen Infrastruktur und verteilt sie automatisch im gesamten Cluster. Du definierst einmal, wie deine Netze aussehen sollen — das SDN kümmert sich um die Umsetzung auf jedem Node.

Das klingt nach Magie, ist es aber nicht. SDN braucht klare Architekturentscheidungen. Eine der wichtigsten: Wer routet eigentlich den Traffic zwischen deinen VLANs?

Proxmox SDN-Grundlagen: Simple Zone, VLAN Zone und VNets

Bevor wir in die Routing-Architekturen einsteigen, müssen wir über die Bausteine sprechen. Das Proxmox SDN operiert mit drei zentralen Konzepten:

Zones sind die oberste Abstraktionsebene. Sie definieren, wie das zugrunde liegende Netzwerk technisch realisiert wird. Proxmox unterscheidet vier Zonentypen:

Simple Zone: Eine klassische Bridge auf jedem Cluster-Node. VMs innerhalb der Zone können kommunizieren, aber zwischen den Nodes brauchst du ein darunterliegendes Layer-2-Netz oder VXLAN.
VLAN Zone: Baut auf einer VLAN-fähigen Bridge auf und nutzt 802.1Q-Tagging. Das ist der direkte Draht zu deinen physischen Switches — VLAN-IDs werden eins zu eins durchgereicht.
VXLAN Zone: Kapselt Layer-2-Traffic in UDP-Pakete und tunnelt ihn über ein beliebiges Layer-3-Netzwerk. Ideal, wenn deine Nodes über geroutete Netze verbunden sind.
EVPN Zone: Kombiniert VXLAN mit BGP EVPN für skalierbare Multi-Tenant-Netzwerke mit verteiltem Routing.

VNets sind die logischen Netze innerhalb einer Zone. Du definierst hier Subnetze, Gateways und DHCP-Bereiche. Ein VNet ist das, woran du deine VMs anschließt — es fühlt sich für die VM an wie ein ganz normales Netzwerk, egal welche Zone darunter liegt.

Subnets innerhalb eines VNets definieren den IP-Adressraum und optional ein Gateway. Das Gateway ist der entscheidende Punkt: Wenn du hier eine IP-Adresse angibst, übernimmt das SDN automatisch das Routing für dieses Subnetz.

Die Kunst besteht nun darin, diese Bausteine so zu kombinieren, dass deine VLANs sinnvoll miteinander reden können — ohne Umwege, ohne Single Point of Failure und ohne dass du jeden Node einzeln konfigurieren musst.

ki tools praxis – Illustration 2

Ansatz 1: Zentraler Router als VM — der Klassiker mit Tücken

Der naheliegendste Gedanke — und der, den der Reddit-User in unserer Ausgangsfrage formuliert — ist eine pfSense- oder OPNsense-VM, die als zentraler Router für alle VLANs fungiert. Du erstellst eine VLAN-aware Bridge, hängst die Firewall-VM mit getaggten Interfaces an jedes VLAN und konfigurierst dort die Routing-Regeln.

Das funktioniert. Es ist sogar das, was viele erfahrene Homelab-Betreiber seit Jahren tun. Aber es hat eine strukturelle Schwäche, die im Cluster sofort schmerzhaft wird: Der gesamte Inter-VLAN-Traffic läuft über genau einen Node.

Stell dir das bildlich vor wie eine Autobahn, auf der alle Fahrzeuge durch eine einzige Mautstation müssen. Egal ob die Quelle in Frankfurt und das Ziel in München liegt — jedes Paket wird erst zum Router-Node geschickt, dort geroutet und dann zum Ziel-Node weitergeleitet. Wenn die pfSense-VM auf Node A läuft und deine Datenbank-VM auf Node C mit deinem Webserver auf Node B kommunizieren will, geht der Weg: Node C → Node A → Node B.

Die Konsequenzen:

Latenz steigt. Selbst bei 10-Gigabit-Verbindungen addiert jeder zusätzliche Hop eine spürbare Verzögerung.
Bandbreiten-Engpass. Der Router-Node muss den gesamten Inter-VLAN-Traffic verarbeiten. Seine Netzwerkkarte wird zum Nadelöhr.
Single Point of Failure. Fällt Node A aus, ist nicht nur der Router tot — alle VLAN-übergreifende Kommunikation bricht zusammen. Hochverfügbarkeit für die Router-VM selbst ist zwar mit CARP möglich, erhöht aber die Komplexität erheblich.
Migration wird zum Problem. Wenn du die Router-VM live migrieren willst, unterbrichst du während der Migration sämtlichen VLAN-Traffic.

Trotzdem hat dieser Ansatz seine Berechtigung, und zwar genau dann, wenn du Stateful Firewalling zwischen den VLANs brauchst. Wenn dein IoT-Netzwerk unter keinen Umständen ungefiltert mit deinem Server-Netzwerk kommunizieren darf, ist eine zentrale Firewall der richtige Weg. Aber für reines Layer-3-Routing ohne komplexe Filterregeln gibt es bessere Alternativen.

Ansatz 2: Simple Zone Gateway — Routing im SDN-Stack

Das SDN von Proxmox bietet eine elegante Alternative: Du lässt das Routing direkt im SDN-Stack erledigen, ohne externe Router-VM.

In einer Simple Zone definierst du ein VNet mit einem Subnet und einem Gateway:

Subnet: 10.0.10.0/24
Gateway: 10.0.10.1

Sobald du das Gateway setzt, erstellt Proxmox auf jedem Node, der an diesem VNet beteiligt ist, eine virtuelle Netzwerkschnittstelle mit der Gateway-IP. Wenn eine VM jetzt ein Paket an ein anderes Subnetz schicken will, wird es an die lokale Gateway-IP (10.0.10.1) gesendet. Der SDN-Stack auf demselben Node routet es dann weiter — kein Umweg über einen anderen Node.

Das ist der entscheidende Unterschied zum Router-VM-Ansatz: Das Routing passiert verteilt auf jedem Node. Eine VM auf Node B erreicht eine andere VM auf Node B direkt über das lokale Gateway. Die Daten verlassen den Node nie.

Aber die Simple Zone hat eine Einschränkung, die im VLAN-Kontext wichtig ist: Sie weiß nichts von VLAN-Tags. Wenn deine Infrastruktur auf physikalischen Switches mit 802.1Q-Tagging basiert, musst du entweder:

Die Simple Zone mit VXLAN unterfüttern (dann tunneln die Nodes den Traffic durch das physische Netzwerk), oder
Auf eine VLAN Zone wechseln, die das Tagging nativ unterstützt.

VXLAN in der Simple Zone ist übrigens ein mächtiges Werkzeug. Es entkoppelt deine virtuelle Netzwerktopologie komplett vom physischen Netzwerk. Deine Switches müssen nur ein IP-Netz bereitstellen — alles andere passiert in den Tunneln. Allerdings kostet VXLAN Overhead: Der UDP-Header und die zusätzliche Kapselung reduzieren die effektive MTU um etwa 50 Byte. Für Jumbo-Frame-Netzwerke kein Problem, für Standard-1500-MTU-Verbindungen etwas, das du im Auge behalten musst.

Ansatz 3: VLAN Zone mit Subnet-Gateways — verteilt und direkt

Wenn deine physischen Switches bereits VLANs managen und du diese Struktur eins zu eins im SDN abbilden willst, ist die VLAN Zone mit verteilten Subnet-Gateways der direkteste Weg.

So sieht die Konfiguration in der Proxmox-SDN-Web-Oberfläche oder via /etc/pve/sdn/ aus:

Eine VLAN Zone namens homelab-vlan wird auf einer VLAN-fähigen Bridge (zum Beispiel vmbr0vlan) erstellt. Innerhalb dieser Zone definierst du mehrere VNets, jedes mit einer VLAN-ID:

server-net: VLAN 10, Subnet 10.0.10.0/24, Gateway 10.0.10.1
iot-net: VLAN 20, Subnet 10.0.20.0/24, Gateway 10.0.20.1
guest-net: VLAN 30, Subnet 10.0.30.0/24, Gateway 10.0.30.1

Jedes VNet hat sein eigenes Gateway. Der entscheidende Punkt: Jeder Node, der an diesen VNets teilnimmt, bekommt alle drei Gateway-IPs lokal zugewiesen. Wenn die IoT-VM (VLAN 20) auf Node B deinen DNS-Server (VLAN 10) auf Node C erreichen will, passiert Folgendes:

Die IoT-VM schickt das Paket an ihr Default-Gateway: 10.0.20.1.
Dieses Gateway existiert lokal auf Node B im SDN-Stack.
Node B routet das Paket ins Ziel-Subnetz 10.0.10.0/24.
Das Ziel (DNS-Server) befindet sich auf Node C — also wird das Paket über das physische Netzwerk getaggt als VLAN 10 an Node C gesendet.

Der Umweg über einen zentralen Router entfällt. Das Routing findet auf dem Quell-Node statt.

Das ist die Architektur, die ich für die meisten Homelab-Cluster mit drei bis fünf Nodes empfehle. Sie verbindet die Klarheit von VLANs mit der Effizienz verteilten Routings. Der einzige Wermutstropfen: Du bekommst kein Stateful Firewalling auf dem Gateway. Wenn du ACLs oder Filter zwischen den VLANs brauchst, musst du die entweder separat konfigurieren (etwa mit Proxmox-eigenen Firewall-Regeln auf VM-Ebene) oder eine dedizierte Firewall-VM für die kritischen Übergänge einsetzen.

Ein wichtiges Detail: Das verteilte Routing funktioniert nur, wenn das SDN die Routen zwischen den Subnetzen kennt. In einer einfachen VLAN-Zone mit mehreren VNets im gleichen IP-Adressraum geschieht das automatisch. Sobald du jedoch separate IP-Bereiche oder externe Netze einbindest, brauchst du statische Routen oder ein Routing-Protokoll.

Ansatz 4: EVPN und VXLAN — wenn der Cluster wächst

Für Cluster jenseits der Fünf-Node-Marke oder für Setups, bei denen die Nodes über verschiedene physische Standorte verteilt sind, reichen Simple und VLAN Zones irgendwann nicht mehr aus. Hier kommt die EVPN Zone ins Spiel.

EVPN (Ethernet VPN) kombiniert VXLAN-Tunneling mit BGP als Control Plane. Anders als bei einer VLAN Zone, in der jeder Node alle VNets kennt, weil sie in der SDN-Konfiguration definiert sind, verteilt EVPN die Informationen dynamisch via BGP. Wenn ein neuer Node dem Cluster beitritt und ein bestimmtes VNet benötigt, bekommt er über BGP alle nötigen Informationen: Welche MAC-Adressen gibt es in diesem VNet, welche IP-Adressen sind wo erreichbar, und wie sehen die Routen zwischen den VNets aus.

Der große Vorteil: Anycast Gateway. In einer EVPN-Zone kannst du dasselbe Gateway in mehreren VNets auf jedem Node konfigurieren. Die Nodes sprechen sich über BGP ab und entscheiden gemeinsam, wer ein eingehendes Paket bearbeitet. Aus Sicht der VM existiert das Gateway auf jedem Node — und der tatsächliche Routing-Pfad wird automatisch optimiert.

Das ist Enterprise-Grade-Networking, das in Proxmox seit Version 8.x kontinuierlich ausgebaut wird. Für die meisten Homelabs ist das Overkill — aber wenn du ein verteiltes Setup mit mehreren Racks oder Standorten planst, ist EVPN die Architektur deiner Wahl.

Die Konfiguration erfordert einen BGP-Router (Proxmox bringt FRRouting mit) und ein grundlegendes Verständnis von BGP Autonomous Systems. Du definierst einen Route-Reflector, konfigurierst die EVPN-Fabric und definierst die VNets als Layer-3-VNIs. Der Lohn ist ein Netzwerk, das sich selbst organisiert und bei Node-Ausfällen automatisch umroutet.

ki tools praxis – Illustration 3

Hochverfügbarkeit: Was passiert wenn ein Node ausfällt

Netzwerk-Hochverfügbarkeit im Cluster ist kein Luxus — sie ist der Grund, warum du überhaupt einen Cluster betreibst. Schauen wir uns an, wie die verschiedenen Ansätze mit Node-Ausfällen umgehen.

Router-VM-Ansatz: Solange die Router-VM selbst hochverfügbar ist (etwa durch HA-Manager mit Replikation), ist das Routing abgesichert. Aber: Wenn der Node mit der aktiven Router-VM ausfällt, gibt es eine Umschaltzeit, während der HA-Manager die VM auf einem anderen Node startet. Das sind typischerweise ein bis zwei Minuten. In dieser Zeit steht jeglicher Inter-VLAN-Traffic still. Mit CARP auf der Router-VM selbst kannst du die Zeit auf wenige Sekunden reduzieren, aber der Konfigurationsaufwand ist nicht trivial.

Verteiltes Gateway (Simple/VLAN Zone): Hier liegt der Vorteil klar auf der Hand. Da das Routing auf jedem Node stattfindet, betrifft ein Node-Ausfall nur die VMs und Container auf diesem Node. Alle anderen Nodes routen unverändert weiter. Der Traffic zwischen den verbleibenden VMs fließt ohne Unterbrechung. Das ist der Goldstandard für homelab-typische Setups.

EVPN mit Anycast Gateway: Der König unter den HA-Architekturen. Fällt ein Node aus, übernehmen die verbleibenden Nodes nahtlos das Gateway für die betroffenen Subnetze. BGP erkennt den Ausfall und zieht die Routen innerhalb von Sekunden um. Deine VMs merken davon nichts — sie sprechen immer noch dieselbe Gateway-IP an, nur dass diese jetzt von einem anderen Node bedient wird.

Ein häufig übersehener Punkt bei allen SDN-Architekturen: Die SDN-Konfiguration selbst muss konsistent bleiben. Proxmox speichert sie in der Cluster-Dateisystem-Datenbank pmxcfs unter /etc/pve/. Das ist dasselbe verteilte Dateisystem, das auch die VM-Konfigurationen speichert. Solange dein Cluster-Quorum erhalten bleibt, ist die SDN-Konfiguration auf allen Nodes synchron. Fällt das Quorum, ändert sich nichts — aber du kannst auch keine Änderungen mehr vornehmen.

Performance-Fallen und wie du sie vermeidest

SDN ist kein Freifahrtschein für sorglose Performance. Hier sind die häufigsten Fallen, die ich in Foren und eigenen Setups gesehen habe:

MTU-Mismatch bei VXLAN. Wenn du VXLAN-Tunnel verwendest, wird jedes Paket um etwa 50 Byte größer (VXLAN-Header + UDP-Header + äußerer IP-Header). Deine Switches und Router auf dem Transportnetz müssen das verkraften. Lösung: Setze die MTU auf allen beteiligten Interfaces auf mindestens 1550 Byte, besser 9000 (Jumbo Frames). In der Proxmox-Web-Oberfläche findest du die MTU-Einstellung in der SDN-Zonen-Konfiguration.

Bridge-Learning und MAC-Flooding. Jeder Node in einer VLAN oder Simple Zone muss die MAC-Adressen aller VMs im Cluster kennen. Bei vielen VMs kann das die MAC-Tabelle der Bridge überlasten. Abhilfe: Erhöhe die MAC-Table-Größe oder wechsle zu VXLAN, wo die MACs im Tunnel gelernt werden.

CPU-Overhead durch Software-Routing. Im Gegensatz zu Hardware-Routern mit ASICs routet das Proxmox-SDN-Gateway in Software. Das ist für typische Homelab-Durchsätze (1-10 Gbit/s) völlig ausreichend, kann aber bei vielen parallelen Verbindungen CPU-Zeit fressen. Wenn du mehrere Hochgeschwindigkeits-Datenbanken zwischen VLANs betreibst, beobachte die CPU-Auslastung der Nodes und erwäge, diese Workloads im selben VLAN zu belassen.

Asymmetrisches Routing durch falsche Gateway-Konfiguration. Wenn du in einer VLAN Zone nicht auf allen Nodes dasselbe Gateway konfigurierst, können Pakete asymmetrische Pfade nehmen. Das ist für die meisten Protokolle unproblematisch, aber stateful Firewalls hassen asymmetrisches Routing. Lösung: Alle Nodes mit demselben VNet erhalten immer dieselbe Gateway-IP. Das SDN erledigt das automatisch, wenn du es korrekt konfigurierst — aber doppelt prüfen schadet nicht.

IGMP Snooping und Multicast. Wenn du Multicast-Anwendungen (etwa für Cluster-Heartbeats oder IPTV) betreibst, aktiviere IGMP Snooping auf deiner VLAN-Bridge. Ohne IGMP Snooping wird Multicast-Traffic wie Broadcast behandelt und an alle Ports geflutet. Das kann deine Netzwerk-Performance spürbar beeinträchtigen.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du ki tools praxis nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

Häufige Fragen (FAQ)

Brauche ich überhaupt SDN, wenn ich nur VLANs routen will?

Nein, für ein einfaches Setup mit einem oder zwei Nodes kannst du VLANs auch klassisch mit Linux Bridges und einem externen Router betreiben. SDN lohnt sich ab dem Moment, wo du Konfigurationen clusterweit synchron halten willst und keine Lust hast, auf jedem Node dieselben Bridges per Hand zu pflegen. Der Mehrwert kommt mit der Skalierung.

Kann ich SDN und manuelle Bridge-Konfiguration mischen?

Ja, das ist sogar der empfohlene Migrationspfad. Du betreibst dein bestehendes Setup manuell weiter und führst SDN Schritt für Schritt für neue Netze ein. Die SDN-VNets und manuelle Bridges können parallel existieren, solange sie nicht denselben Bridge-Namen verwenden.

Was ist der Unterschied zwischen VLAN Zone und VLAN-aware Bridge?

Eine VLAN-aware Bridge ist die technische Grundlage, auf die eine VLAN Zone aufsetzt. Die Bridge selbst macht nichts außer Pakete zu taggen und zu enttaggen. Die VLAN Zone bringt die SDN-Logik obendrauf: automatische Verteilung im Cluster, Gateway-Management, IPAM (IP Address Management). Du kannst eine VLAN-aware Bridge auch ohne SDN nutzen — dann musst du aber alle VNets und deren Subnetze manuell konfigurieren.

Wie viele VNets kann ich in einer VLAN Zone anlegen?

Technisch gibt es keine harte Grenze. Das 802.1Q-Protokoll erlaubt maximal 4094 VLAN-IDs. In der Praxis limitiert dich die Verwaltbarkeit — ab 20-30 VNets wird die Konfiguration unübersichtlich. Für sehr viele Subnetze ist eine EVPN Zone die bessere Wahl.

Unterstützt Proxmox SDN IPv6?

Ja, IPv6 wird in allen Zonentypen unterstützt. Du kannst in einem VNet sowohl IPv4- als auch IPv6-Subnetze mit separaten Gateways definieren. Das verteilte Routing funktioniert für beide Protokolle gleichermaßen.

Brauche ich für EVPN einen physischen BGP-Router?

Nein. Proxmox bringt FRRouting (FRR) mit, das als Software-BGP-Router auf den Nodes läuft. Du konfigurierst einen deiner Nodes als Route-Reflector, und die anderen Nodes peeren mit ihm. Ein externer physischer Router ist nur nötig, wenn du BGP-Peering mit netzwerkexternen Systemen brauchst.

Wie debugge ich SDN-Routing-Probleme?

Der Befehl ip route show table local zeigt dir, welche Routen lokal auf einem Node existieren. Mit bridge fdb show siehst du die MAC-Tabelle der Bridge. Für VXLAN-Tunnel hilft bridge vlan show beim Überprüfen der VLAN-Zuordnung. Und der Klassiker: tcpdump -i vnet_name zeigt dir, welche Pakete tatsächlich durch ein VNet fließen.

Kann ich das SDN-Gateway mit einer Firewall kombinieren?

Das SDN-Gateway selbst bietet keine Stateful-Firewall-Funktionalität. Du kannst aber die Proxmox-eigene Firewall auf VM- oder Container-Ebene nutzen, um Traffic zwischen VLANs zu filtern. Für komplexere Regeln oder Layer-7-Filterung ist eine dedizierte Firewall-VM der sauberere Weg — dann routest du nur die Netze über das SDN-Gateway, die keine Filterung brauchen.

Was ist schneller: VLAN Zone mit Gateway oder externe Router-VM?

Die VLAN Zone mit lokalem Gateway ist in der Regel schneller, weil sie den zusätzlichen Netzwerk-Hop zur Router-VM vermeidet. Der Unterschied wird bei hohem Durchsatz und vielen parallelen Verbindungen deutlich. Für die meisten Homelab-Workloads (Webserver, Datenbanken, Mediastreaming) ist der Unterschied aber im niedrigen einstelligen Prozentbereich und damit kaum spürbar.

Muss ich für das verteilte Gateway etwas auf meinem physischen Switch konfigurieren?

Nur, wenn die Gateway-IPs in Subnetzen liegen, die auch von physischen Geräten außerhalb des Clusters erreicht werden sollen. Innerhalb des Clusters kümmert sich das SDN um die Verteilung. Wenn externe Geräte das Gateway erreichen müssen, konfiguriere auf deinem Switch eine statische Route, die auf den Cluster zeigt — idealerweise mit VRRP oder einer anderen Redundanzmethode.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Fazit

VLAN-Routing im Proxmox-Cluster ist kein Hexenwerk, aber es verlangt eine bewusste Architekturentscheidung. Die Tage, in denen man einfach eine pfSense-VM als Allheilmittel hinstellt, sind im Cluster-Kontext vorbei — nicht, weil der Ansatz falsch ist, sondern weil es inzwischen bessere, native Alternativen gibt.

Wenn du heute einen Proxmox-Cluster mit VLANs aufsetzt, ist die VLAN Zone mit verteilten Subnet-Gateways dein Sweet Spot. Du bekommst lokales Routing ohne Single Point of Failure, automatische Synchronisation über alle Nodes und native Integration mit deinen bestehenden physischen Switches. Der Weg dorthin ist überschaubar: Eine VLAN-aware Bridge, eine SDN VLAN Zone, ein VNet pro VLAN mit Gateway-IP — und der Rest passiert automatisch.

Bleibt dein Cluster klein und du brauchst feingranulares Firewalling zwischen den VLANs, hat die Router-VM immer noch ihren Platz. Kombiniere sie dann gezielt mit SDN: Die Netze, die nur geroutet werden müssen, bekommen ein verteiltes Gateway. Die Netze, die gefiltert werden müssen, laufen über die Firewall-VM.

Und wenn dein Setup über den Homelab-Maßstab hinauswächst — mehrere Standorte, zweistellige Node-Zahlen, mandantenfähige Netze — dann öffne die Tür zur EVPN-Welt. Der Einstieg ist steil, aber was du dafür bekommst, ist ein selbstorganisierendes Netzwerk, das mit deinem Cluster mitwächst.

Der nächste Schritt liegt bei dir: Öffne die Proxmox-SDN-Oberfläche, lege eine Zone an und fang mit einem VNet an. Der Rest ergibt sich.

Quellen und weiterführende Informationen

Hinweis zur Quellenlage: Dieser Artikel basiert auf der langjährigen Proxmox-Dokumentation, dem SDN-Implementierungsstand in Proxmox VE 8.x und Community-Erfahrungen aus dem r/Proxmox-Subreddit. Die beschriebenen Architekturentscheidungen und Konfigurationsprinzipien leiten sich aus der offiziellen Dokumentation und verbreiteten Best Practices der Homelab-Community ab. Konkrete Konfigurationsbeispiele wurden im Einklang mit der Proxmox-Dokumentation erstellt.

Passende Produktrecherchen

Falls du dein Homelab-Netzwerk ausbauen möchtest, findest du hier thematisch passende Produktrecherchen. Mit einem Kauf über diese Links unterstützt du kalika.de — für dich entstehen keine Mehrkosten.

Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Preise und Verfügbarkeiten können abweichen.