Cisco Unified Computing System (UCS) stellt mit seinen Virtual Interface Cards (VIC) eine direkte Verbindung zu den Fabric Interconnects her. Auf dieser Ebene können Linux‑Betriebssysteme das Bonding‑Subsystem nutzen, um mehrere physische Schnittstellen logisch zu bündeln. Da die VIC‑Karte keinen eigenen Switch darstellt, gelten besondere Einschränkungen für switch‑abhängige Modi wie LACP oder statisches Trunking. In UCS‑Umgebungen werden daher ausschließlich switch‑unabhängige Bonding‑Varianten empfohlen, bei denen die Lastverteilung ausschließlich über die Quell‑MAC‑Adresse erfolgt. Diese Vorgehensweise verhindert MAC‑Flapping zwischen den beiden Fabric Interconnects und sorgt für ein deterministisches Fail‑over‑Verhalten.
Der Linux‑Bonding‑Treiber unterstützt acht Modi (0‑7). Für UCS‑Fabric‑Interconnects sind nur jene Modi sinnvoll, die entweder ein einfaches Fail‑over bereitstellen oder eine Lastverteilung auf Basis der Quell‑MAC‑Adresse durchführen. Im Folgenden werden die relevanten Modi kurz erläutert:
-
Modus 0 – balance‑rr (Round Robin)
Pakete werden nacheinander über alle Slave‑Interfaces gesendet. Da die Verteilung nicht auf der MAC‑Adresse beruht, kann es bei UCS zu ungleichmäßiger Last und potenziellen Flapping‑Problemen kommen. Dieser Modus wird daher nur in sehr speziellen Szenarien empfohlen, in denen die zugrundeliegende Switch‑Topologie die Pakete ausschließlich über einen Fabric Interconnect lässt. -
Modus 1 – active‑backup
Nur ein Slave ist aktiv, die anderen stehen im Standby. Bei Ausfall des aktiven Links wird sofort ein Ersatz übernommen. Dieses Verfahren benötigt keinerlei Switch‑Konfiguration und ist vollständig kompatibel mit der UCS‑Umgebung, weil der Datenverkehr immer über einen einzigen Fabric Interconnect fließt, bis ein Fail‑over eintritt. -
Modus 2 – balance‑xor
Die Slave‑Auswahl erfolgt anhand eines XOR‑Hashes von Quelle und Ziel (MAC, IP oder Port). Die Optionxmit_hash_policyerlaubt es, den Hash auf verschiedene Ebenen zu legen. Für UCS muss die Policy auflayer2(also ausschließlich Quell‑MAC) gesetzt werden, sonst kann das Flapping‑Problem auftreten. Mitxmit_hash_policy=layer2+srcmacentsteht ein stabiler Lastausgleich, der nur die Quell‑MAC berücksichtigt. -
Modus 3 – broadcast
Alle Pakete werden auf jedem Slave gesendet. Dieser Modus erzeugt unnötigen Verkehr und wird in produktiven UCS‑Umgebungen kaum verwendet. -
Modus 4 – 802.3ad (LACP)
Erfordert ein Port‑Channel auf der Gegenstelle. Da der Fabric Interconnect kein LACP‑Partner für die VIC‑Karte sein kann, führt dieser Modus zu MAC‑Flapping und wird nicht unterstützt. -
Modus 5 – balance‑tlb (Adaptive Transmit Load Balancing)
Der ausgehende Verkehr wird basierend auf der aktuellen Last jedes Slave verteilt, eingehender Verkehr wird vom aktuellen Slave empfangen. Da keine besondere Switch‑Konfiguration nötig ist und das Verfahren ausschließlich auf der ausgehenden Seite arbeitet, ist es mit UCS kompatibel, solange das eingehende Traffic‑Handling über einen einzelnen Fabric Interconnect erfolgt. -
Modus 6 – balance‑alb (Adaptive Load Balancing)
Kombiniert TLB mit Empfangs‑Lastausgleich über ARP‑Neversting. Ebenso wie TLB benötigt es keine Switch‑Seite und funktioniert in UCS, wenn das ARP‑Handling nicht zu einer MAC‑Adressen‑Migration zwischen den Fabric Interconnects führt. -
Modus 7 – balance‑tcp (nicht im Kernel‑Standard, gelegentlich als Patch verfügbar)
Nicht Teil der offiziellen Dokumentation für UCS und wird daher nicht weiter betrachtet.
Um bekannte Probleme zu vermeiden, empfiehlt Cisco für die Modi 2, 5 und 6 die Kernel‑Option fail_over_mac=1. Diese Einstellung sorgt dafür, dass bei einem Fail‑over die MAC‑Adresse des neuen aktiven Slaves übernommen wird, wodurch das Aufzeichnen von veralteten MAC‑Einträgen auf den Fabric Interconnects verhindert wird. Ohne diese Option kann es insbesondere bei Modus 2 mit falscher xmit_hash_policy zu dauerhaftem MAC‑Flapping kommen, was zu Leistungseinbußen oder sogar zum Verlust der Netzwerkkonnektivität führen kann.
In der Praxis haben sich folgende Konfigurationen bewährt:
- Active‑Backup (Modus 1) für maximale Einfachheit und höchste Fail‑over‑Zuverlässigkeit.
- Balance‑xor mit
xmit_hash_policy=layer2+srcmac(Modus 2) für einen aktiven‑aktiven Lastausgleich, solange die Pakete ausschließlich über einen Fabric Interconnect geleitet werden. - Balance‑tlb (Modus 5) beziehungsweise balance‑alb (Modus 6), wenn eine dynamische Lastverteilung auf der Senderseite gewünscht wird, ohne dass Switch‑Seite konfiguriert werden muss.
Alle genannten Modi benötigen keinerlei spezielle Switch‑ oder UCS‑Konfiguration außerhalb des Bonding‑Setups selbst. Damit lassen sich Linux‑Hosts an UCS Fabric Interconnects anbinden, während die Vorteile von Redundanz und, falls gewünscht, Lastausgleich erhalten bleiben. Für Umgebungen, die ausschließlich über einen einzigen Fabric Interconnect verbunden sind (z. B. in kleineren Edge‑Deployments), bieten diese Optionen einen stabilen und einfach zu verwaltenden Netzwerkanschluss.