Network Bonding und Teaming mit NetworkManager: Modi, Switch-Anforderungen und Überprüfung

Worum es geht

Linux Bonding (der Kerneltreiber bonding) stellt mehrere physische Netzwerkkarten als eine logische Schnittstelle (bondX) bereit. NetworkManager kann eine Bond-Verbindung anlegen und verwalten: Dazu dient ein Verbindungstyp bond sowie pro Slave eine ethernet-Verbindung, die als Port des Bonds markiert ist. Die Optionen des Kerneltreibers liegen in der Eigenschaft bond.options (zum Beispiel mode=802.3ad,miimon=100). Teaming (teamd, Verbindungstyp team) ist die ältere Alternative; es gilt in RHEL 9 als veraltet (deprecated) und ist in RHEL 10 entfernt. Neue Setups sollten daher Bonding verwenden.

Warum es wichtig ist

Die Bonding-Modi sind nicht austauschbar. Eine falsche Wahl bringt entweder keinen Nutzen oder unterbricht die Konnektivität:

• active-backup: Es ist jeweils nur ein Slave aktiv, die übrigen stehen in Reserve; bei Link-Verlust erfolgt ein Failover. Auf dem Switch ist keine Konfiguration nötig – jede Netzwerkkarte kann sogar an einen anderen Switch angeschlossen werden, was zugleich der wichtigste Ausfallsicherheitsvorteil dieses Modus ist.
• 802.3ad (LACP): Die Slaves handeln mit dem Switch über das LACP-Protokoll eine dynamische Link Aggregation Group aus. Normalerweise hängen alle Slaves am selben Switch, und dessen Ports müssen ausdrücklich als passende LACP-Gruppe konfiguriert sein. Ohne diese Konfiguration auf der Switch-Seite wird Verkehr verworfen, oder es wird faktisch nur ein Slave genutzt.
• Die übrigen Modi gewichten Lastverteilung und Switch-Anforderungen unterschiedlich: balance-rr, balance-xor und broadcast erfordern, dass die Switch-Ports als statischer (nicht-LACP) EtherChannel bzw. Trunk zusammengefasst sind, sonst sieht der Switch dieselbe MAC-Adresse zwischen den Ports hin- und herspringen (Flapping). balance-tlb und balance-alb benötigen keine Switch-Konfiguration.

So wird es angewendet

• Den Modus danach wählen, was das Switch-Team konfigurieren kann: active-backup, wenn keine abgestimmte Switch-Konfiguration möglich oder verfügbar ist; 802.3ad, wenn sich ein korrekter LACP-Port-Channel bzw. EtherChannel einrichten lässt.
• Mit nmcli anlegen: eine bond-Verbindung mit bond.options, danach zwei oder mehr ethernet-Verbindungen, bei denen connection.master auf den Bond zeigt und connection.slave-type bond gesetzt ist.
• Den ausgehandelten Zustand prüfen, nicht nur die Konfiguration: cat /proc/net/bonding/bond0 zeigt den aktiven Modus, den MII-Status je Slave und – bei 802.3ad – den LACP-Partner sowie die Aggregator-IDs, auf die man sich mit dem Switch tatsächlich geeinigt hat.
• Das Failover-Verhalten bestätigen, indem ein Slave heruntergefahren wird (ip link set eth0 down, als root). Anschliessend in /proc/net/bonding/bond0 prüfen, ob die Umschaltung sichtbar ist und die Konnektivität erhalten bleibt; mit ip link set eth0 up wieder aktivieren. Diesen Test von einer Konsole aus durchführen, nicht über den Bond selbst – funktioniert das Failover nicht, ist die Sitzung weg.

Stolpersteine

• 802.3ad auf dem Host konfigurieren, während die Switch-Ports im Standalone-Modus (nicht aggregiert) bleiben: Der Link kommt unter Umständen trotzdem hoch, aber der Verkehr wird verworfen oder dupliziert.
• Annehmen, /proc/net/bonding gebe die Absicht aus einer Konfigurationsdatei wieder. Die Datei zeigt nur, was der Treiber aktuell ausgehandelt hat – nach jeder Änderung auf der Switch-Seite erneut prüfen.