Stack Troubleshooting: Member fehlt, Split-Brain, Versionsmismatch

Ein Cisco Switch Stack (z. B. StackWise) wirkt im Normalbetrieb wie ein einzelnes Gerät. Wenn jedoch ein Member fehlt, der Stack in zwei Teile „splittert“ (Split-Brain) oder ein Versionsmismatch vorliegt, kann das schnell zu Ausfällen, Port-Downs und schwer erklärbaren Effekten bei Uplinks führen. Der Schlüssel ist ein strukturiertes Vorgehen: erst Stack-Status und Stack-Ports prüfen, dann Logs und Versionen, anschließend physische Ursachen (Kabel/Ports/Power) und zuletzt kontrollierte Recovery-Schritte. Diese Anleitung zeigt die wichtigsten Checks und typische Fixes praxisnah.

Symptome richtig einordnen: Was genau ist das Problem?

Stack-Probleme zeigen oft ähnliche Symptome, haben aber unterschiedliche Ursachen. Kläre zuerst, ob wirklich ein Member fehlt, ob der Stack „gesplittet“ ist oder ob ein Member wegen Software nicht joinen kann.

• Member fehlt: Ports eines Members sind down, show switch zeigt Member nicht oder als Provisioned/Absent
• Split-Brain: zwei eigenständige Control-Planes, doppelte Active-Rollen, Topologie wirkt „geteilt“
• Versionsmismatch: Member bootet, join’t aber nicht; Logs zeigen Version/Package-Fehler

Quick-Check in 60 Sekunden

show switch
show switch stack-ports
show redundancy
show version
show logging | include STACK|SWITCH|REDUNDANCY|VERSION|INCOMPAT|MISMATCH

Grundcheck: Stack-Status, Rollen und Member-Liste

Der erste Blick geht immer auf show switch: Welche Member sind da, welche Rollen (Active/Standby/Member) sind gesetzt und ob ein Switch als „Provisioned“ oder „Removed“ auftaucht.

show switch
show redundancy

Wichtige Hinweise im Output

• Active/Standby wie geplant oder „unerwartet“?
• Member-Nummern stimmen mit Dokumentation überein?
• Status zeigt „Ready“, „Provisioned“, „Removed“, „Mismatch“ oder „Init“?

Problem 1: Member fehlt – die häufigsten Ursachen

Ein fehlender Member ist meist ein physisches oder Boot-Thema: Stromversorgung, Stack-Kabel, defekte Stack-Ports, oder der Member hängt in einem Boot-Prozess.

• Power/Netzteil/Stack-Power-Problem
• Stack-Kabel locker/defekt, Ring nicht geschlossen
• Stack-Port flapped oder ist administrativ/physisch gestört
• Member bootet nicht korrekt (Image/Config/Hardware)

Stack-Ports und Ring-Topologie prüfen

show switch stack-ports
show logging | include STACKPORT|STACK|LINK|UPDOWN

Physische Checks (praxisnah)

• Stack-Kabel neu stecken, Kabel tauschen (wenn möglich)
• Ring schließen (nicht als Chain betreiben)
• Power-Status des Members prüfen (LEDs, Netzteil, Versorgung)

Member-Provisioning prüfen (RMA/Erweiterung)

Wenn ein Member als Provisioned existiert, aber physisch fehlt, kann das auf RMA/Replacement hinweisen. Prüfe, ob Provisioning zum Modell passt.

show run | include switch provision
show switch

Problem 2: Split-Brain – wenn der Stack in zwei „Stapel“ zerfällt

Split-Brain entsteht typischerweise, wenn der Stack-Ring unterbrochen wird und die Stacking-Verbindung so gestört ist, dass sich zwei unabhängige Einheiten bilden. Dann können beide Seiten versuchen, „Active“ zu sein, und du bekommst doppelte Steuerinstanzen.

Typische Anzeichen

• Unerwartete Active-Rolle auf einem Teil
• Ports/Port-Channels, die über mehrere Member gehen, brechen weg
• STP/TCNs und Uplink-Verhalten wirkt „geteilt“
• Logs zeigen Stack-Port/Stack-Link Down Events

Diagnose: Stack-Port-Status und Logs

show switch
show switch stack-ports
show redundancy
show logging | include STACK|SPLIT|REDUNDANCY|STACKPORT|LINK

Sofortmaßnahme: Ring wiederherstellen

Der wichtigste Fix ist fast immer physisch: Stack-Kabel/Ring reparieren. Sobald die Stacking-Links wieder stabil sind, kann sich der Stack wieder konsolidieren (plattformabhängig).

Problem 3: Versionsmismatch – Member join’t nicht in den Stack

Wenn ein Member nicht beitritt, obwohl Kabel und Power passen, liegt es häufig an inkompatibler Software: IOS/IOS XE Versionen, Packages, Feature-Sets oder nicht unterstützte Kombinationen. In Stacks müssen Images in der Regel konsistent sein.

Versionen und Images prüfen

show version
show switch
dir flash:

Logs auf Mismatch-Hinweise prüfen

show logging | include VERSION|MISMATCH|INCOMPAT|STACK

Typische Ursachen für Mismatch

• Unterschiedliche IOS/IOS XE Releases
• Unterschiedliche Install-/Bundle-Modi (plattformabhängig)
• Feature-Lizenz-/Package-Abweichungen
• Falsches oder beschädigtes Image auf dem neuen Member

Strukturierter Troubleshooting-Ablauf (Playbook)

Dieses Vorgehen ist robust: Du findest damit die Ursache in den meisten Umgebungen, ohne den Stack durch Aktionismus weiter zu destabilisieren.

• 1) show switch und show redundancy: Rollen und fehlende Member identifizieren
• 2) show switch stack-ports: Ring/Links prüfen
• 3) show logging gefiltert: Stack-/Version-Events finden
• 4) Physik: Kabel/Ports/Power prüfen und stabilisieren
• 5) Version/Images: Konsistenz herstellen
• 6) Danach erst kontrollierte Reload-/Recovery-Schritte

show switch
show redundancy
show switch stack-ports
show version
show logging | include STACK|SWITCH|REDUNDANCY|VERSION|MISMATCH|INCOMPAT

Recovery: Kontrollierte Maßnahmen, wenn Physik/Version stimmt

Wenn die Ursache behoben ist (Kabel/Power/Version), kann ein kontrollierter Neustart einzelner Member oder des gesamten Stacks nötig sein. Plane das als Change, weil Ports kurzzeitig ausfallen.

Konfiguration sichern und Status dokumentieren

show switch
show version
copy running-config startup-config
show logging

Member-IDs und Prioritäten prüfen (unerwartete Masterwahl vermeiden)

Nach Instabilität kann die Active-Rolle wechseln. Setze Prioritäten so, dass der gewünschte Switch Active wird.

configure terminal
switch 1 priority 15
switch 2 priority 14
end

Häufige Betriebsfallen: Warum Probleme wiederkommen

Viele Stack-Probleme kommen zurück, wenn Standards fehlen: Chain statt Ring, unklare Prioritäten, fehlendes Provisioning oder unkontrollierte Image-Stände bei RMA.

• Stack als Chain betrieben (kein Redundanzpfad)
• Keine dokumentierten Member-IDs/Ports (falsches Patchen bei Änderungen)
• Ungeplante Active-Wahl nach Reboot (Prioritäten fehlen)
• RMA/Erweiterung ohne Image-Standardisierung

Best Practices: Stack stabil halten und Troubleshooting minimieren

Ein gut betriebener Stack ist langweilig: Ring verkabelt, Rollen geplant, Images konsistent, Uplinks über mehrere Member als LACP-Port-Channel und regelmäßige Health Checks.

• Stack-Ring schließen und Stack-Kabel dokumentieren
• Active/Standby per Priorität festlegen
• Einheitliche IOS/IOS XE Version auf allen Membern
• Cross-Stack Uplinks als LACP-Port-Channel
• Health Checks: Stack-Ports, Logs, Redundancy regelmäßig prüfen

show switch
show switch stack-ports
show redundancy
show logging | include STACK|REDUNDANCY|MISMATCH
copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.