Linux LACP-Bonding: Konfiguration, Überprüfung und Fehlerbehebung

Linux LACP-Bonding bündelt mehrere Ethernet-Schnittstellen zu einer einzigen logischen Verbindung und bietet Ihnen so mehr Gesamtbandbreite sowie automatisches Failover zwischen physischen Netzwerkkarten. Es nutzt den IEEE 802.3ad-Standard, wobei beide Seiten (Server und Switch) aushandeln, welche Verbindungen aktiv sind und wie der Datenverkehr verteilt wird. Dieser Beitrag behandelt, was LACP tatsächlich leistet, wann man es den anderen Linux-Bonding-Modi vorziehen sollte, wie man es auf einem modernen Linux-Server konfiguriert und wie man überprüft, ob es funktioniert.

Was sind Link-Aggregation und LACP?

Link Aggregation bündelt mehrere physische Netzwerkverbindungen zu einem logischen Kanal. Dies dient zwei Zwecken: der Erhöhung der insgesamt verfügbaren Bandbreite über die Linkgruppe hinweg und der Bereitstellung eines automatischen Failovers, falls eine einzelne Verbindung ausfällt.

LACP, das Link Aggregation Control Protocol, ist die dynamische Version der Link-Aggregation, die durch IEEE 802.3ad definiert ist. Anstatt sich auf eine statische Konfiguration an beiden Enden zu verlassen, tauscht LACP Kontrollpakete, sogenannte LACPDUs, zwischen dem Server und dem Switch aus. Beide Seiten verhandeln, welche Verbindungen in die Aggregation aufgenommen werden, überwachen den Zustand jeder Verbindung und nehmen Mitglieder in die Gruppe auf oder entfernen sie aus ihr, wenn sich die Bedingungen ändern.

In einem Linux-Kontext läuft LACP als Modus 4 (802.3ad) des Kernel-Bonding-Treibers. Der Treiber erstellt eine logische Schnittstelle (typischerweise bond0), die die IP-Adresse besitzt, während physische Schnittstellen wie eth0 und eth1 Untergebene des Bonds werden. Aus Sicht des Betriebssystems gibt es eine Netzwerkschnittstelle. Aus Sicht der physischen Verbindung gibt es mehrere parallele Ethernet-Verbindungen.

Einige Dinge, die LACP ausdrücklich nicht tut, obwohl dies oft erwartet wird:

• Eine einzelne TCP-Verbindung läuft weiterhin über eine physische Verbindung. LACP verteilt den Datenverkehr, nicht die Pakete innerhalb eines Datenflusses. Zwei gebündelte 1-GbE-Verbindungen sorgen nicht dafür, dass ein einzelner Download schneller als 1 Gbit/s läuft.
• LACP erfordert einen Switch, der 802.3ad unterstützt. Es lässt sich kein Bond mit einem unmanaged oder nicht-LACP-fähigen Switch bilden.
• Alle Mitgliedsverbindungen müssen mit derselben Geschwindigkeit und demselben Duplexmodus laufen. Sie können einen 1-GbE-Port nicht mit einem 10-GbE-Port bündeln.

Linux-Bonding-Modi: Wann sollte LACP verwendet werden?

Der Linux-Bonding-Treiber unterstützt sieben Modi. In den meisten Produktionsumgebungen wird einer von drei Modi verwendet.

Modus 1: Active-Backup

Eine Schnittstelle ist aktiv, die anderen bleiben im Leerlauf. Wenn die aktive Schnittstelle ausfällt, übernimmt eine andere innerhalb weniger hundert Millisekunden. Es ist keine Switch-Konfiguration erforderlich, was diesen Modus zur richtigen Wahl macht, wenn die Switches außerhalb Ihrer Kontrolle liegen oder 802.3ad nicht unterstützen. Sie erhalten Redundanz, aber keine zusätzliche Bandbreite.

Modus 4: 802.3ad (LACP)

Alle Mitglieder übertragen Datenverkehr. Der Bonding-Treiber und der Switch verwenden LACP, um den aktiven Satz auszuhandeln und Ausfälle zu erkennen. Der ausgehende Datenverkehr wird anhand einer von Ihnen konfigurierten Hash-Richtlinie auf die Mitglieder verteilt. Dies ist die Standardwahl für dedizierte Server, die an verwaltete Switches angeschlossen sind, wenn Sie sowohl Redundanz als auch zusätzliche Bandbreite für Multi-Flow-Workloads wünschen.

Modus 6: balance-alb

Adaptives Lastenausgleich in beide Richtungen, ohne dass Switch-Unterstützung erforderlich ist. Der Treiber fängt ARP-Antworten ab, um MAC-Adressen umzuschreiben und eingehenden Datenverkehr zu verteilen. Es funktioniert, ist aber im Vergleich zu LACP anfällig. Verwenden Sie es nur, wenn eine Konfiguration auf Switch-Seite wirklich unmöglich ist.

Entscheidungsregel:

• Kein verwalteter Switch oder Sie benötigen nur Failover: Modus 1 (active-backup).
• Managed Switch, mehrere Flows, Sie benötigen sowohl Bandbreite als auch Redundanz: Modus 4 (LACP).
• Managed Switch ist nicht möglich, aber Sie benötigen Lastverteilung in beide Richtungen: Modus 6 (balance-alb).

Die Modi 0 (Balance-RR), 2 (Balance-XOR), 3 (Broadcast) und 5 (Balance-TLB) existieren zwar, sind auf moderner Hardware jedoch selten die richtige Wahl. Wählen Sie Modus 1 oder Modus 4, sofern Sie keinen konkreten Grund haben, dies nicht zu tun.

Konfigurieren von LACP-Bonding unter Linux

Auf modernen Ubuntu- und Debian-Systemen wird LACP über netplan konfiguriert. Auf RHEL, CentOS Stream, AlmaLinux und Rocky Linux verwenden Sie NetworkManager über nmcli oder durch Bearbeiten der zugrunde liegenden Verbindungsdateien.

Netplan (Ubuntu, Debian)

Fügen Sie Folgendes in /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

Wenden Sie die Änderungen dann mit netplan apply. Die wichtigsten Parameter:

• mode: 802.3ad aktiviert LACP.
• lacp-rate: fast sendet LACPDUs jede Sekunde statt der standardmäßigen 30 Sekunden. Muss mit der Switch-Einstellung übereinstimmen.
• mii-monitor-interval: 100 Fragt den Link-Status alle 100 ms ab.
• transmit-hash-policy: layer3+4 verteilt Datenströme nach Quell-/Ziel-IP und TCP/UDP-Port. Dies sorgt für eine bessere Lastverteilung als die Standard- layer2 Richtlinie für typischen Web- und Datenbankverkehr.

NetworkManager (RHEL, AlmaLinux, Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

Switch-Seite

Der Switch benötigt eine LAG-Gruppe (oft als Port-Channel bezeichnet), die auf den LACP-Aktivmodus konfiguriert ist und die gleiche Anzahl an Mitgliedsports wie die Bond-Konfiguration aufweist. Die genaue Syntax variiert je nach Hersteller, die Anforderungen jedoch nicht: Die Ports müssen sich im selben VLAN befinden, auf dieselbe Geschwindigkeit und denselben Duplexmodus eingestellt sein und auf mindestens einer Seite den LACP-Aktivmodus verwenden. Die sicherste Konfiguration ist, wenn beide Seiten aktiv sind.

Unter Cisco IOS:

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Auf Aruba/ProCurve:

trunk 1-2 trk1 lacp

Die lacp_rate Einstellung am Switch muss mit der des Hosts übereinstimmen. Eine Nichtübereinstimmung ist hier einer der häufigsten LACP-Konfigurationsfehler und verursacht alle 30 Sekunden ein zeitweiliges Flapping.

Überprüfung und Fehlerbehebung bei LACP

Überprüfen Sie den Live-Status des Bonds auf der Linux-Seite:

cat /proc/net/bonding/bond0

Vier Dinge, auf die Sie in der Ausgabe achten sollten:

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation bestätigt, dass Modus 4 geladen ist.
2. Jede untergeordnete Schnittstelle, die mit MII Status: up und link failure count: 0.
3. Ein Wert ungleich Null Partner Mac Address für jede untergeordnete Schnittstelle. Sind hier nur Nullen zu sehen, bedeutet dies, dass der Switch überhaupt keine LACP-Pakete sendet, entweder weil der Port nicht in einem LACP-aktiven LAG ist oder weil das Kabel am falschen Port steckt.
4. Aggregator ID ist auf jedem Mitglied gleich. Unterschiedliche IDs bedeuten, dass die Mitglieder nicht tatsächlich kombiniert sind, sondern unabhängig voneinander agieren.

Der schnellste Test, um zu überprüfen, ob die Bandbreite genutzt wird, ist die Ausführung von iperf3 mit mehreren parallelen Streams (iperf3 -P 8) von einem anderen Host aus. Wenn der Gesamtdurchsatz die Kapazität einer einzelnen Verbindung übersteigt, sorgt LACP für den richtigen Lastausgleich. Ein Ein-Stream-Test, der die Geschwindigkeit einer einzelnen Verbindung anzeigt, ist erwartetes Verhalten und kein Fehler.

Die häufigsten LACP-Probleme und ihre Ursachen:

• Die Partner-MAC besteht nur aus Nullen: Der Switch-Port befindet sich nicht in einer LACP-aktiven LAG oder die Kabel sind falsch gepatcht.
• Die Verbindung wird hergestellt, aber der Durchsatz bleibt auf einer Verbindung stehen: Die Hash-Richtlinie wurde wahrscheinlich standardmäßig auf layer2, die nur nach Ziel-MAC hasht. Wechseln Sie zu layer3+4.
• Intermittierendes Flapping alle 30 Sekunden: lacp_rate Nichtübereinstimmung zwischen Host und Switch.
• Ein untergeordneter Port funktioniert, der andere überträgt jedoch keinen Datenverkehr: Nicht übereinstimmende Geschwindigkeit/Duplex-Einstellung oder die Switch-Ports befinden sich auf der Switch-Seite nicht in derselben LAG-Gruppe.

Wenn LACP nicht die richtige Lösung ist

LACP löst ein spezifisches Problem: die Aggregation mehrerer Verbindungen zwischen einem Host und einem Switch (oder einem Switch-Stack), um Redundanz und Bandbreite pro Datenfluss zu erzielen. Es gibt Szenarien, in denen es nicht das richtige Werkzeug ist.

Wenn Sie nur Redundanz benötigen und die Switches 802.3ad nicht unterstützen, verwenden Sie stattdessen Modus 1 (Active-Backup). Dieser funktioniert mit jedem System.

Wenn Sie zwei separate Switches für Redundanz auf Chassis-Ebene verbinden müssen, überbrückt Standard-LACP keine zwei unabhängigen Switches. Sie benötigen Multi-Chassis Link Aggregation (MLAG), bei dem sich zwei Switches als ein einziger logischer LACP-Partner präsentieren. Die meisten Anbieter von Enterprise-Switches implementieren dies unter ihrem eigenen Namen: Cisco vPC, Arista MLAG, Juniper MC-LAG.

Wenn ein einzelner Datenfluss die Bandbreite einer Verbindung überschreiten muss, ist dies mit LACP nicht möglich. Die Optionen sind entweder die Verwendung einer schnelleren physischen Verbindung (Ersetzen von 2x 10 GbE durch 1x 25 GbE oder 1x 40 GbE) oder der Einsatz einer völlig anderen Technologie. SR-IOV bietet virtuellen Maschinen eine Single-Flow-Leistung nahe der Leitungsgeschwindigkeit, indem es jeder VM eine hardwarebeschleunigte virtuelle Netzwerkkarte zuweist, löst jedoch ein anderes Problem und hat seine eigenen Einschränkungen. Das ist ein Thema für einen separaten Beitrag.

Für die meisten dedizierten und Colocation-Server, die viele gleichzeitige Verbindungen verarbeiten, bleibt LACP die Standardlösung. Zwei gebündelte 10-GbE-Verbindungen mit layer3+4 Hashing bewältigen problemlos mehr als 18 Gbit/s an Gesamtdatenverkehr über viele Flows hinweg und überstehen dabei einen NIC- oder Kabelausfall, ohne dass ein Paket verloren geht.