# Bonding & Teaming: Redundantes Netzwerk unter RHEL

TL;DR / Management Summary In der RHEL-Welt gab es lange zwei parallele Konzepte für die Bündelung von Netzwerkkarten: Bonding (Kernel-basiert) und Teaming (User-Space-basiert via teamd). Wichtigste Info: Ab RHEL 9 ist Teaming offiziell veraltet (deprecated). Wir setzen im Enterprise-Umfeld wieder voll auf das klassische Linux-Bonding, da es performanter ist und eine bessere Hardware-Unterstützung bietet. Das Ziel: Ausfallsicherheit gegen Switch- oder Kabeldefekte.

# 1. Einführung & Architektur

Bonding vs. Teaming.

• Bonding: Läuft im Kernel. Es ist schnell, robust und wird von fast allen Tools unterstützt.
• Teaming: Wollte die Komplexität in den User-Space verlagern, konnte sich aber nie durchsetzen und wird nun von Red Hat wieder entfernt.

# Der Bond-Workflow (Mermaid)

graph TD
    A[Logical Device: bond0] --> B[Slave NIC 1: eth0]
    A --> C[Slave NIC 2: eth1]
    B --- D[Switch A]
    C --- E[Switch B]
    subgraph "Modes"
        F[Active-Backup: Mode 1]
        G[LACP: Mode 4]
    end
    A --- F
    A --- G

# 2. LACP Bond erstellen (Enterprise Standard)

Maximale Bandbreite und Redundanz.

Wir nutzen LACP (802.3ad), was einen Switch-Stack oder einen Switch mit LACP-Support voraussetzt.

# Schritt 1: Bond-Master anlegen

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,miimon=100"

# Schritt 2: Physikalische Slaves hinzufügen

sudo nmcli con add type ethernet con-name bond0-port1 ifname eth0 master bond0
sudo nmcli con add type ethernet con-name bond0-port2 ifname eth1 master bond0

# Schritt 3: IP auf dem Bond setzen

sudo nmcli con mod bond0 ipv4.addresses 192.168.10.20/24 ipv4.method manual
sudo nmcli con up bond0

# 3. Active-Backup (Wenn der Switch kein LACP kann)

Der sicherste Failover-Weg.

Hier ist nur eine Karte aktiv. Die zweite übernimmt erst, wenn der Link der ersten Karte stirbt.

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

# 4. Day-2 Operations: Status & Diagnose

Funktioniert das Failover?

# Den Kernel-Status prüfen (Die Wahrheit)

cat /proc/net/bonding/bond0

Hier sehen Sie:

• Welcher Port aktuell Active ist.
• Ob der LACP Partner (Switch) korrekt antwortet.
• Wie viele Link Failures aufgetreten sind.

# NetworkManager Sicht

nmcli con show bond0

# 5. Troubleshooting & “War Stories”

Wenn der Link hakt.

# Story 1: “Der LACP-Blackout”

Symptom: Nach dem Aktivieren von LACP ist der Server nicht mehr erreichbar. cat /proc/net/bonding/bond0 zeigt, dass keine LACP-Pakete vom Switch empfangen werden. Ursache: Der Switch-Port steht noch auf “Access” und nicht auf “LACP / Port-Channel”. Lösung: Stellen Sie sicher, dass der Switch-Admin den channel-group mode active gesetzt hat. Tipp: Nutzen Sie erst active-backup, um den Zugriff zu behalten, während Sie den Switch konfigurieren.

# Story 2: “MTU-Mismatch beim Bonding”

Symptom: Der Bond ist up, aber große Pakete (NFS/iSCSI) gehen verloren. Ursache: Die Slaves haben unterschiedliche MTU-Werte oder der Bond-Master hat eine andere MTU als die Slaves. Lösung: Setzen Sie die MTU immer auf dem Bond-Master. Der NetworkManager wendet dies automatisch auf die Slaves an: sudo nmcli con mod bond0 802-3-ethernet.mtu 9000.

# 6. Fazit & Empfehlung

• RHEL 9: Nutzen Sie kein Teaming mehr. Migrieren Sie bestehende Teaming-Konfigurationen zu Bonding.
• Monitoring: Überwachen Sie /proc/net/bonding/bondX. Ein Server, der auf einer Karte “humpelt”, ist ein ungelöstes Ticket.
• miimon: Ein Wert von 100ms ist der Enterprise-Standard für die Überprüfung des Link-Status.

# Anhang: Cheatsheet