# Virtual Bridges on SUSE: Das Rückgrat der Virtualisierung

TL;DR / Management Summary Ein Server, der virtuelle Maschinen (VMs) hostet, braucht einen Weg, um diese an das physikalische Netzwerk anzubinden. Eine Linux Bridge agiert als virtueller Switch innerhalb des SUSE-Kernels. Wir nutzen Wicked, um Bridges (br0 oder vmbr0) über physische Karten oder Bonds zu legen. Ein Senior Admin muss hierbei das Spanning Tree Protocol (STP) beherrschen, um gefährliche Netzwerkschleifen in redundanten Umgebungen zu verhindern.

# 1. Einführung & Architektur

Der Switch im RAM.

Eine Bridge arbeitet auf Layer 2 (OSI). Sie lernt, welche MAC-Adresse hinter welchem Port (physisch oder virtuell) liegt.

# Die Architektur-Schichten (Mermaid)

graph TD
    A[Physical Link: bond0] --- B[Bridge: br0]
    B --- C[Virtual Interface: tap0 - VM 1]
    B --- D[Virtual Interface: tap1 - VM 2]
    B --- E[Management IP: 10.0.0.5]
    subgraph "SUSE Hypervisor Host"
        B
        E
    end
    subgraph "External Network"
        A --- F[Physical Switch]
    end

# 2. Konfiguration via YaST

Präzise und sicher.

In SUSE ist es Best-Practice, die Management-IP des Hosts nicht auf die Karte, sondern auf die Bridge zu legen.

# Schritt-für-Schritt (YaST)

1. sudo yast2 lan.
2. Add -> “Bridge”.
3. Bridge Ports: Wählen Sie das physikalische Device aus (z.B. eth0). Dieses darf danach keine eigene IP mehr haben!
4. STP: Wenn Ihr Host an zwei Switches angeschlossen ist, aktivieren Sie STP = on.
5. IP: Vergeben Sie die IP-Adresse des Servers nun für die Bridge br0.

# 3. Manuelle Konfiguration (ifcfg-br0)

Für die Automatisierung.

Beispiel: /etc/sysconfig/network/ifcfg-br0

BOOTPROTO='static'
IPADDR='10.0.0.5/24'
STARTMODE='auto'
# Hier definieren wir die Bridge
BRIDGE='yes'
BRIDGE_PORTS='eth0'
BRIDGE_STP='on'
BRIDGE_FORWARDDELAY='0'

# 4. Day-2 Operations: STP und Forward Delay

Das Netz stabil halten.

# Warum STP?

Wenn zwei Netzwerkkarten eines Hosts an den gleichen Switch-Stack angeschlossen sind und beide Teil einer Bridge sind, entsteht ein Loop. STP erkennt dies und schaltet einen Pfad auf “Blocking”.

# Forward Delay

Standardmäßig wartet eine Bridge 15 Sekunden (Listening/Learning), bevor sie Pakete weiterleitet. In virtuellen Umgebungen (Proxmox/KVM) setzen wir diesen Wert oft auf 0, damit VMs nach dem Start sofort Netz haben.

# 5. Troubleshooting & “War Stories”

Wenn die Pakete im Loop sterben.

# Story 1: “Der Broadcast-Sturm”

Symptom: Das gesamte Firmennetzwerk bricht zusammen, sobald ein neuer SUSE-Node gestartet wird. Die CPU-Last auf den Switches springt auf 100%. Ursache: Eine Bridge ohne STP wurde an zwei Switch-Ports angeschlossen, die ebenfalls kein STP (oder BPDU Guard) aktiv hatten. Lösung: Aktivieren Sie BRIDGE_STP='on' in der Konfiguration und stellen Sie sicher, dass die Bridge-Priorität korrekt gesetzt ist.

# Story 2: “Kein Ping zur VM”

Symptom: Der Host kann das Internet erreichen, aber die VMs in der Bridge sind stumm. Ursache: Das Kernel-Modul br_netfilter ist geladen, und die Iptables-Regeln blockieren den Traffic, der durch die Bridge fließt. Lösung: Deaktivieren Sie das Filtern auf Bridge-Ebene (falls nicht benötigt): echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables.

# 6. Fazit & Empfehlung

• Virtualisierung: Nutzen Sie für KVM-Umgebungen unter SUSE immer Bridges.
• Management IP: Legen Sie die IP des Hosts auf die Bridge. Das erlaubt Wartungsarbeiten am physikalischen Interface, ohne die logische IP-Verbindung zu unterbrechen.
• Wahl: Nutzen Sie Open vSwitch (OVS) nur dann, wenn Sie komplexe SDN-Features (Software Defined Networking) brauchen. Für 99% der Fälle reicht die Standard Linux Bridge.

# Anhang: Cheatsheet