Proxmox VE: Netzwerk mit Bridges, VLANs, Bonds und SDN
Auf einen Blick
| Gilt für | Proxmox VE 9.1 und 9.2 (Debian 13), ifupdown2, Linux-Bridge, SDN; Einzelserver und Cluster |
|---|---|
| Bereich | Server-Software |
| Dauer | ca. 1–2 Stunden (Planung und Umstellung je Knoten) |
| Rechte | root@pam bzw. Rolle Administrator; Zugang zur Konsole (IPMI/iDRAC/iLO) als Rückfallebene |
| Stand | Oktober 2026 |
Das Proxmox-Netzwerk mit Bridges, VLANs und Bonds einrichten ist die Grundlage für einen stabilen Betrieb von VMs und Containern im Unternehmen. VMs hängen an Linux-Bridges, VLANs trennen Netze, Bonds sichern Uplinks ab. Dieser Artikel zeigt die Konfiguration in /etc/network/interfaces mit ifupdown2, die sinnvolle Trennung von Cluster-, Migrations- und Storage-Verkehr und den Einstieg in Software-Defined Networking (SDN) mit Zonen und VNets.
Grundbegriffe und Planung
| Baustein | Name (Beispiel) | Aufgabe |
|---|---|---|
| Physischer Port | eno1, enp1s0f0, gepinnt mit Präfix nic |
Verbindung zum Switch |
| Linux-Bridge | vmbr0 |
virtueller Switch, an dem VMs und Container hängen |
| Bond | bond0 |
bündelt zwei oder mehr Ports (Link Aggregation) |
| VLAN-Interface | vmbr0.20, eno1.20 |
IP-Adresse des Hosts in einem VLAN |
| SDN-VNet | vnet20 |
clusterweit definiertes Netz, auf allen Knoten gleich |
Bewährte Aufteilung für KMU-Cluster:
- Management: Weboberfläche und SSH, eigenes VLAN, nur aus dem Admin-Netz erreichbar.
- VM-Verkehr: VLAN-aware Bridge auf einem Bond (2 × 10 GbE oder 2 × 25 GbE).
- Corosync: eigener physischer Port (1 GbE genügt), zweiter Link als Reserve. Corosync braucht Latenzen unter 5 ms, aber kaum Bandbreite – und darf sich die Leitung nicht mit Storage- oder Migrationsverkehr teilen.
- Storage/Ceph und Migration: eigenes, schnelles Netz (mindestens 10 GbE).
/etc/network/interfaces mit ifupdown2
Seit Proxmox VE 7.0 ist ifupdown2 Standard. Änderungen in der Weboberfläche (<Knoten> › System › Network) landen zunächst in /etc/network/interfaces.new; erst Apply Configuration übernimmt sie ohne Neustart. Wer die Datei von Hand bearbeitet, lädt sie anschließend neu:
cp /etc/network/interfaces /root/interfaces.bak # Sicherung
nano /etc/network/interfaces
ifreload -a # Änderungen anwenden
ip -br addr; bridge vlan show # Ergebnis prüfen
Wichtig: Netzwerkänderungen nie ohne zweiten Zugang durchführen. Ein Tippfehler bei Bridge oder Gateway trennt die SSH-Sitzung; dann hilft nur die Konsole über IPMI, iDRAC oder iLO.
Der Installer legt eine einfache Bridge an:
auto lo
iface lo inet loopback
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.168.10.2/24
gateway 192.168.10.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
Schnittstellennamen festschreiben: Neue Kernel oder Firmware können Netzwerknamen verändern. Proxmox VE bringt dafür pve-network-interface-pinning generate mit; es erzeugt .link-Dateien mit dem Präfix nic unter /usr/local/lib/systemd/network und legt angepasste Konfigurationen mit Endung .new zum Vergleich ab. Danach ist ein Neustart nötig. Die Datacenter-Firewall (/etc/pve/firewall/cluster.fw) passt das Werkzeug nicht an – dort Interface-Namen selbst prüfen.
Bonds mit LACP oder active-backup
| Modus | Switch-Konfiguration | Einsatz |
|---|---|---|
| 802.3ad (LACP) | LACP-Port-Channel bzw. LAG nötig | Empfehlung, wenn der Switch LACP beherrscht; mit Switch-Stack auch über zwei Geräte |
| active-backup | keine | Standard ohne LACP; ein Port aktiv, der zweite springt bei Ausfall ein |
| balance-tlb, balance-alb | keine | nicht für Bridges mit Gästen verwenden |
| balance-rr, balance-xor, broadcast | je nach Modus | Sonderfälle, im KMU nicht nötig |
Bond als Unterbau einer VLAN-aware Bridge – die übliche Konfiguration für den VM-Verkehr:
auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3
auto vmbr0
iface vmbr0 inet manual
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
auto vmbr0.10
iface vmbr0.10 inet static
address 192.168.10.2/24
gateway 192.168.10.1
Der Host erhält seine Management-Adresse im VLAN 10 über vmbr0.10. Am Switch werden beide Ports als LACP-Gruppe und Trunk-Port mit den benötigten VLANs konfiguriert, z. B. EtherChannel mit LACP oder Link Aggregation bei UniFi.
Corosync braucht keinen Bond. Proxmox empfiehlt stattdessen mehrere getrennte Corosync-Links (bis zu acht), zwischen denen Corosync selbst umschaltet. Manche Bond-Modi verursachen bei Corosync sogar Probleme.
VLANs für VMs und Container
Mit einer VLAN-aware Bridge trägt man das VLAN direkt an der Netzwerkkarte der VM ein (Hardware › Network Device › VLAN Tag); weitere Bridges je VLAN entfallen. Ohne Tag hängt die VM im untagged bzw. Native VLAN des Ports.
qm set 120 --net0 virtio,bridge=vmbr0,tag=20,firewall=1 # VM im VLAN 20
pct set 130 --net0 name=eth0,bridge=vmbr0,tag=30,ip=dhcp # Container im VLAN 30
OPNsense als Firewall-VM: Für eine virtualisierte OPNsense gibt es zwei Wege:
- eine VirtIO-Karte ohne Tag an die VLAN-aware Bridge hängen und die VLANs in OPNsense anlegen (Trunk in die VM, siehe OPNsense - VLAN und Netzwerksegmentierung) – übersichtlich, solange es wenige Netze sind;
- je VLAN eine eigene Karte mit Tag – einfacher in OPNsense, aber die Zahl der Karten pro VM ist begrenzt.
Die WAN-Leitung sollte über einen eigenen physischen Port und eine eigene Bridge ohne Host-IP laufen. In OPNsense bleiben die Hardware-Offloads für VirtIO-Karten deaktiviert (Standard unter Interfaces › Settings).
Getrennte Netze für Cluster, Migration und Storage
Ohne Vorgabe nutzt Proxmox VE für Live-Migrationen das Cluster-Netz – bei großen VMs stört das Corosync. Ein eigenes Migrationsnetz wird in /etc/pve/datacenter.cfg festgelegt (in der Oberfläche unter Datacenter › Options); jeder Knoten braucht darin genau eine IP-Adresse:
# /etc/pve/datacenter.cfg
migration: secure,network=10.10.30.0/24
secure verschlüsselt den Transfer per SSH; insecure ist schneller, überträgt aber den Arbeitsspeicher der VM unverschlüsselt und kommt nur in einem physisch abgeschotteten Netz infrage. Für eine einzelne Migration: qm migrate 120 pve2 --online --migration_network 10.10.30.0/24.
Ein eigenes Storage-Netz (NFS, iSCSI, Ceph) erhält ein Interface ohne Gateway, z. B. bond1 mit address 10.10.40.11/24. Jumbo Frames (mtu 9000) nur setzen, wenn alle Switch-Ports und alle Knoten durchgehend dieselbe MTU haben – sonst entstehen schwer auffindbare Aussetzer. Die Corosync-Links werden beim Anlegen des Clusters angegeben, siehe Proxmox VE: Cluster und Hochverfügbarkeit.
SDN: Zonen und VNets im Cluster
Mit Proxmox SDN werden Netze einmal unter Datacenter › SDN definiert und auf allen Knoten gleich ausgerollt. Voraussetzung ist die Zeile source /etc/network/interfaces.d/* am Ende von /etc/network/interfaces auf jedem Knoten. Änderungen sind zunächst ausstehend und werden in Datacenter › SDN mit Apply clusterweit angewendet.
| Zone | Funktion | Typischer Einsatz |
|---|---|---|
| Simple | isolierte Bridge je Knoten, optional mit NAT und DHCP | Testnetze, Labor |
| VLAN | VLAN-Tag pro VNet auf einer vorhandenen Bridge | Standard im KMU: VLANs zentral pflegen |
| QinQ | gestapelte VLANs (Service-VLAN außen) | Provider-Netze; MTU 1496 bei 1500-Byte-Leitung |
| VXLAN | Layer-2-Overlay über UDP 4789, MTU 50 Byte kleiner | Standorte bzw. Racks ohne gemeinsames VLAN; keine Verschlüsselung |
| EVPN | VXLAN mit BGP-Steuerung und Routing zwischen VNets | größere Cluster, Mandantentrennung |
So entsteht ein VLAN-Netz für alle Knoten:
- Datacenter › SDN › Zones › Add › VLAN: ID z. B. vlanzone, Bridge vmbr0.
- Datacenter › SDN › VNets › Create: Name vnet20 (höchstens 8 Zeichen), Zone vlanzone, Tag 20.
- Optional unter dem VNet ein Subnetz mit Gateway anlegen (IPAM pve; IPAM und DHCP sind Tech Preview).
- Datacenter › SDN › Apply. Das VNet erscheint auf jedem Knoten als Bridge und lässt sich VMs zuweisen; Berechtigungen gibt es pro VNet.
Für EVPN und Fabrics werden frr und frr-pythontools auf allen Knoten benötigt.
Neu in Proxmox VE 9.2: Unter Datacenter › SDN › Fabrics gibt es neben OpenFabric und OSPF nun auch WireGuard-Fabrics (verschlüsselte Verbindungen zwischen Knoten, Paket wireguard-tools) und BGP-Fabrics (eBGP-Underlay ohne Adressierung der Verbindungsnetze, eigene ASN je Knoten). Dazu kommen Route Maps, Prefix Lists, OSPF-Redistribution und ein IPv6-Underlay für EVPN. Für die meisten KMU bleibt die VLAN-Zone der passende Einstieg.
Hinweise
- Dokumentieren: Port-, VLAN- und IP-Plan pro Knoten festhalten; alle Knoten eines Clusters sollten identisch verkabelt sein, damit Bridges und VNets überall gleich heißen.
- STP:
bridge-stp offist Standard; Schleifenschutz übernimmt der Switch (Spanning Tree Protocol, BPDU Guard an Server-Ports nur mit Bedacht). - Firewall: Die Option firewall=1 an der VM-Karte aktiviert die Proxmox-Firewall für diese Schnittstelle, siehe Proxmox VE: Sicherheit mit Rollen, 2FA, Firewall und Updates.
- Für Planung, Überwachung und Betrieb der Netzwerk- und Virtualisierungsumgebung bieten sich die Managed Services von m.a.x. it an.
Siehe auch
- Proxmox im Unternehmen – Überblick und alle Artikel der Reihe
- Proxmox VE: Installation und Grundkonfiguration
- Proxmox VE: Cluster und Hochverfügbarkeit
- Proxmox VE: Storage mit ZFS, Ceph und Replikation
- Proxmox VE: Sicherheit mit Rollen, 2FA, Firewall und Updates
- OPNsense - VLAN und Netzwerksegmentierung
Links und Quellen
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
