MLAG/VSX/vPC Split-Brain: Früherkennung und Response-Plan

Ein MLAG/VSX/vPC Split-Brain ist einer der kritischsten Failure Modes in modernen Rechenzentrums- und Campus-Netzen, weil er Redundanzmechanismen in ihr Gegenteil verkehren kann: Statt „zwei Geräte wie ein Switch“ zu verhalten, agieren beide Peers gleichzeitig eigenständig – oft mit widersprüchlichen Forwarding-Entscheidungen. Das führt nicht nur zu Paketverlust, sondern häufig zu MAC-Flapping, Blackholing, Broadcast-Stürmen oder sogar Layer-2-Loops, die sich domänenweit ausbreiten können. In der Praxis tritt Split-Brain selten „aus dem Nichts“ auf. Meist gibt es Vorzeichen: ein instabiler Peer-Link, ein gestörter Keepalive, inkonsistente State-Synchronisation, ein Timing-Problem nach Reload oder ein Change, der die Kontrollpfade beeinflusst. Für NOC- und On-Call-Teams ist deshalb ein zweigeteilter Ansatz entscheidend: erstens Früherkennung über klare, messbare Signale (bevor die Produktion kippt), zweitens ein Response-Plan, der unter Zeitdruck sichere, reversible Schritte vorgibt. Dieser Artikel erklärt, wie Split-Brain in MLAG-Varianten wie Cisco vPC und Aruba/HP VSX typischerweise entsteht, welche Symptome wirklich aussagekräftig sind, wie Sie die Fault Domain schnell begrenzen und welche präventiven Guardrails Split-Brain selten machen.

Begriffe und Architektur: Was MLAG, vPC und VSX gemeinsam haben

Auch wenn die Produktnamen unterschiedlich sind, verfolgen MLAG-Designs (Multi-Chassis Link Aggregation) das gleiche Ziel: Zwei physische Switches bilden für Downstream-Geräte (z. B. Server, ToR-Hosts, Access-Switches) ein gemeinsames, redundantes Gegenüber. Dazu benötigen die Peers Synchronisation und Koordination über zwei logische Pfade:

• Peer-Link/ISL: Dataplane- und/oder Controlplane-Verbindung zwischen den Peers. Je nach Implementierung trägt er zusätzlich „Peer-Forwarding“ und Synchronisation.
• Keepalive: separater Lebenszeichen-Pfad, der bei Peer-Link-Störungen helfen soll, Split-Brain zu vermeiden.
• State Synchronisation: Austausch von MAC-Tabellen, ARP/ND-Zuständen, LACP/Port-Channel-Informationen und ggf. FHRP/Anycast-Status.

Im Hintergrund bleiben VLAN-Tagging und Bridging-Grundlagen maßgeblich. Für VLAN- und Bridging-Mechanismen ist IEEE 802.1Q die zentrale Referenz. Für Link Aggregation und LACP ist IEEE 802.1AX relevant, da LACP-Status und Hashing-Verhalten Split-Brain-Symptome verstärken oder kaschieren können.

Was „Split-Brain“ in MLAG-Kontext konkret bedeutet

Von Split-Brain spricht man, wenn beide Peers gleichzeitig glauben, sie seien (allein) in einem gültigen Betriebszustand und daher aktiv forwarden dürfen, obwohl die Koordination zwischen ihnen gestört ist. Das kann zwei Formen annehmen:

• Hard Split: Peer-Link ist down oder unbrauchbar, Keepalive ist ebenfalls gestört oder liefert widersprüchliche Informationen.
• Soft Split: Peer-Link ist zwar up, aber State-Synchronisation ist inkonsistent (z. B. VLAN/Port-Channel-Divergenz, Sync-Prozess hängt, Controlplane-Überlast).

Das Gefährliche: Split-Brain ist nicht nur ein „Controlplane-Problem“. Er manifestiert sich in der Datenebene: MAC-Tabellen driften, ARP/ND-Einträge werden unterschiedlich gehandhabt, und Downstream-LAGs können auf beiden Peers gleichzeitig als aktiv erscheinen, obwohl sie es aus Sicht eines „virtuellen Switches“ nicht dürften.

Warum Split-Brain so eskaliert: Typische Schadensbilder

Split-Brain erzeugt häufig eine Mischung aus scheinbar unzusammenhängenden Symptomen. Ein Response-Plan muss deshalb auf wenige, starke Indikatoren fokussieren, um nicht in „Symptom-Jagd“ zu enden.

• MAC-Flapping/MAC-Moves: dieselben MACs wechseln schnell zwischen Peer A und Peer B oder zwischen Downstream-Uplinks.
• ARP-/ND-Anomalien: ARP-Requests bleiben unbeantwortet, „incomplete“ Einträge häufen sich, Gateway-Reachability ist intermittierend.
• Blackholing: Bestimmte Flows verschwinden, während andere funktionieren (häufig hash- oder asymmetriebedingt).
• Broadcast/Unknown-Unicast steigt: durch instabiles Learning und Flooding in falsche Pfade.
• STP/Loop-Risiko: wenn das Design nicht strikt loopfrei ist oder Guardrails fehlen, kann Split-Brain Loops begünstigen.
• CPU- und Controlplane-Last: Logging, Sync-Retries, MAC-Move-Events und TCNs können Geräte in die Knie zwingen.

Früherkennung: Die besten Leading Indicators für Split-Brain

Früherkennung bedeutet: Signale finden, die vor dem großflächigen Ausfall sichtbar werden. Dafür eignen sich insbesondere Statusindikatoren der Peer-Beziehung und Metriken, die Drift und Asymmetrie abbilden.

• Peer-Link Degradation: Fehlerzähler, Drops, CRC/Symbol Errors, FEC-Probleme, Microbursts/Discards auf dem Peer-Link.
• Keepalive Jitter/Loss: erhöhte Latenz oder Paketverlust auf dem Keepalive-Pfad, insbesondere wenn er über ein Out-of-Band-Netz läuft.
• Split-Role Flags: Plattform-spezifische Zustände wie „peer not alive“, „dual-active“, „split active“, „orphan ports active“.
• MAC-Move-Rate: plötzlicher Anstieg der MAC-Moves in den VLANs, die über MLAG laufen.
• Asymmetrische Member-Utilization: starke Unwucht in den LAG-Membern kann Hinweis auf unidirektionale Fehler oder Hashing-Pathologie sein, die Split-Brain triggern kann.

Split-Brain-Frühwarnscore als kombinierte Kennzahl (MathML)

$\mathrm{SBScore}=w{1}_{}\times \mathrm{PeerLinkLoss}+w{2}_{}\times \mathrm{KeepaliveLoss}+w{3}_{}\times \mathrm{MACMoveRate}$

Im NOC reicht oft ein pragmatischer Ansatz: PeerLinkLoss und KeepaliveLoss als Prozentwerte im Zeitfenster (z. B. 1–5 Minuten), MACMoveRate als Moves pro Minute. Die Gewichte w1–w3 können initial gleich gesetzt werden, bis Erfahrungswerte vorliegen. Wichtig ist nicht „perfekte Mathematik“, sondern eine wiederholbare Alarmierung, die echte Vorfälle früh sichtbar macht.

Typische Ursachen: Wie Split-Brain in der Praxis entsteht

Split-Brain ist fast immer ein Kettenereignis. Häufig beginnt es mit einem „kleinen“ Problem, das in Kombination mit Topologie, Timings oder Fehlkonfiguration eskaliert.

• Peer-Link Instabilität: CRC/Errors, Optikprobleme, fehlerhafte LAG-Konfiguration des Peer-Links, MTU-Mismatch auf dem ISL.
• Keepalive nicht wirklich unabhängig: Keepalive läuft über denselben Failure Domain wie der Peer-Link (z. B. gleiche ToR-Fabric), fällt also gleichzeitig aus.
• Controlplane-Überlast: hohe MAC-Move-Raten, Broadcast-Storms oder Logging-Fluten blockieren Sync-Prozesse.
• Konfigurationsdrift: VLAN-Allowed-Listen, Native VLAN/PVID oder Port-Channel-Profile sind zwischen den Peers inkonsistent.
• Asymmetrische Softwarestände: unterschiedliche Firmware/Features führen zu abweichendem Verhalten nach Reload oder Failover.
• Orphan Ports: Ports, die nur an einem Peer hängen, werden im falschen Zustand aktiv, wenn Peer-Status unklar ist.

Symptome sauber trennen: Split-Brain vs. „normale“ LACP- oder VLAN-Probleme

Viele Indikatoren überschneiden sich mit klassischen L2-Störungen. Deshalb ist die Abgrenzung wichtig: Ein VLAN-Mismatch kann „nur ein VLAN kaputt“ erzeugen; ein unidirektionaler Link kann Hashing-ähnliche Ausfälle verursachen. Split-Brain erkennen Sie meist daran, dass Koordinationssignale der Peers und Drift-Symptome gleichzeitig auftreten.

• Misconfig (VLAN/LACP): meist stabil reproduzierbar, betrifft klar definierte VLANs/Port-Channels, ohne Peer-Role-Alarme.
• Unidirektional: per-member Rx/Tx stark asymmetrisch, häufig auf einem einzelnen Link; Peer-Status bleibt oft konsistent.
• Split-Brain: Peer-Role-/Dual-Active-Indikatoren plus breit verteiltes MAC-Flapping/ARP-Anomalien.

Response-Plan: Sofortmaßnahmen, die den Schaden begrenzen

Ein guter Response-Plan setzt auf Safety First: Die falsche Maßnahme kann aus einem Partial Outage einen Full Outage machen. Ziel ist, die Datenebene schnell zu stabilisieren, ohne unnötige Rekonvergenzen zu triggern.

• 1) Scope bestimmen: Welche VLANs, welche Downstream-LAGs, welche Services sind betroffen? Ist es auf ein MLAG-Paar begrenzt?
• 2) Peer-Health prüfen: Peer-Link Status, Keepalive Status, Dual-Active-/Split-Flags, Sync-Status.
• 3) Drift-Symptome messen: MACMoveRate, ARP/ND-Anomalien, Broadcast/Unknown-Unicast, CPU/Controlplane.
• 4) Fault Domain verkleinern: Wenn möglich, betroffene Downstream-Links isolieren, bevor Core/Peer-Link angefasst wird.
• 5) Entscheiden: „Welcher Peer bleibt aktiv?“ Ziel ist, einen eindeutigen Active-Zustand herzustellen.

Warum „ein Peer hart abschalten“ nicht immer die beste erste Option ist

Ein „hartes“ Abschalten (Power off/Reload) kann zwar sofort Split-Brain beenden, erzeugt aber auch massive Rekonvergenz und kann Datenverlust verstärken, wenn gleichzeitig andere Fehler aktiv sind. Außerdem kann es die Beweislage vernichten (Logs, Zustände, Counters). Im NOC-Kontext ist es besser, zuerst den stabileren Pfad zu wählen und die Aktion so zu gestalten, dass sie reversibel bleibt.

Response-Plan: Sichere Entscheidungslogik bei Dual-Active

Wenn Dual-Active/Split-Brain bestätigt ist, muss die Umgebung so schnell wie möglich zu einem eindeutigen Forwarding-Zustand zurückkehren. In vielen Designs gibt es Mechanismen wie „dual-active detection“ und „orphan port handling“, die automatisch Ports blockieren. Ihr Plan sollte dennoch eine manuelle Entscheidungslogik enthalten.

• Priorität 1: Peer-Link/Keepalive wiederherstellen, wenn klar ist, dass dadurch ein sauberer Sync-Zustand entsteht (z. B. physischer Patchfehler).
• Priorität 2: Einen Peer in einen nicht-forwarding Zustand bringen (plattformabhängig), wenn die Koordination nicht schnell wiederherstellbar ist.
• Priorität 3: Orphan Ports kontrollieren, weil sie in Split-Brain-Szenarien besonders gefährliche Asymmetrien erzeugen können.
• Priorität 4: Nach Stabilisierung gezielt Evidence sichern: MAC-Move-Logs, Peer-Link Errors, Keepalive-Statistiken, Change-Korrelation.

Beweise sichern: Welche Daten in einem Split-Brain-Ticket Pflicht sind

Split-Brain-Fälle sind lehrreich, aber nur dann, wenn Sie die richtigen Daten festhalten. Ohne klare Evidence endet die RCA häufig in Vermutungen („vielleicht war der Peer-Link kurz weg“). Diese Fakten sollten Sie standardmäßig dokumentieren:

• Zeitlinie: Startzeit, erste Warnsignale, Zeitpunkt Dual-Active erkannt, Maßnahmen mit Zeitstempeln, Zeitpunkt Stabilisierung.
• Peer-Status: Peer-Link up/down, Keepalive up/down, Dual-Active-Flags, Sync-Status (MAC/ARP/LACP Sync).
• Peer-Link Telemetrie: Errors, Drops, Discards, Optikwerte (bei Fiber), Auslastung, MTU.
• Drift-Metriken: MACMoveRate, ARP/ND-Fehler, Broadcast/Unknown-Unicast-Anteile, CPU/Controlplane.
• Topologie: betroffene Port-Channels, Downstream-Geräte, Orphan Ports, VLAN-Liste.
• Change-Korrelation: letzter Change am Peer-Link, am Keepalive-Pfad, an VLAN/Allowed-Listen, Firmware/Reload-Events.

Prävention: Guardrails, die Split-Brain selten machen

Prävention ist bei MLAG-Designs besonders wirkungsvoll, weil die häufigsten Ursachen aus wenigen Mustern bestehen: fehlende Unabhängigkeit, Drift, unklare Orphan-Strategie und mangelnde Überwachung der Peer-Gesundheit.

• Keepalive wirklich unabhängig: eigener Pfad, eigene Failure Domain, bevorzugt OOB oder dediziertes Routing, nicht „irgendwo im gleichen Fabric“.
• Peer-Link als kritisches Asset: klare Baselines (Errors, Rx/Tx, Drops), saubere Optik-/Kabelstandards, keine Mischkonfigurationen.
• Konfig-Templates: VLAN/Allowed/Native, LAG-Profile, MTU und Features müssen auf beiden Peers identisch und auditierbar sein.
• Orphan-Port-Policy: definieren, welche Ports orphan sein dürfen, wie sie sich bei Peer-Failure verhalten, und wie das NOC sie im Incident behandelt.
• Dual-Active Detection aktivieren: plattformspezifische Mechanismen konsequent nutzen und in Alarmierung aufnehmen.
• Change-Prechecks: Peer-Link/Keepalive vor und nach Changes validieren, insbesondere bei Wartung an Optik/Patchpanels.

Monitoring-Design: Alarme, die wirklich helfen (und nicht nur Lärm erzeugen)

Viele Teams alarmieren erst, wenn „Peer down“ ist. Für Früherkennung brauchen Sie zusätzlich Degradationssignale, die das Risiko anzeigen, bevor Split-Brain eintritt. Gleichzeitig sollten Alarme nicht so empfindlich sein, dass sie permanent auslösen.

• Peer-Link Error-Rate: nicht nur „link down“, sondern steigende CRC/Discards pro Minute als Warning.
• Keepalive Loss/Jitter: Paketverlust oder ungewöhnliche Latenz im Zeitfenster; besonders kritisch, wenn Peer-Link gleichzeitig degradierend ist.
• Dual-Active/Split Flags: sofort kritisch, da unmittelbarer Incident-Risikoindikator.
• MACMoveRate: ab Schwelle pro VLAN oder pro MLAG-Domäne; Hold-Down gegen kurze Peaks.
• Orphan Port State Change: wenn orphan Ports plötzlich aktiv/blockiert wechseln, ist das ein starkes Signal für Peer-Instabilität.

Outbound-Links für Standards und Grundlagen

• IEEE 802.1Q für VLAN-Tagging und Bridging-Grundlagen, die bei MLAG-Symptomen wie MAC-Flapping und Flooding zentral sind.
• IEEE 802.1AX für Link Aggregation und LACP, relevant für Member-States, Konsistenz und Hashing-Verhalten in MLAG-Designs.
• Link Aggregation – Überblick zur schnellen Terminologieeinordnung (LAG, LACP, Lastverteilung).
• IEEE 802.1Q – Überblick als ergänzende, herstellerneutrale Begriffseinordnung zu VLANs und Tagging.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.