vPC/MLAG Split-Brain: Symptome, Risiken und Response-Plan

Ein vPC/MLAG Split-Brain ist eine der kritischsten Fehlersituationen in redundanten Switching-Designs und kann innerhalb von Sekunden zu massiven Netzwerkstörungen führen. In einer vPC- (Virtual PortChannel) oder MLAG- (Multi-Chassis Link Aggregation) Architektur sollen zwei physische Switches wie ein logisches System wirken, damit Downstream-Geräte (z. B. Access-Switches, Server, Firewalls) aktiv/aktiv angebunden werden können. Beim Split-Brain verlieren die beiden Peers jedoch die gemeinsame Sicht auf ihren Zustand und treffen widersprüchliche Entscheidungen: Beide halten sich für „primär“ oder beide glauben, der jeweilige Partner sei ausgefallen – obwohl er möglicherweise weiterhin Pakete forwardet. Das ist besonders gefährlich, weil es nicht nur um einen Link-Down geht, sondern um inkonsistente Steuer- und Datenebenen, die MAC-Tabellen, ARP/ND, LACP, STP und Routing-Protokolle durcheinanderbringen können. Wer die Symptome eines vPC/MLAG Split-Brain früh erkennt, die Risiken richtig einordnet und einen klaren Response-Plan etabliert, kann Ausfälle deutlich verkürzen und Folgeschäden vermeiden.

Grundlagen: Was ist vPC, was ist MLAG und warum kann Split-Brain entstehen?

vPC und MLAG sind Konzepte, bei denen zwei unabhängige Switches gemeinsam eine logische Link-Aggregation gegenüber einem Downstream-Gerät präsentieren. Ziel ist Redundanz ohne Blockierung (wie es klassisch bei STP passieren kann) und eine gleichzeitige Nutzung beider Uplinks. Damit das funktioniert, müssen die beiden Peers ihren Status kontinuierlich synchronisieren, etwa über eine Peer-Link-Verbindung und zusätzliche Kontrollmechanismen (z. B. Keepalive/Heartbeat).

Ein Split-Brain entsteht typischerweise, wenn die Peers den Kommunikationskanal verlieren oder widersprüchliche Signale erhalten, sodass der interne Konsens darüber, wer aktiv ist und welche Ports forwarden dürfen, zusammenbricht. Besonders heikel sind Situationen, in denen der Peer-Link gestört ist, aber ein Keepalive noch besteht (oder umgekehrt), oder wenn es zu einseitigen Blackholes kommt, bei denen ein Peer den anderen nicht mehr erreicht, während die Gegenrichtung noch funktioniert.

Peer-Link, Keepalive und Zustandskonsistenz

In vielen Implementierungen hat der Peer-Link die Aufgabe, Control-Plane-Informationen (z. B. MAC- und ARP-Synchronisation) und in Sonderfällen auch Datenverkehr zu transportieren. Ein Keepalive dient häufig als zusätzliche „Lebenszeichen“-Prüfung, damit ein Peer-Link-Problem nicht automatisch als Totalausfall des Partners interpretiert wird. Split-Brain-Risiko entsteht dann, wenn die Schutzlogik nicht sauber greift, Konfigurationen fehlerhaft sind oder ein Teil der Kommunikation durch Filters, ACLs, CoPP-Profile oder MTU-Mismatches beeinflusst wird.

Auslöser: Häufige Ursachen für vPC/MLAG Split-Brain

• Peer-Link-Down oder instabiler Peer-Link: Unterbrechung durch Kabel/SFP-Defekt, Port-Channel-Fehlkonfiguration, LACP-Probleme oder Fehler in der Verkabelung.
• Keepalive/Heartbeat gestört: VRF-/Routing-Fehler, falsche Management-Subnetze, ACLs, Firewall-Regeln, falsches Gateway oder asymmetrische Erreichbarkeit.
• MTU- und Fragmentierungsprobleme: Kontrollpakete oder Synchronisationsdaten kommen nicht mehr durch, obwohl der Link „up“ ist.
• Software-/Firmware-Bugs: Bestimmte Releases können vPC/MLAG-Edge-Cases fehlerhaft behandeln.
• Control-Plane-Überlast: Hohe CPU, CoPP/Policing greift zu hart, wodurch Keepalives oder Sync-Frames gedroppt werden.
• Fehlkonfiguration bei vPC/MLAG-Ports: Unterschiedliche VLAN-Listen, Native-VLAN-Fehler, inkonsistente Port-Channel-Parameter oder falsche LACP-Modi.

Symptome: So erkennen Sie Split-Brain frühzeitig

Split-Brain zeigt sich selten nur an einem einzelnen Log-Eintrag. Typisch ist eine Kombination aus ungewöhnlichen Netzwerkphänomenen, Warnmeldungen am Switch und Auffälligkeiten auf Endgeräten. Besonders wichtig: Der Zustand kann dynamisch sein. Ein Netz kann „teilweise“ funktionieren, während bestimmte VLANs, bestimmte Flows oder nur Ost-West-Verkehr zusammenbrechen.

Symptome auf Datenebene

• MAC-Flapping: Dieselbe MAC-Adresse erscheint abwechselnd auf Ports beider Peers oder auf unerwarteten Interfaces.
• ARP-/ND-Instabilität: ARP-Tabellen wechseln häufig, Nachbarn verschwinden, IPv6 Neighbor Discovery wirkt unzuverlässig.
• Unidirektionale Erreichbarkeit: Ping/Traffic in eine Richtung klappt, in die andere nicht.
• Massive Paketverluste und Retransmissions: TCP-Verbindungen werden langsam oder brechen ab, Applikationen melden Timeouts.
• Broadcast-/Unknown-Unicast-Spikes: Übermäßiger Flooding-Verkehr durch inkonsistente MAC-Lernzustände.

Symptome auf Control-Plane- und Protokollebene

• LACP-Anomalien: Aggregates wechseln den Status, Bundles sind „partial“, Member-Links werden inkonsistent aktiviert/deaktiviert.
• STP-Unregelmäßigkeiten: Obwohl vPC/MLAG STP oft stabilisieren soll, können Topologieänderungen oder Root-Änderungen auffällig häufig auftreten.
• Routing-Instabilität: Wenn L3-Gateways beteiligt sind, können FHRP-States (HSRP/VRRP) oder Routing-Adjacencies flappen.

Alarme und Logs auf den Peers

Viele Plattformen melden vPC/MLAG-inkonsistente Parameter, Peer-Link-Events oder Split-Brain-Warnungen. Relevante Indikatoren sind unter anderem Peer-Link-Down-Events, vPC/MLAG-Consistency-Check-Fehler, Hinweise auf „dual-active“ oder „orphan port“ Zustände sowie Meldungen über das gezielte Shutdown von Ports als Schutzmaßnahme.

Risiken: Warum Split-Brain gefährlicher ist als ein normaler Link-Ausfall

Ein klassischer Link-Ausfall ist in redundanten Designs vorgesehen: Ein Uplink fällt aus, der andere übernimmt. Beim vPC/MLAG Split-Brain hingegen kann die Redundanz zur Gefahr werden, weil beide Seiten gleichzeitig falsche Annahmen treffen. Dadurch entstehen Inkonsistenzen, die sich schnell ausbreiten und schwer zu isolieren sind.

Konkrete technische Risiken

• Layer-2-Loops: Wenn Schutzmechanismen versagen, kann ein Loop entstehen, der das Segment mit Broadcast-Stürmen überflutet.
• Blackholing von Traffic: Frames werden in einen Peer gesendet, der den Return-Path nicht korrekt behandelt oder Zustände nicht kennt.
• Asymmetrisches Forwarding: Hin- und Rückweg gehen über unterschiedliche Peers, was bei Statefulness (Firewalls, Load Balancer, NAT) kritisch ist.
• Verteilte Instabilität: MAC- und ARP-Flapping kann sich auf viele Switches ausbreiten und die gesamte Fabric belasten.
• Fehlersuche wird erschwert: Symptome ähneln Kabelproblemen, MTU-Problemen oder Applikationsfehlern, obwohl die Ursache auf Peer-Ebene liegt.

Auswirkungen auf Services und Business

• Unterbrechung kritischer Anwendungen (ERP, Datenbanken, VoIP, VDI, Produktionssysteme).
• Dateninkonsistenzen, wenn Storage- oder Cluster-Kommunikation instabil ist.
• Erhöhte Wiederherstellungszeit, weil ein falscher Eingriff (z. B. beide Peers rebooten) den Zustand verschlimmern kann.

Prävention: Design- und Betriebsmaßnahmen gegen Split-Brain

Split-Brain lässt sich nie zu 100 % ausschließen, aber die Wahrscheinlichkeit und die Auswirkungen können stark reduziert werden. Entscheidend sind sauberes Design, Konsistenz in der Konfiguration, klare Betriebsstandards und Monitoring.

Bewährte Design-Prinzipien

• Peer-Link robust auslegen: Mehrere physische Links als Port-Channel, hochwertige Transceiver, saubere Verkabelung, klare Dokumentation.
• Keepalive getrennt vom Peer-Link führen: Idealerweise über ein unabhängiges Netz (z. B. Management) und nicht über dieselbe physische Abhängigkeit.
• Consistency Checks aktiv nutzen: VLAN-Listen, MTU, LACP-Parameter und Port-Channel-Settings strikt standardisieren.
• Control-Plane schützen, aber nicht abwürgen: CoPP/Policing so konfigurieren, dass essenzielle Protokolle zuverlässig passieren.

Operational Best Practices

• Change-Management: Änderungen an vPC/MLAG, Port-Channels und VLAN-Listen nur mit Peer-Check und Rollback-Plan.
• Release-Strategie: Firmware/OS-Versionen mit bekannter Stabilität einsetzen und Upgrades kontrolliert testen.
• Monitoring und Alerting: Peer-Link-Status, Keepalive-Status, Consistency-Errors, MAC-Flapping und Broadcast-Raten überwachen.

Response-Plan: Vorgehen bei Verdacht auf vPC/MLAG Split-Brain

Ein wirksamer Response-Plan ist klar, schnell und risikoarm. Ziel ist nicht „sofort alles reparieren“, sondern zuerst das Netzwerk zu stabilisieren, die Ausbreitung zu stoppen und dann strukturiert zu normalem Betrieb zurückzukehren. Dabei gilt: Unkoordinierte Aktionen (beide Peers gleichzeitig anfassen, blindes Neustarten) erhöhen oft das Risiko.

Phase 1: Sofortmaßnahmen zur Stabilisierung

• Situation bestätigen: Peer-Link-Status, Keepalive-Status, vPC/MLAG-Status und Consistency-Checks auf beiden Peers prüfen.
• Scope eingrenzen: Welche VLANs/Services sind betroffen? Gibt es MAC-Flapping oder Broadcast-Stürme?
• Schutzmechanismen berücksichtigen: Viele Systeme schalten Ports automatisch in einen Schutzstatus. Nicht vorschnell „force up“ setzen.
• Traffic dämpfen: Wenn Broadcast-Stürme drohen, kann das temporäre Isolieren bestimmter Downstream-Port-Channels notwendig sein, um die Fabric zu schützen.

Phase 2: Entscheidungspunkt – welcher Peer bleibt aktiv?

Wenn ein echter Dual-Active-/Split-Brain-Zustand vorliegt, ist die zentrale Frage: Welcher Peer soll das Forwarding übernehmen? Die Wahl hängt von Topologie, aktiven Gateways, angeschlossenen Services und Sichtbarkeit ab. In vielen Betriebsmodellen wird ein „Preferred“-Peer definiert, der im Incident-Fall priorisiert bleibt, während der andere in einen sicheren Zustand überführt wird.

• Bevorzugten Peer identifizieren: Basierend auf Design-Dokumentation, Rolle (z. B. aktives Gateway), aktueller Stabilität und Fehlermeldungen.
• Den anderen Peer kontrolliert entschärfen: Ports, die den Split-Brain verstärken (häufig Downstream-vPC/MLAG-Port-Channels), ggf. gezielt deaktivieren, statt alles hart zu rebooten.

Phase 3: Ursache beheben – Peer-Link und Keepalive wiederherstellen

• Peer-Link prüfen: LACP-Status, Member-Links, Fehlerzähler, MTU, VLAN-Trunking, native VLAN, erlaubte VLANs.
• Keepalive-Pfad prüfen: Routing/VRF, ACLs, Gateway, asymmetrische Pfade, MTU, Policing.
• Hardware/Layer-1 validieren: Transceiver, Patchkabel, Ports, Lichtpegel (bei LWL), Fehlercounter.

Phase 4: Rückkehr zum Normalbetrieb (Controlled Rejoin)

Die Rückkehr in den Normalzustand sollte kontrolliert erfolgen, damit keine erneute Instabilität entsteht. Empfehlenswert ist ein schrittweises Vorgehen: Peer-Link stabil, Keepalive stabil, dann erst Downstream-Port-Channels wieder aktivieren und Monitoring engmaschig beobachten.

• Rejoin in Stufen: Erst Peer-Synchronisation, dann einzelne kritische Port-Channels, zuletzt weniger kritische Segmente.
• Counter und Flapping beobachten: MAC-Flapping, ARP-Instabilität, LACP-Events, Broadcast-Raten.
• Applikations-Checks: Nicht nur „Link up“, sondern echte Service-Health (z. B. Login, Transaktionen, Storage-IO).

Runbook-Checkliste: Was gehört in eine einsatzfähige Incident-Dokumentation?

Ein gutes Runbook reduziert Reaktionszeit und Fehlentscheidungen. Es sollte sowohl Einsteiger abholen (klare Prüfpunkte) als auch Profis unterstützen (kompakte Kommandos, Abhängigkeiten, Eskalationspfade). Folgende Inhalte haben sich bewährt:

• Topologie-Übersicht: Peer-Namen, Peer-Link-Ports, Keepalive-Pfad, Downstream-vPC/MLAG-Paare, kritische VLANs.
• Definition „Preferred Peer“: Welcher Peer bleibt im Zweifel aktiv, inklusive Begründung.
• Symptom-Mapping: MAC-Flapping, CRC/Broadcast-Spikes, LACP-Flaps, FHRP-Flaps und zugehörige Prüfschritte.
• Stabilisierungsmaßnahmen: Welche Ports dürfen im Notfall isoliert werden und in welcher Reihenfolge?
• Rollback-Strategie: Wie wird ein Change zurückgenommen, ohne erneut Split-Brain auszulösen?
• Kommunikation: Wer wird wann informiert (NOC, Security, Applikationsteams), welche Statusmeldungen sind standardisiert?

Wichtige Begriffe und verwandte Keywords für die Praxis

Für die Fehlersuche und Dokumentation ist es hilfreich, typische Schlüsselbegriffe im Blick zu haben: Dual-Active, Peer-Link Failure, Keepalive Failure, Consistency Check, Orphan Ports, MAC Flapping, ARP Flux, LACP Partial, Split Horizon, Broadcast Storm, Control-Plane Policing. Diese Begriffe tauchen in Logs, Monitoring-Systemen und Hersteller-Dokumentationen häufig wieder auf und beschleunigen die Diagnose.

Weiterführende Informationsquellen

Da vPC und MLAG je nach Hersteller unterschiedlich umgesetzt sind, lohnt sich der Blick in herstellerspezifische Referenzen sowie in allgemeine Grundlagen zu Link Aggregation. Für einen Einstieg in die Protokollbasis ist die Spezifikation zu IEEE 802.1AX Link Aggregation hilfreich. Eine praxisnahe, herstellerbezogene Perspektive bietet die Dokumentation zu Cisco Nexus vPC-Konzepten. Für MLAG-Varianten in modernen Datacenter-Designs ist außerdem die Übersicht zu Arista EOS MLAG eine nützliche Referenz, um Terminologie und Schutzmechanismen besser einzuordnen.

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.