Netzwerk-Bonding erklärt: Alle 7 Modi, Architektur und Konfiguration in der Praxis

Network Bonding — auch NIC Teaming, Link Aggregation oder Ethernet Bonding genannt — ist die Technik, zwei oder mehr physische Netzwerkschnittstellenkarten (NICs) zu einer einzigen logischen Schnittstelle zusammenzufassen, die vom Betriebssystem-Kernel verwaltet wird. Das Ergebnis ist ein einheitliches Netzwerkgerät, das erhöhte aggregierte Bandbreite, automatisches Failover und Lastverteilung über alle Mitgliedsverbindungen gleichzeitig bietet.

Auf Kernel-Ebene bei Linux-Systemen wird Bonding durch das `bonding` Kernel-Modul implementiert, das dem Netzwerk-Stack eine einzige virtuelle Schnittstelle (typischerweise `bond0` genannt) präsentiert. Diese Abstraktion bedeutet, dass Anwendungen, Routing-Tabellen und Firewall-Regeln mit einer Schnittstelle interagieren, unabhängig davon, wie viele physische NICs darunter liegen — ein kritisches architektonisches Detail, das die Verwaltung vereinfacht und gleichzeitig Resilienz auf Enterprise-Niveau bietet.

Warum Network Bonding in Produktionsumgebungen wichtig ist

Bevor wir uns mit den Modi befassen, lohnt es sich zu verstehen, welches Problem Bonding genau löst — und wo es das nicht tut. Ein einzelner Gigabit-Ethernet-Port hat eine harte Obergrenze von etwa 125 MB/s Durchsatz. Für einen Datenbankserver, einen Storage-Node oder eine stark frequentierte Webanwendung wird diese Grenze schnell erreicht. Das Bündeln von zwei 1-GbE-NICs verdoppelt den Durchsatz für einen einzelnen TCP-Stream nicht auf magische Weise (das ist ein weit verbreitetes Missverständnis), ermöglicht aber mehreren gleichzeitigen Flows, beide Links zu sättigen, was die aggregierte Kapazität effektiv verdoppelt.

Über den reinen Durchsatz hinaus eliminiert Bonding den Single Point of Failure, den eine einzelne NIC oder ein einzelnes Kabel darstellt. In Umgebungen, in denen Verfügbarkeit in Neunen gemessen wird, ist das enorm wichtig.

Kernvorteile auf einen Blick

• Aggregierte Bandbreite: Mehrere physische Links tragen zum Gesamtdurchsatz für gleichzeitige Traffic-Flows bei
• Automatisches Failover: Linkausfall-Erkennung (über MII- oder ARP-Monitoring) löst eine Umschaltung unter einer Sekunde auf eine funktionierende Schnittstelle aus
• Lastverteilung: Traffic wird gemäß dem aktiven Bonding-Algorithmus auf die Mitgliedsschnittstellen verteilt
• Transparent für Anwendungen: Die Bond-Schnittstelle hat eine einzige MAC-Adresse und IP, ohne dass Änderungen auf Anwendungsebene erforderlich sind
• Hardware-Kosteneffizienz: Das Bündeln von Standard-NICs kann in manchen Szenarien kostengünstiger sein als das Upgrade auf eine einzelne 10-GbE-Karte

Network Bonding Architektur: Wie es unter der Haube funktioniert

Der Linux-Kernel-Bonding-Treiber arbeitet zwischen Layer 2 (Data Link) und den physischen NIC-Treibern. Wenn ein Frame übertragen wird, wählt die Übertragungsrichtlinie des Bonding-Treibers aus, welche Slave-Schnittstelle verwendet werden soll. Beim Empfang leiten alle Slave-Schnittstellen Frames an den Bond-Master weiter, der sie dedupliziert und an den Netzwerk-Stack übergibt.

Link-Monitoring ist der Mechanismus, der Ausfälle erkennt. Es gibt zwei Methoden:

• MII (Media Independent Interface) Monitoring: Fragt den physischen Link-Status jeder NIC in einem konfigurierbaren Intervall ab (Parameter `miimon`, typischerweise 100ms). Schnell und zuverlässig für die Erkennung von Kabelzügen oder NIC-Ausfällen.
• ARP-Monitoring: Sendet ARP-Anfragen an eine Ziel-IP und wartet auf Antworten. Nützlicher, wenn Sie die End-to-End-Konnektivität statt nur den physischen Link-Status überprüfen möchten, führt aber eine Abhängigkeit von einem erreichbaren ARP-Ziel ein.

Die Parameter `downdelay` und `updelay` fügen Hysterese hinzu — um schnelles Flapping zu verhindern, wenn ein Link schwankt. Diese auf jeweils 200ms zu setzen ist eine übliche Produktions-Baseline.

Alle 7 Linux Bonding Modi: Technischer Deep Dive

Der Linux-Bonding-Treiber definiert sieben verschiedene Modi (0 bis 6). Jeder implementiert eine andere Übertragungsrichtlinie und ein anderes Failover-Verhalten. Die Wahl des falschen Modus ist eine der häufigsten Fehlkonfigurationen bei Server-Deployments.

Modus 0 — Round-Robin (balance-rr)

Pakete werden sequenziell über alle aktiven Slave-Schnittstellen in rotierender Reihenfolge übertragen: Paket 1 auf eth0, Paket 2 auf eth1, Paket 3 auf eth0 und so weiter.

Was tatsächlich passiert: Round-Robin arbeitet auf Paketebene, nicht auf Flow-Ebene. Das bedeutet, dass eine einzelne TCP-Verbindung ihre Pakete außer der Reihe geliefert bekommen kann, wenn die beiden Pfade unterschiedliche Latenz haben. Der TCP-Stack des empfangenden Hosts wird sie neu ordnen, aber das verursacht in der Praxis Neuübertragungen und Durchsatzverschlechterung — besonders bei großen Dateiübertragungen über eine einzelne Verbindung bemerkbar.

Switch-Anforderung: Die Switch-Ports müssen als statische LAG (Link Aggregation Group) ohne LACP konfiguriert sein. Ohne dies sieht der Switch Frames von derselben MAC-Adresse, die auf mehreren Ports ankommen, und kann eine Loop-Protection-Abschaltung auslösen.

Beste Verwendung: Massenübertragungsworkloads mit vielen gleichzeitigen kurzlebigen Verbindungen, bei denen paketweise Neuordnung tolerierbar ist.

Modus 1 — Active-Backup

Zu jedem Zeitpunkt ist nur eine Slave-Schnittstelle aktiv. Alle anderen befinden sich in einem Hot-Standby-Zustand. Wenn der aktive Link ausfällt (erkannt über MII- oder ARP-Monitoring), befördert der Bonding-Treiber einen Backup-Slave und sendet ein Gratuitous ARP, um die MAC-Adresstabellen des Netzwerks zu aktualisieren.

Kritische Nuance: Im Active-Backup-Modus präsentiert die Bond-Schnittstelle dem Netzwerk immer dieselbe MAC-Adresse (die MAC des aktuell aktiven Slave). Das bedeutet, dass keine spezielle Switch-Konfiguration erforderlich ist — aus Sicht des Switches ist es eine normale Einzelhost-Verbindung. Dies ist der einzige Modus, der auf Switches ohne LAG-Konfiguration korrekt funktioniert.

Failover-Timing: Mit `miimon=100`, `downdelay=200`, `updelay=200` können Sie ein Failover in etwa 200–300ms erwarten — schnell genug, um TCP-Session-Drops in den meisten Fällen zu vermeiden.

Beste Verwendung: Hochverfügbarkeitsszenarien, bei denen Einfachheit und Kompatibilität wichtiger sind als Bandbreite — Management-Schnittstellen, Out-of-Band-Zugang oder jede Umgebung, in der der Switch nicht unter Ihrer Kontrolle steht.

Modus 2 — Balance-XOR

Traffic wird mithilfe einer auf jedes Paket angewendeten ÜbertragungsHash-Richtlinie verteilt. Der Standard-Hash ist `(source_MAC XOR destination_MAC) modulo slave_count`. Richtlinien auf höherer Ebene (`layer3+4`) verwenden IP-Adressen und Portnummern für eine bessere Verteilung.

Die layer3+4-Richtlinie: Die Konfiguration von `xmit_hash_policy=layer3+4` verbessert die Verteilung erheblich, indem auf Quell-IP, Ziel-IP, Quellport und Zielport gehasht wird. Dies stellt sicher, dass verschiedene TCP-Flows zum selben Zielserver über Links verteilt werden, was der Standard-MAC-basierte Hash nicht erreichen kann.

Switch-Anforderung: Statische LAG-Konfiguration am Switch (wie Modus 0), aber ohne das Problem der Paket-Neuordnung, da alle Pakete innerhalb eines einzelnen Flows dieselbe Schnittstelle durchlaufen.

Beste Verwendung: Umgebungen, die Load Balancing ohne LACP-Unterstützung benötigen, insbesondere in Kombination mit der `layer3+4` Hash-Richtlinie.

Modus 3 — Broadcast

Jedes Paket wird gleichzeitig auf allen Slave-Schnittstellen übertragen. Jeder Slave sendet eine identische Kopie jedes Frames.

Wann das tatsächlich nützlich ist: Der Broadcast-Modus dreht sich nicht um Bandbreite — es geht um garantierte Zustellung an mehrere Netzwerksegmente gleichzeitig. Er wird in spezialisierten Hochverfügbarkeits-Clustering-Szenarien verwendet, in denen zwei separate Switches oder Netzwerkpfade jedes Paket empfangen müssen (zum Beispiel bestimmte Storage-Replikations- oder Finanzhandelssysteme mit redundanten Netzwerkfabrics). Er wird auch in einigen Netzwerk-Monitoring-Setups verwendet.

Die Bandbreitenkosten: Mit zwei NICs im Broadcast-Modus verbrauchen Sie für jedes Paket die 2-fache Bandbreite auf der Leitung. Mit vier NICs die 4-fache. Dieser Modus sollte niemals für allgemeinen Traffic verwendet werden.

Modus 4 — 802.3ad / LACP (Dynamic Link Aggregation)

Dies ist der IEEE 802.3ad-Standard, implementiert über das Link Aggregation Control Protocol (LACP). Der Bonding-Treiber und der Switch tauschen LACP PDUs (Protocol Data Units) aus, um dynamisch auszuhandeln, welche Links die Aggregationsgruppe bilden, ihre Parameter und ihren Zustand.

Wie LACP-Aushandlung funktioniert: Jede Seite sendet LACPDUs, die ihre Systempriorität, Port-Priorität und den Aggregationsschlüssel ankündigen. Links mit übereinstimmenden Schlüsseln auf beiden Seiten bilden eine LAG. Wenn ein Link ausfällt, erkennt LACP dies und entfernt ihn ohne manuelle Eingriffe aus der Gruppe.

Übertragungs-Hash-Richtlinie: Wie Modus 2 verwendet Modus 4 eine Hash-Richtlinie für die Lastverteilung. Die `layer3+4` Richtlinie wird auch hier dringend empfohlen. Beachten Sie, dass LACP keine paketweise Lastverteilung garantiert — es verteilt Flows über Links, sodass eine einzelne große Dateiübertragung immer noch nur einen physischen Link verwendet.

Switch-Konfiguration: Der Switch muss LACP auf dem entsprechenden Port-Channel aktiviert haben. Nicht übereinstimmende LACP-Modi (aktiv vs. passiv) sind eine häufige Ursache für Bonding-Fehler. Beide Seiten können auf `active` gesetzt werden, um sicherzustellen, dass die Aushandlung immer fortschreitet.

Beste Verwendung: Rechenzentren, Hochleistungsserver und jede Umgebung, in der Sie die Switch-Konfiguration kontrollieren. Dies ist der Goldstandard für Produktions-Bonding, wenn Switch-Unterstützung verfügbar ist.

Modus 5 — Balance-TLB (Adaptive Transmit Load Balancing)

Modus 5 verteilt ausgehenden Traffic auf alle Slaves basierend auf der aktuellen Last jeder Schnittstelle (der am wenigsten belastete Slave erhält das nächste ausgehende Paket). Eingehender Traffic wird nur auf einem einzigen designierten Slave empfangen.

Der entscheidende Vorteil: Es ist keinerlei Switch-Konfiguration erforderlich. Die Bond-Schnittstelle verwendet unterschiedliche Quell-MAC-Adressen pro Slave für ausgehenden Traffic, was ein gültiges Verhalten ist, das jeder Switch transparent handhabt.

Die Einschränkung: Eingehender Traffic wird nicht ausgeglichen. Wenn Ihr Server hauptsächlich große Datenmengen empfängt (ein Download-Server, ein Datenbankreplikat, das Replikations-Streams empfängt), bietet Modus 5 für diese Richtung keinen Vorteil. Wenn Ihr Server hauptsächlich Daten sendet, ist Modus 5 sehr effektiv.

Failover-Verhalten: Wenn der empfangende Slave ausfällt, übernimmt ein anderer Slave die Empfangsrolle. Die ausgehende Lastverteilung wird auf den verbleibenden Slaves fortgesetzt.

Modus 6 — Balance-ALB (Adaptive Load Balancing)

Modus 6 erweitert Modus 5 durch das Hinzufügen von eingehendem Load Balancing durch ARP-Aushandlung. Der Bonding-Treiber sendet periodisch ARP-Antworten mit unterschiedlichen Quell-MAC-Adressen an verschiedene Clients, wodurch diese Clients Return-Traffic an verschiedene Slave-Schnittstellen senden.

Der ARP-Manipulationsmechanismus: Das ist der clevere Teil. Der Treiber fängt ARP-Antworten ab und rotiert die Quell-MAC-Adresse unter den Slaves. Clients cachen diese ARP-Einträge und leiten ihren Traffic an die Slave-MAC, die sie gelernt haben. Dies erreicht eingehendes Load Balancing ohne jegliche switch-seitige Konfiguration.

Praktischer Vorbehalt: Das ARP-basierte eingehende Balancing funktioniert nur für Hosts, die kürzlich mit dem gebondeten Server kommuniziert haben. Neue Verbindungen kommen immer auf dem primären Slave an, bis eine ARP-Antwort gesendet wird. In Szenarien mit hoher Verbindungsrate kann die eingehende Verteilung ungleichmäßig sein.

Beste Verwendung: Umgebungen ohne LACP-fähige Switches, die bidirektionales Load Balancing benötigen. Eine solide Wahl für VPS Hosting-Umgebungen, in denen der virtuelle Switch des Hypervisors möglicherweise kein LACP unterstützt.

Bonding-Modus-Vergleichstabelle

Network Bonding unter Linux konfigurieren

Voraussetzungen

“`bash

Verify bonding module is available

modinfo bonding

Load the module if not already loaded

modprobe bonding

“`

Konfiguration über systemd-networkd (Moderner Ansatz)

Erstellen Sie `/etc/systemd/network/bond0.netdev`:

“`ini

[NetDev]

Name=bond0

Kind=bond

[Bond]

Mode=802.3ad

TransmitHashPolicy=layer3+4

MIIMonitorSec=100ms

LACPTransmitRate=fast

“`

Erstellen Sie `/etc/systemd/network/bond0.network`:

“`ini

[Match]

Name=bond0

[Network]

Address=192.168.1.10/24

Gateway=192.168.1.1

“`

Erstellen Sie `/etc/systemd/network/eth0.network` und `eth1.network`:

“`ini

[Match]

Name=eth0

[Network]

Bond=bond0

“`

Konfiguration über `/etc/network/interfaces` (Debian/Ubuntu)

“`bash

auto bond0

iface bond0 inet static

address 192.168.1.10

netmask 255.255.255.0

gateway 192.168.1.1

bond-slaves eth0 eth1

bond-mode 4

bond-miimon 100

bond-lacp-rate 1

bond-xmit-hash-policy layer3+4

auto eth0

iface eth0 inet manual

bond-master bond0

auto eth1

iface eth1 inet manual

bond-master bond0

“`

Bond-Status überprüfen

“`bash

Check bond status and slave states

cat /proc/net/bonding/bond0

Monitor interface statistics

ip -s link show bond0

Check LACP negotiation state (Mode 4)

cat /proc/net/bonding/bond0 | grep -A5 "LACP"

“`

Die `/proc/net/bonding/bond0`-Ausgabe ist das wichtigste Diagnosewerkzeug. Sie zeigt den aktiven Slave, den Link-Status jedes Mitglieds, den MII-Status und (für Modus 4) LACP-Partner-Informationen.

Network Bonding auf Dedicated Servern und VPS

Auf Bare-Metal-Dedicated Servern haben Sie die volle Kontrolle über die NIC-Konfiguration des Servers und (typischerweise) die Switch-Port-Konfiguration, was Modus 4 (LACP) zur natürlichen Wahl für Produktionsworkloads macht. Die meisten Rechenzentrumsanbieter können LACP auf Ihren Switch-Ports auf Anfrage konfigurieren.

In VPS mit cPanel-Umgebungen handhabt die virtuelle Netzwerkschicht des Hypervisors das zugrunde liegende Bonding auf Host-Ebene. Die Gast-VM sieht typischerweise eine einzelne virtuelle NIC, aber der Host kann darunter gebondete physische Schnittstellen betreiben — was Redundanz transparent bereitstellt.

Bei der Bereitstellung GPU-intensiver Workloads auf GPU Hosting-Infrastruktur wird Network Bonding entscheidend, um GPU-Nodes schnell genug mit Daten zu versorgen und I/O-Starvation zu verhindern. Trainings-Pipelines und Inferenz-Serving profitieren beide von der aggregierten Bandbreite, die LACP-Bonding bietet.

Häufige Fallstricke und Sonderfälle

Spanning Tree Protocol (STP)-Konflikte: Beim Hinzufügen gebondeter Ports zu einem Switch kann STP die Ports während der Aushandlung vorübergehend blockieren. Konfigurieren Sie PortFast (oder Äquivalent) auf den Switch-Ports, um 30-Sekunden-Verzögerungen bei Link-Up-Ereignissen zu verhindern.

MTU-Mismatches: Alle Slave-Schnittstellen in einem Bond müssen identische MTU-Einstellungen haben. Ein Mismatch verursacht intermittierenden Paketverlust, der extrem schwer zu diagnostizieren ist. Überprüfen Sie immer mit `ip link show` nach der Konfiguration.

LACP-Timeout-Modi: LACP unterstützt „slow” (30-Sekunden) und „fast” (1-Sekunden) Timeout-Modi. Verwenden Sie in der Produktion immer `lacp-rate fast` (`bond-lacp-rate 1`). Der Slow-Modus bedeutet, dass ein ausgefallener Link bis zu 90 Sekunden braucht, um aus der LAG entfernt zu werden.

Live-Migration virtueller Maschinen: Wenn eine VM mit einer gebondeten Schnittstelle auf einen anderen Host migriert wird, können sich die MAC-Adressen des Bonds je nach Hypervisor ändern. Dies kann veraltete ARP-Cache-Einträge und kurzen Konnektivitätsverlust verursachen. Bereiten Sie Gratuitous ARPs in Ihren Migrationsskripten vor.

Asymmetrisches Hashing: Bei Modus 4 und `layer3+4`-Hashing kann Traffic von Server A zu Server B eth0 durchlaufen, während Return-Traffic von B zu A eth1 auf Bs Bond durchläuft. Das ist normal und erwartet — jeder Endpunkt hasht seinen ausgehenden Traffic unabhängig.

NetworkManager-Interferenz: Auf RHEL/CentOS-Systemen kann NetworkManager manuell konfigurierte Bonds stören. Konfigurieren Sie Bonds entweder über NetworkManagers nmcli-Schnittstelle oder deaktivieren Sie NetworkManager für die relevanten Schnittstellen mit `NM_CONTROLLED=no` in der Schnittstellenkonfigurationsdatei.

Bonding vs. andere Hochverfügbarkeits-Netzwerktechniken

Network Bonding ist nicht der einzige Ansatz für NIC-Redundanz. Es ist ebenso wichtig zu verstehen, wann Alternativen verwendet werden sollten.

MLAG (Multi-Chassis Link Aggregation) verdient besondere Erwähnung: Es ermöglicht einem Server mit Modus-4-Bonding, seine zwei NICs mit zwei physisch getrennten Switches zu verbinden, die beide an derselben logischen LAG teilnehmen. Dies eliminiert den Switch selbst als Single Point of Failure — ein Redundanzniveau, das Standard-Single-Switch-LACP nicht bieten kann.

Entscheidungsmatrix: Den richtigen Bonding-Modus wählen

Verwenden Sie dieses Framework zur Auswahl Ihres Bonding-Modus:

Kontrollieren Sie die Switch-Konfiguration?

• Nein → Gehen Sie zu Modus 1, 5 oder 6
• Bidirektionales Load Balancing benötigt? → Modus 6
• Überwiegend ausgehender Traffic? → Modus 5
• Reines Failover, maximale Einfachheit? → Modus 1
• Ja → Gehen Sie zu Modus 0, 2 oder 4
• Dynamische Aushandlung und Best-Practice-Konformität benötigt? → Modus 4 (LACP)
• Statische LAG, einfacheres Setup? → Modus 2 mit layer3+4-Hash
• Spezialisierte Broadcast-Anforderung? → Modus 3

Ist dies eine Management/IPMI-Schnittstelle? Verwenden Sie immer Modus 1. Riskieren Sie niemals eine Management-Schnittstelle mit einem Modus, der Switch-Konfiguration erfordert.

Sind Sie auf einer Cloud- oder virtuellen Plattform? Prüfen Sie, ob der virtuelle Switch des Hypervisors LACP unterstützt. Falls nicht, bietet Modus 6 die beste Balance aus Lastverteilung und Kompatibilität.

Für Teams, die mehrere Server über VPS Control Panels verwalten, sollte die Überprüfung des Bonding-Status Teil der Standard-Post-Deployment-Checkliste sein, zusammen mit der SSL-Überprüfung über SSL Certificates und DNS-Propagationsprüfungen nach der Domain Registration.

Technische Schlüssel-Checkliste

• Setzen Sie immer `miimon=100` und `downdelay=200 updelay=200` als Baseline für MII-Monitoring in der Produktion
• Verwenden Sie `xmit_hash_policy=layer3+4` mit Modus 2 und Modus 4, um Flow-Level-Verteilung statt MAC-Level-Verteilung sicherzustellen
• Überprüfen Sie `/proc/net/bonding/bond0` unmittelbar nach der Konfiguration — nehmen Sie nicht an, dass es funktioniert
• Konfigurieren Sie die LACP-Rate auf `fast` in Modus 4, um die Failover-Erkennungszeit von 90 Sekunden auf 3 Sekunden zu reduzieren
• Stellen Sie sicher, dass alle Slave-NICs identische MTU-, Geschwindigkeits- und Duplex-Einstellungen haben, bevor Sie sie zu einem Bond hinzufügen
• Fordern Sie auf Produktions-Dedicated Servern immer LACP-Konfiguration von Ihrem Rechenzentrumsanbieter an, anstatt statische LAG zu verwenden
• Testen Sie Failover explizit durch Abziehen eines Kabels — nehmen Sie nicht an, dass die Konfiguration korrekt ist, bis Sie sie unter Ausfallbedingungen überprüft haben
• Dokumentieren Sie, welche physische NIC welchem Slave (eth0, eth1) entspricht, mithilfe von `ethtool -i eth0`, um Verwirrung bei physischer Wartung zu vermeiden
• Untersuchen Sie für Cross-Switch-Redundanz in kritischen Umgebungen MLAG, bevor Sie sich mit Single-Switch-LACP zufriedengeben

FAQ

Verdoppelt Network Bonding die Geschwindigkeit eines einzelnen Datei-Downloads?

Nein. Bonding verteilt Traffic über Links auf Flow-Ebene (oder Paketebene in Modus 0). Eine einzelne TCP-Verbindung verwendet in den meisten Modi jeweils nur einen physischen Link. Bonding erhöht den aggregierten Durchsatz über mehrere gleichzeitige Verbindungen, nicht die Geschwindigkeit einer einzelnen Verbindung.

Was ist der Unterschied zwischen Bonding-Modus 4 (LACP) und einer statischen LAG?

Eine statische LAG (verwendet von Modus 0 und 2) definiert manuell, welche Ports die Aggregationsgruppe bilden, ohne Aushandlung. LACP (Modus 4) handelt die LAG dynamisch mithilfe von Steuerungspaketen aus, erkennt automatisch Fehlkonfigurationen, ausgefallene Links und fügt Mitglieder hinzu oder entfernt sie. LACP ist robuster und ist der Industriestandard für Produktions-Deployments.

Kann ich Network Bonding auf einem VPS konfigurieren?

Das hängt vom Hypervisor und Hosting-Anbieter ab. Die meisten Cloud-VPS-Instanzen präsentieren dem Gast eine einzelne virtuelle NIC, wobei Bonding auf Hypervisor-Ebene gehandhabt wird. Einige Anbieter, die Bare-Metal-ähnliche VPS oder dedizierte Cloud-Instanzen anbieten, unterstützen Bonding auf Gast-Ebene. Erkundigen Sie sich bei Ihrem Anbieter, bevor Sie versuchen, Bonding innerhalb eines VPS-Gastes zu konfigurieren.

Was passiert mit aktiven Verbindungen, wenn ein gebondeter Link ausfällt?

In Modus 1 (Active-Backup) sendet der Bond nach dem Failover ein Gratuitous ARP und aktualisiert die Switch-MAC-Tabellen. Bestehende TCP-Verbindungen erleben eine kurze Pause (typischerweise unter 300ms bei schnellem MII-Monitoring), überleben aber im Allgemeinen. In Modus 4 erkennt LACP den Ausfall und verteilt Flows auf überlebende Links um — bestehende Flows auf dem ausgefallenen Link müssen von der Anwendung neu aufgebaut werden.

Warum zeigt mein Modus-4-Bond in `/proc/net/bonding/bond0` nur einen aktiven Slave?

Die häufigste Ursache ist eine switch-seitige Fehlkonfiguration. Überprüfen Sie, ob die Switch-Ports im selben Port-Channel mit aktiviertem LACP im aktiven Modus konfiguriert sind. Prüfen Sie auch, ob `lacp-rate` auf beiden Seiten konsistent gesetzt ist. Ein nicht übereinstimmender LACP-Schlüssel oder eine nicht übereinstimmende Systempriorität kann die Aggregation verhindern, selbst wenn physische Links aktiv sind.