Aktiv-Backup-Bond unter Linux auf All-Active-EVPN: Was bricht

Setzen Sie einen Aktiv-Backup-Bond auf den Server und ein All-Active-Ethernet-Segment auf das Fabric, und die Hälfte des Rückverkehrs kann verschwinden, ohne dass sich ein einziger Fehlerzähler bewegt. Keine der beiden Konfigurationen ist für sich falsch. Das Problem liegt in der Übergabe zwischen ihnen: Die eine Seite wählt einen einzigen Port, die andere geht davon aus, dass jedes angeschlossene Leaf liefern kann. Verfolgen Sie einen Frame in jede Richtung, und die Diskrepanz wird offensichtlich.

Was Aktiv-Backup mit einem eingehenden Frame macht

Bonding-Modus 1 hält genau einen Slave im Sendepfad und tauscht ihn nur aus, wenn der aktuelle ausfällt. Dieser Teil ist bekannt. Entscheidend ist hier die Empfangsseite: Der Kernel übergibt einen Frame nur dann an den Stack, wenn er auf dem aktiven Slave ankommt, und verwirft Frames, die auf einem anderen Slave erscheinen. Diese all_slaves_active Einstellung existiert genau, um diese Regel zu lockern, und sie ist standardmäßig aus. ip -d link show bond0 gibt den aktuellen Wert neben dem Modus aus.

/proc/net/bonding/bond0 benennt den aktiven Slave und meldet den Linkzustand für jeden Slave. Diese Datei ist die einzige ehrliche Quelle dafür, welcher Port gerade Verkehr trägt.

Ein Host in diesem Modus hat jeweils einen nutzbaren Empfangspfad, lokal gewählt, ohne Kenntnis des Fabrics. Kommt ein Frame für diesen Host über das andere Kabel an, zählt der Switch-Port ihn als empfangen, der Host-Stack sieht ihn nie, und jeder Zähler außer dem eigenen Drop-Zähler des Hosts sieht vollkommen gesund aus.

Was All-Active-Multihoming mit einem entfernten Next Hop macht

EVPN-Multihoming beschreibt eine Menge von Leaves, die ein Ethernet-Segment teilen, das durch eine ESI identifiziert wird, und kündigt dieses Segment im übrigen Fabric an. Im All-Active-Modell installieren entfernte Peers mehr als einen Next Hop für die Adressen des Segments. Unicast zum Server kann dann an beiden Leaves ankommen, und das Fabric darf pro Flow wählen. Das ist der ganze Sinn des Designs und zugleich die Annahme, die der Server-Bond erfüllen muss.

Gefluteter Verkehr folgt einer anderen Regel. Die Leaves wählen pro Segment einen Designated Forwarder, sodass Broadcast, unbekanntes Unicast und Multicast normalerweise über einen von ihnen eintreten. Unicast und Fluten treffen damit zwei getrennte Entscheidungen, und nur eine davon zeigt sich im Bond-Zustand eines Hosts.

Wo die beiden Wahlen auseinandergehen

Der Kernel wählt seinen aktiven Slave aus Linkzustand und eigener Politik. Das Fabric wählt Next Hops aus EVPN-Routen und einen Designated Forwarder aus einer Wahl unter den Leaves. Keiner der beiden Prozesse fragt den anderen. Wählen sie verschiedene Leaves, ist der Fehler richtungsabhängig: Was der Server sendet, verlässt das Netz normal, und die Antworten verschwinden.

Es gibt zwei unterstützte Auswege, und sie sind nicht austauschbar. Geben Sie dem Host einen Bond, den das Fabric als eine logische Anbindung behandeln kann, was praktisch einen mit den Leaves ausgehandelten LACP-Bond bedeutet, und beide Links sind wirklich gemeinsam aktiv. Oder akzeptieren Sie zusätzlich Single-Active-Zustellung aus dem Fabric, sodass das Segment demselben Modell „ein Port zur Zeit“ folgt wie der Bond. Was nicht funktioniert, ist ein All-Active-Segment vor einem Bond, der nur auf einem Port lauscht, es sei denn, Sie aktivieren bewusst den Empfang auf den inaktiven Slaves und akzeptieren die folgende doppelte Zustellung.

Warum das Reservekabel gesund aussieht

Ein Kabel ohne Verkehr meldet trotzdem Link up, und ein Standby-Slave in einem Bond ist darauf ausgelegt, bereit auszusehen. Betreiber lesen das als Redundanz und hören auf zu fragen.

Fragen Sie stattdessen, welchen physischen Port der Rückrahmen benutzt hat. Zählen Sie auf dem Host empfangene Pakete pro Slave statt pro Bond, weil der Bond-Zähler die Asymmetrie verdeckt. Auf dem Leaf schauen Sie auf die Forwarding-Einträge der Bridge für die MAC des Servers und auf die Next-Hop-Menge, die die EVPN-Route trägt. Wenn der Eintrag auf das Leaf zeigt, dessen Host-Link der Standby ist, liefert das Design in einen Port, den der Host ignoriert. Das ist eine Konfigurationsdiskrepanz und kein Hardwarefehler, und keine noch so gründliche Linkzustandsüberwachung wird sie sichtbar machen.

Testen Sie die Zustellung in beide Richtungen, nicht den Linkzustand

Bauen Sie eine Matrix mit einer Zeile pro Fehler und einer Spalte pro Richtung, und tragen Sie dann zugestellten Verkehr statt Schnittstellenzustand ein. Zeile eins ist der Normalbetrieb, und genau dort versteckt sich die Diskrepanz, weil das Symptom wie ein Anwendungsproblem aussieht.

Entfernen Sie dann den aktiven Host-Link, entfernen Sie ein Leaf, entfernen Sie dessen Uplinks, und stellen Sie jedes nacheinander wieder her. Notieren Sie nach jedem Schritt den aktiven Slave, den Zustand des EVPN-Segments, den entfernten Forwarding-Eintrag und den beobachteten Durchsatz in beide Richtungen. Ein Leaf, das seinen Fabric-Pfad verliert, während sein Host-Link oben bleibt, ist der interessante Fall, weil die Anbindung angekündigt bleibt und still zu einer Sackgasse werden kann. Testen Sie mit frischen Unicast-Flows und mit dem gefluteten Verkehr, auf den die Anwendung angewiesen ist, weil beide unterschiedliche Forwarding-Entscheidungen nutzen.

Akzeptieren Sie das Design erst, wenn die Matrix eine bidirektionale Zustellung über den beabsichtigten Pfad zeigt. Zwei Kabel mit Link up sind nicht dieses Ergebnis.