Netzwerk-Bonding mit LACP: Ausfallsicherheit und Bandbreite bündeln

1. Warum ein einzelner Netzwerk-Port nicht ausreicht

Server mit nur einer aktiven Netzwerkkarte sind gegenüber Kabelbruch, defekter Netzwerkkarte oder einem ausfallenden Switch-Port völlig ungeschützt, unabhängig davon, wie redundant Storage oder Stromversorgung ausgelegt sind. Gerade bei Datenbankservern oder Application-Servern, die permanent erreichbar sein müssen, ist ein solcher Single Point of Failure in der Netzwerkanbindung ein oft übersehenes Risiko, das im Vergleich zu redundanten Netzteilen oder RAID-Arrays deutlich seltener konsequent adressiert wird.

Linux Bonding, umgesetzt über den Kernel-Treiber bonding, fasst zwei oder mehr physische Netzwerkschnittstellen zu einem einzigen logischen Interface zusammen, das nach außen wie eine gewöhnliche Netzwerkkarte erscheint. Je nach gewähltem Modus übernimmt der Bond entweder reine Ausfallsicherheit, bei der eine Schnittstelle als Backup bereitsteht, oder echte Lastverteilung über mehrere physische Links hinweg, wodurch sich die nutzbare Bandbreite gegenüber einer einzelnen Verbindung erhöht.

2. Die Bonding-Modi im Überblick: active-backup, LACP und Co.

Der Linux Bonding Treiber unterstützt sieben Modi, von denen in der Praxis vor allem drei relevant sind. Mode 1, active-backup, betreibt zu jedem Zeitpunkt nur eine Schnittstelle aktiv, während die übrige als reine Reserve bereitsteht und bei Ausfall der aktiven Verbindung übernimmt. Dieser Modus benötigt keine spezielle Switch-Konfiguration, weil aus Sicht des Switches immer nur eine MAC-Adresse an einem Port aktiv kommuniziert, was ihn zur einfachsten und robustesten Wahl für reine Redundanz macht.

Mode 4, 802.3ad, auch als LACP bekannt, verhandelt über das Link Aggregation Control Protocol mit dem angeschlossenen Switch eine echte Bündelung mehrerer Links zu einer Link Aggregation Group. Anders als active-backup verteilt LACP den Datenverkehr aktiv über alle beteiligten Links, wodurch sich sowohl Ausfallsicherheit als auch aggregierte Bandbreite ergeben, allerdings nur, wenn der Switch selbst LACP unterstützt und entsprechend konfiguriert wurde. Balance-rr, Mode 0, verteilt Pakete zwar auch über alle Links im Round-Robin-Verfahren, ohne jedoch mit dem Switch zu verhandeln, was in der Praxis häufig zu Problemen mit Paketreihenfolge führt und für die meisten Produktivszenarien ungeeignet ist.

# Verfuegbare Bonding Modi und aktuellen Status eines Bonds pruefen
cat /sys/class/net/bond0/bonding/mode
cat /proc/net/bonding/bond0

3. Switch-Konfiguration: Warum LACP ohne Gegenstelle nicht funktioniert

LACP ist ein Verhandlungsprotokoll zwischen zwei Endpunkten, weshalb der angeschlossene Switch zwingend eine passende Port-Channel- oder Link-Aggregation-Group-Konfiguration benötigt, die dieselben physischen Ports zu einer logischen Gruppe zusammenfasst. Ohne diese Gegenkonfiguration sendet der Server zwar LACP-Kontrollpakete, erhält aber keine Antwort, und der Bond bleibt in einem Zustand, in dem einzelne Slave-Interfaces als nicht aggregierbar markiert werden, obwohl der Bond selbst aktiv erscheint.

Zusätzlich muss die LACP-Rate zwischen Server und Switch übereinstimmen: Der schnelle Modus sendet alle Sekunde ein Kontrollpaket, der langsame Modus alle dreißig Sekunden. Eine Abweichung führt zwar meist nicht zum kompletten Ausfall der Aggregation, verzögert aber die Erkennung eines ausgefallenen Links erheblich, was gerade bei Datenbankservern mit strengen Verfügbarkeitsanforderungen ein unterschätztes Risiko darstellt. Ebenso wichtig ist eine konsistente Hash-Policy auf beiden Seiten, da Switch und Server sonst unterschiedliche Kriterien für die Lastverteilung verwenden und die Bündelung faktisch wirkungslos bleibt.

4. Bond-Konfiguration mit netplan auf Ubuntu Servern

Auf modernen Ubuntu Server Installationen wird Netzwerkkonfiguration standardmäßig über netplan verwaltet, das YAML-Definitionen in systemd-networkd oder NetworkManager übersetzt. Ein LACP-Bond wird dabei als eigener Interface-Typ definiert, der die beteiligten physischen Schnittstellen referenziert und die Bonding-Parameter, insbesondere Modus, LACP-Rate und Hash-Policy für die Lastverteilung, explizit festlegt.

Die transmit-hash-policy bestimmt, nach welchem Kriterium ausgehende Pakete auf die einzelnen physischen Links verteilt werden. layer2 verwendet lediglich MAC-Adressen und führt bei wenigen Kommunikationspartnern häufig zu unausgewogener Lastverteilung, während layer3+4 zusätzlich IP-Adressen und Ports einbezieht und damit für Server mit vielen parallelen TCP-Verbindungen, etwa Datenbank- oder Webserver, die deutlich gleichmäßigere Verteilung liefert.

# /etc/netplan/01-bond0.yaml
network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: no
    enp2s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [enp1s0, enp2s0]
      addresses: [192.168.10.20/24]
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4
      routes:
        - to: default
          via: 192.168.10.1

5. MII-Monitoring und schnelle Ausfallerkennung

Der Bonding-Treiber überwacht die Verfügbarkeit der einzelnen Slave-Interfaces standardmäßig über MII-Monitoring, das den physischen Link-Status der Netzwerkkarte in einem konfigurierbaren Intervall abfragt. Der Parameter mii-monitor-interval, im obigen Beispiel auf 100 Millisekunden gesetzt, bestimmt dabei, wie schnell ein Linkausfall erkannt wird, wobei zu aggressive Werte unter 50 Millisekunden in der Praxis gelegentlich zu Fehlalarmen bei kurzen, harmlosen Link-Flaps führen können.

Alternativ unterstützt der Bonding-Treiber ARP-Monitoring, bei dem gezielt ARP-Anfragen an definierte Zieladressen gesendet werden, um nicht nur den physischen Link-Status, sondern die tatsächliche Erreichbarkeit über den jeweiligen Slave zu prüfen. Dieser Ansatz erkennt zusätzlich Probleme, die MII-Monitoring nicht sieht, etwa einen fehlerhaft konfigurierten Switch-Port, der zwar elektrisch Link zeigt, aber keinen Verkehr weiterleitet, ist im Gegenzug aber komplexer in der Konfiguration und für die meisten Standardszenarien nicht notwendig.

6. Den Bond-Status im laufenden Betrieb überwachen

Die Datei /proc/net/bonding/bond0 liefert den vollständigen Status eines aktiven Bonds, inklusive des aktuell verwendeten Modus, der MII-Status jedes einzelnen Slaves und bei LACP zusätzlich Details zum Aggregations-Status wie Partner-MAC-Adresse und Aggregator-ID. Ein Slave, der als down markiert ist, obwohl die physische Verkabelung intakt scheint, deutet häufig auf eine fehlerhafte Switch-seitige Konfiguration hin und sollte zuerst dort geprüft werden, bevor die lokale Konfiguration in Frage gestellt wird.

Für dauerhaftes Monitoring in Produktionsumgebungen empfiehlt sich die Einbindung des Bond-Status in ein zentrales Monitoring-System, etwa über einen Node Exporter für Prometheus, der die Anzahl aktiver Slaves und deren Zustand regelmäßig auswertet. Ein Alert sollte bereits ausgelöst werden, sobald ein einzelner Slave ausfällt, auch wenn der Bond insgesamt weiterhin funktionsfähig bleibt, da ein unbemerkter Single-Link-Betrieb die eigentlich vorgesehene Redundanz stillschweigend aufhebt.

# Vollstaendigen Status inklusive LACP Partner Informationen anzeigen
cat /proc/net/bonding/bond0

# Anzahl aktiver Slaves für ein einfaches Monitoring Skript extrahieren
grep -c "MII Status: up" /proc/net/bonding/bond0

7. MLAG: Wenn auch der Switch selbst kein Single Point of Failure sein darf

Klassisches LACP bündelt zwar mehrere physische Links, setzt aber voraus, dass alle beteiligten Ports an einem einzigen Switch enden, wodurch der Switch selbst zum verbleibenden Single Point of Failure wird. Multi-Chassis Link Aggregation, kurz MLAG, löst dieses Problem, indem zwei physisch getrennte Switches sich untereinander so koordinieren, dass sie sich gegenüber dem Server als ein einziger logischer LACP-Partner verhalten, obwohl die beiden Kabel des Bonds an unterschiedlichen Geräten enden.

Aus Sicht des Linux-Servers ändert sich an der bonding-Konfiguration selbst nichts, Mode 4 mit denselben Parametern bleibt bestehen, da die gesamte Koordination zwischen den beiden Switches über einen proprietären, herstellerspezifischen Synchronisationskanal erfolgt, der dem Server verborgen bleibt. Für produktive Server-Cluster mit strengen Verfügbarkeitsanforderungen lohnt sich MLAG deutlich, weil es den Ausfallschutz von der Netzwerkkarte über den Link bis hinauf zum Switch selbst durchgängig macht, statt an der letzten Stelle vor dem eigentlichen Netzwerk-Backbone abzureißen.

8. Typische Fehlkonfigurationen und wie sie den Ausfallschutz unbemerkt aushebeln

Der häufigste Fehler ist eine Diskrepanz zwischen der Switch-seitigen Port-Channel-Konfiguration und dem lokalen Bonding-Modus: Wird auf Server-Seite LACP konfiguriert, während der Switch die Ports als statisches EtherChannel ohne LACP-Verhandlung behandelt, kann der Bond zwar funktionieren, verhält sich aber unvorhersehbar bei Linkausfällen, weil beide Seiten unterschiedliche Annahmen über den Zustand der Aggregation treffen.

Ein zweiter Klassiker ist das Bündeln von Netzwerkkarten unterschiedlicher Geschwindigkeit oder unterschiedlichen Duplex-Modus in einem Bond, was bei den meisten Modi entweder zu einer impliziten Begrenzung auf die langsamere Schnittstelle führt oder in Kombination mit LACP von manchen Switches komplett abgelehnt wird. Ebenso unterschätzt wird eine falsch gewählte Hash-Policy: Wird layer2 verwendet, obwohl der gesamte Verkehr über einen einzigen vorgelagerten Router mit fester MAC-Adresse läuft, landet der komplette Datenverkehr trotz mehrerer physischer Links faktisch auf nur einem von ihnen, was die vermeintlich gebündelte Bandbreite in der Praxis nicht liefert.

9. Wann welcher Modus sinnvoll ist: Entscheidungshilfe für die Praxis

Für Umgebungen ohne Kontrolle über die Switch-Konfiguration oder mit strikten Anforderungen an maximale Einfachheit bleibt active-backup die pragmatischste Wahl, da es ohne jede switch-seitige Anpassung funktioniert und dennoch vollständige Ausfallsicherheit gegen den Ausfall eines einzelnen Links oder Switch-Ports bietet. Wo zusätzlich zur Redundanz auch höhere Bandbreite benötigt wird, etwa bei Storage-Netzwerken mit hohem Durchsatzbedarf, führt an LACP kein Weg vorbei, vorausgesetzt die Switch-Infrastruktur unterstützt es und die Konfiguration wird sorgfältig zwischen Netzwerk- und Server-Team abgestimmt.

Broadcast- und balance-rr-Modi haben in modernen Produktionsumgebungen kaum noch praktische Relevanz, da sie entweder unnötige Redundanz-Overhead erzeugen oder, im Fall von balance-rr, Probleme mit der Paketreihenfolge verursachen können, die insbesondere TCP-basierte Anwendungen wie Datenbankverbindungen empfindlich stören. Für die überwiegende Mehrheit produktiver Magento-Hosting-Umgebungen liefert die Kombination aus 802.3ad mit layer3+4 Hash-Policy das beste Verhältnis aus Ausfallsicherheit, Bandbreite und Vorhersagbarkeit.

10. Zusammenfassung

11. FAQ: Netzwerk-Bonding