# Proxmox Virtual Bridges: Architektur & Netzwerk-Performance

TL;DR / Management Summary In Proxmox VE ist die Linux Bridge (vmbr0) das Rückgrat des Netzwerks. Sie agiert als virtueller Switch auf dem Host, der physische Netzwerkkarten mit virtuellen VM-Adaptern verbindet. Ein Senior Admin nutzt Bonding (LACP) zur Bündelung physischer Karten, setzt auf VLAN-Aware Bridges zur Reduzierung von Komplexität und trennt Management-, Storage- und VM-Traffic konsequent auf Layer-2 Ebene.

# 1. Das Bridge-Konzept

Der Software-Switch.

Eine Bridge (vmbr) leitet Ethernet-Frames auf Layer 2 weiter.

• vmbr0 (Standard): Meist an eth0 gebunden. Dient dem Management und dem VM-Traffic.
• VLAN-Aware: Erlaubt es VMs, VLAN-Tags direkt zu senden und zu empfangen (Artikel 548).

# 2. Bonding & Redundanz

Zwei Kabel sind besser als eins.

Nutzen Sie Linux Bonding, um Ausfallsicherheit zu erreichen. Node -> Network -> Create -> Bond.

• Mode: LACP (802.3ad): Bietet Lastverteilung und Fehlertoleranz (erfordert Support am physischen Switch).
• Mode: Active-Backup: Einfachste Form der Redundanz (kein Switch-Support nötig).

# 3. Deep Dive: Open vSwitch (OVS)

Die Enterprise-Alternative.

Neben der Standard-Linux-Bridge unterstützt Proxmox Open vSwitch.

• Vorteil: Bietet fortgeschrittene Features wie Overlay-Netzwerke (Gre, VXLAN) und besseres Management von VLAN-Trunks.
• Einsatz: Wenn Sie OVS nutzen, sollten Sie dies auf allen Knoten des Clusters einheitlich tun.

# 4. Day-2 Operations: MTU & Performance

Den Datenstau vermeiden.

Sollten Sie 10G+ Karten nutzen (Artikel 661):

• Aktion: Setzen Sie die MTU auf allen Bridges und physischen Interfaces auf 9000 (Jumbo Frames).
• Wichtig: Die gesamte Kette (VM -> Bridge -> Switch -> Storage) muss die gleiche MTU unterstützen, sonst kommt es zu Paketfragmentierung.

# 5. Troubleshooting & “War Stories”

Wenn die Bridge bricht.

# Top 3 Fehlerbilder

1. Symptom: Host verliert Verbindung nach Netzwerk-Änderung.

   • Ursache: IP-Adresse wurde dem physischen Interface (eth0) statt der Bridge (vmbr0) zugewiesen.
   • Lösung: IPs gehören in Proxmox immer an die Bridge!

2. Symptom: LACP-Bond geht nicht “Up”.

   • Ursache: Mismatch zwischen Active (Host) und Passive (Switch).
   • Lösung: cat /proc/net/bonding/bond0 prüfen.

3. Symptom: VMs können sich im gleichen VLAN nicht pingen.

   • Fix: Proxmox Firewall-Regeln auf Datacenter-Ebene prüfen (Artikel 664).

# “War Story”: Die “Loop”-Katastrophe

Ein Admin erstellte zwei Bridges (vmbr0 und vmbr1) und verband beide physisch mit dem gleichen Switch, ohne Bonding zu konfigurieren. Das Ergebnis: Ein Layer-2 Loop. Innerhalb von Millisekunden fluteten Broadcast-Pakete das gesamte Firmennetzwerk. Alle Proxmox-Hosts waren für Stunden offline. Lehre: Aktivieren Sie STP (Spanning Tree Protocol) in den Bridge-Optionen, wenn Sie mehr als einen physischen Uplink ohne Bonding nutzen.

# 6. Monitoring & Reporting

Traffic-Statistiken.

# Brücken-Status (Shell)

# Zeigt, welche VMs an welcher Bridge hängen
brctl show

# 7. Fazit & Empfehlung

Ein durchdachtes Netzwerk-Layout ist die Basis für einen stabilen Cluster.

• Empfehlung: Nutzen Sie VLAN-Aware Linux Bridges. Sie bieten die beste Mischung aus Performance und einfacher Verwaltung.
• Wichtig: Dokumentieren Sie Ihre Port-Belegung (z.B. Port 1: Management, Port 2: VM-VLANs, Port 3+4: Storage).

# Anhang: Cheatsheet (Bonding Modes)

# Referenzen

• Proxmox VE: Network Configuration
• Linux Foundation: Ethernet Bridge Documentation
• Open vSwitch Project Page