Fehlerbehebung: Stack Manager 3650/3850 lädt neu

Einleitung

In diesem Dokument wird beschrieben, wie Sie Systemberichte zur Diagnose von Stack-Problemen nutzen können.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Wenn Sie die Fehlerbehebung für Stack-Neuladevorgänge über einen Systembericht durchführen, wenn es nicht zu einem Absturz kommt, geschieht dies in der Regel auf NGWC-Switching-Plattformen, die die StackWise-Technologie verwenden. Die aktuelle Dokumentation beschränkt sich auf die Verwendung eines Systemberichts. In diesem Leitfaden wird erläutert, wie Sie diese Berichte nutzen können, um Probleme zu diagnostizieren, die in der Regel bei Stacking-Problemen auftreten. Dieser Leitfaden ist insbesondere für Catalyst 3650/3850 Switch-Architekturen gedacht, die Cisco IOS® XE mit Stacking-Funktionen ausführen.

Die meisten Probleme mit der Stack-Technologie sind auf Kommunikationsprobleme zwischen den Elementen innerhalb eines Stacks zurückzuführen. Jede Inkonsistenz der Informationen zwischen den Elementen oder der Verlust der Verbindung kann zu einem Problem führen, das den gesamten Stack durchdringt und schließlich zu einem Reset mit dem Stack-Manager führt. In diesem Dokument werden einige der häufigsten Fehlertypen beschrieben, die beim Neuladen des Stack-Managers aufgetreten sind, sowie die Verwendung eines Systemberichts und der für die Diagnose verfügbaren relevanten CLIs sowie verschiedene Arten von Problemen.

Systembericht und Switch-Berichte

Ein Systembericht ist ein umfassender Bericht über den Zustand des Stacks. Dies ist kein Crashfo (der Speicher für das weitere Debugging auslagern kann), sondern ein Bericht, der Protokolle und Debugging-Informationen für verschiedene Dienste enthält, die unter Cisco IOS XE ausgeführt werden. Diese Informationen sind für die Entwicklung hilfreich, um den Status dieses Dienstes zu verfolgen. Ein Systembericht kann generiert werden, wenn der Switch vom Stack-Manager neu geladen wird, ein Prozessabsturz aufgetreten ist oder manuell vom Benutzer während des laufenden Betriebs generiert wurde.

In vielen Fällen kann ein einzelner Switch in einem Stack ausfallen, während die übrigen Komponenten intakt bleiben. Um Informationen über den Status des Stacks zu einem bestimmten Zeitpunkt zu sammeln, wurden switch_reports eingeführt, sodass aktuelle Elemente einen generieren können, wenn sie erkennen, dass ein Element ausgefallen ist. Bei switch_report kann es sich um einen lokalen Bericht darüber handeln, wie das Mitglied den aktuellen Status des Stacks wahrnimmt.

Hinweis: Diese Berichte werden geschrieben und komprimiert, sodass sie nicht mehr an das Terminal gedruckt werden können. Sie müssen möglicherweise vom Switch übertragen und dekomprimiert werden, um das Protokoll anzuzeigen.

Sammeln von System-/Switch-Berichten

Systemberichte können in der Regel in das crashinfo:-Verzeichnis des Elements in diesem Stapel geschrieben werden. Wenn es beispielsweise einen Switch-Stack mit x Elementen gibt, kann jeder Switch ein eigenes crashinfo-Verzeichnis haben, auf das mit dir crashinfo-x zugegriffen werden kann, wobei x dem Element im Stack entspricht.

3850#dir crashinfo-1:

Verzeichnis von crashinfo:/    

11 -rwx 355 Aug 14 2015 07:48:17 -04:00 last_systemreport_log  

12 -rwx 724015 Okt 15 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz

3850#dir crashinfo-2:

Verzeichnis von crashinfo-2:/   

11 -rwx 357 Aug 14 2015 07:50:49 -04:00 last_systemreport_log  

12 -rwx 751340 Okt 15 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz

Hinweis: Stellen Sie sicher, dass Sie die Ausgabe für dir crashinfo-x für jeden Switch in diesem Stack sammeln, da die show tech nicht die verfügbaren Dateisysteme oder die crashinfo-Dateien auflisten kann. Es ist wichtig, dass Sie das gesamte Bild jedes einzelnen Elements in diesem Stapel haben. Update: Ab den neueren Cisco IOS XE-Versionen >3.6E kann die Show-Technologie die Ausgabe von dir crashinfo: + show file systems widerspiegeln. Siehe Cisco Bug-ID CSCun50428.

Bemerkenswerte Abschnitte im Systembericht

Aus Sicht des TAC sind dies einige der am häufigsten angezeigten Einträge im Systembericht, die bei der Diagnose eines bestimmten Problems helfen können. Es gibt andere Protokolle von anderen Diensten in hier enthalten, dass Entwicklung finden wollen überprüfen.

Protokolldatei: /mnt/pss/sup_sysmgr_reset.log

Dies ist eine kurze Ausgabe, um sehr allgemein zu verstehen, warum ein Reset stattgefunden hat. Im Abschnitt zu den nächsten Fehlertypen finden Sie Informationen über die Bedeutung und den Kontext dieser Ursachen.

Protokolldatei: Cisco IOS

Dies ist der Protokollpuffer, der von Cisco IOSd verwaltet wird. Alle Befehle, die vom Benutzer ausgegeben wurden, oder Syslogs, die innerhalb von Cisco IOSd generiert wurden, finden Sie in diesem Abschnitt. Die letzten Protokolle befinden sich gegen Ende dieser Ausgabe.

Trace-Puffer: stack-mgr-events

Verfolgt die Ereignisse des Stack-Managers, die einschließen können, wenn andere Elemente dem Stack beitreten/daraus entfernt werden oder über welchen Stack-Port die Nachrichten eingehen.

               

Trace-Puffer: redundancy-timer-ha_mgr

Zeigt Keep-Alive-Ereignisse zwischen Switches im Stack an. Die Zeitstempel können dabei helfen festzustellen, wann die Unterbrechung der Kommunikation begann.

Fehlertypen

In diesem Abschnitt können Sie einige häufig verwendete Zurücksetzungen aus einem Systembericht hervorheben, die normalerweise vom Stack-Manager-Prozess aufgerufen werden. Stack Manager ist ein Linux-Prozess, der die Elemente im Stack verwaltet und alle Rollenänderungen zwischen Switches im Stack überwachen kann. Wenn der Stack-Manager bei der Initialisierung oder Rollenauswahl ein Problem erkennt, kann er ein Neuladesignal an einzelne Switches senden, damit der Stack zurückgesetzt werden kann. In der nächsten Liste können Sie auch bekannte Fehler auflisten, die mit dem jeweiligen Fehlertyp verknüpft sind.

Grund zurücksetzen:Zurücksetzen/Neuladen wurde von [Stack-Manager] angefordert. [ISSU-Inkompatibilität]

Diese Art des Zurücksetzens wird bei einem Fehler bei der Massensynchronisierung angezeigt, wenn Sie versuchen, die Konfiguration auf dem aktiven System zwischen allen Elementen im Stapel zu synchronisieren. Überprüfen Sie die Protokolldatei: Cisco IOS oder die Protokolle des aktiven Switches können die Konfigurationen hervorheben, die zu diesem Zurücksetzen beigetragen haben.

Grund zurücksetzen: Service [iosd] pid:[xyz] wurde ungewöhnlich beendet [11].

Dieser Fall tritt auf, wenn der Switch beim Cisco IOSd-Prozess abstürzt. Schauen Sie sich die crashinfo-Verzeichnisse für alle crashinfo-Dateien an + Core Dumps können verwendet werden, um diesen Fehler weiter zu debuggen.

hap_sup_reset: Zurücksetzen Grund: Zurücksetzen/Neuladen wurde von [stack-manager] angefordert. [Stapelzusammenführung]

Eine Stack-Zusammenführung wird erkannt, wenn zwei oder mehr Switches der Ansicht sind, dass sie der aktive Switch des Stacks sind. Dies ist erkennbar, wenn der Ring eines Stacks unterbrochen ist (d. h., dass zwei Kabel vom Stack getrennt sind), sodass sowohl der aktive als auch der Standby-Modus die Kommunikation mit den anderen Elementen verlieren. Das Hinzufügen eines bereits mit Strom versorgten Switches zu einem aktuellen Stack kann zu einer Stack-Zusammenführung führen, da sich zwei aktive Switches im Stack befinden können.

Cisco Bug-ID CSCuh58098 - 3850-Stack kann neu geladen werden, wenn Probleme mit der Stack-Verkabelung auftreten

Cisco Bug-ID CSCui56058 - Aktiviert Debouncing-Logik für Stack-Kabel

Cisco Bug-ID CSCup5338 - 3850 IOSD-Absturz | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: Ursachencode:[4] Zurücksetzungsgrund: Zurücksetzen/NeuladenAnforderung von [Stack-Manager]. [Zusammenführen des Stapels aufgrund von Inkompatibilität]

Dies tritt auf, wenn ein aktiver Standby-Switch im Stack vorhanden ist. Wenn die Kommunikation zwischen dem aktiven Switch und dem Standby-Gerät unterbrochen wird, kann der Standby-Gerät versuchen, das Gerät als aktives Gerät zu übernehmen, obwohl das Gerät noch aktiv ist.

Cisco Bug-ID CSCuo49555

Cisco Bug-ID CSCup58016 - 3850/3650 stürzt aufgrund von Unicast-Überflutung auf dem Mgmt-Port ab

Cisco Bug-ID CSCur07909 - Zusammenführung von Stacks wegen Verbindungsunterbrechung im aktiven und Standby-Modus

Grund zurücksetzen:Zurücksetzen/Neuladen wurde von [Stack-Manager] angefordert. [Falscher Nachbar nach ASIC-Abstimmung gefunden]

Switches werden beim Hochfahren in einem ASIC-Stimmzettel ausgewählt, um die benachbarten Switches im Stack zu bestimmen. Dieser Reset wird angezeigt, wenn ein Timer abläuft, damit ein Nachbar sich selbst deklariert, oder wenn während der NBR-Konversation ein Logikfehler auftritt. Dies wurde im Zusammenhang mit fehlerhaften Stack-Kabeln gesehen, die durch Austausch behoben wurden.

Cisco Bug-ID CSCun6077 - Switch neu geladen aufgrund von falschem Nachbarn nach ASIC-Abstimmung

Cisco Bug-ID CSCud93761 - Switch neu geladen aufgrund von falschem Nachbarn nach ASIC-Abstimmung

Cisco Bug-ID CSCun17506 - Amur:ng3k:derselbe Nachbar ist auf beiden Stack-Ports in einem Stack mit drei Elementen zu finden

hap_sup_reset: Ursachencode:[4] Zurücksetzen:Zurücksetzen/Neuladen, beantragt von [Stack-Manager]. [verlorene aktive und Standby-Geräte]

Dies wird in der Regel bei einem Element im Stack deutlich, das weder eine aktive noch eine Standby-Rolle innehat. Wenn der aktive Switch ausfällt und kein Standby-Switch die aktive Rolle für den Stack übernimmt, kann der gesamte Stack zurückgesetzt werden. Wenn der Stack instabil ist oder die Redundanzrichtlinien noch nicht synchronisiert wurden, ist dies ersichtlich. Wahrscheinlich liegt dies daran, dass die Aktiv-/Standby-Switches ausfallen, oder es gibt einen Hinweis darauf, dass die Redundanz nicht richtig synchronisiert wird. Dies ist auch in zu sehen, wenn Stacks in einer Halbring-Konfiguration konfiguriert werden.

Cisco Bug-ID CSCup5382- Mitglieds-Switches beim Neustart des 3850-Stacks - [verlorene aktive und Standby-Geräte]

hap_sup_reset: Ursachencode:[1] Zurücksetzen (Reset): Zurücksetzen/Neuladen, beantragt von [Stack-Manager]. [Keepalive_Timeout]

Wird erkannt, wenn Keep-Alive-Nachrichten nicht vom Switch im Stack empfangen werden. Schauen Sie sich Trace Buffer: redundancy-timer-ha_mgr an und es zeigt den Austausch von Keep-Alive-Nachrichten und bietet eine Zeitperspektive für den Zeitpunkt, an dem der Ausfall der Kommunikation begann. Wenn Sie Switch-Berichte aus dem Rest des Stacks sammeln und Protokolle über den gesamten Zeitraum einsehen, kann dies hilfreich sein.

hap_sup_reset: Zurücksetzen Grund: Zurücksetzen/Neuladen wurde von [stack-manager] angefordert. [Befehl neu laden]

Dies ist ein ziemlich intuitiver Grund für das Zurücksetzen - dies zeigt sich, wenn der Stack-Manager eine Neuladeanforderung empfängt, die über die CLI oder extern über das Verwaltungsgerät (SNMP) aufgerufen werden könnte. In Fällen mit der Cisco Bug-ID CSCuj17317 wird dies auch als Befehl zum erneuten Laden angezeigt. Aus der Protokolldatei Cisco IOS können Sie Folgendes sehen:

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

Verwandte Fehler

Cisco Bug-ID CSCur76872 - Der Stack-Manager fällt aus, wenn der SDP-Puffer im System ausfällt.

Cisco Bug-ID CSCup49704 - 3850 FED Crash - Wartet auf SPI-Kanäle FED_SPI_FLCD,FED_SPI_FAST ...

Diagnose eines potenziellen Stack-Kabels oder Port-Problems

Symptom 1) Anzeichen eines Stack-Kabelproblems werden durch ein Flapping des Stack-Ports vor dem Zurücksetzen deutlich. Protokolldatei: Der Cisco IOS-Bericht vor dem Zurücksetzen ist in der Regel ein guter Ausgangspunkt. Hier sehen Sie ein Beispiel für das Flapping des Stack-Ports, der sowohl auf dem aktuellen SW2 als auch auf dem Standby-SW1 registriert ist. Derselbe Stack-Port flatterte jedes Mal beim Zurücksetzen und wurde beim Ersetzen des Stack-Kabels wie folgt aufgelöst:

=====================  log file: Cisco IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

Symptom 2: Je nach Stack-Konfiguration (180, 480 plus) variiert die Anzahl der Übertragungsringe pro Port-ASIC. Diese Befehle fragen globale Register ab, die eine Gesamtsumme verwalten, die sich um die Anzahl der Lesefehler erhöht, die für jeden Übertragungsring erkannt werden. Port-asic 0 entspricht Stack-Port 1 und Port-asic 1 entspricht Stack-Port 2. Diese muss für jeden Switch ausgegeben werden, und alle Anzeichen für Zählungen, die bei einem inkrementellen Vorgang ausgelöst werden, können erkennen, ob ein Problem am Port oder mit dem Stack-Kabel vorliegt.

Diese können mehrmals innerhalb weniger Minuten gesammelt werden, um die Deltas in der Zählung zu vergleichen:

show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>

• Segment mit Daten-CRC-Fehler.

show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>

• Erhöht bei jeder fehlgeschlagenen CRC-Prüfung.

show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>

• Inkrementiert bei ungültigem PCS-Code, unbekanntem PCS-Codewort, das einen erkannten Disparitätsfehler ausführt.

show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>

• Bitfehler im Stapel hat einen Ringwort-CRC-Fehler verursacht.

Für Polaris (16.X-Code) sind dies die folgenden Befehle:

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1> 

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>

Dieses Beispiel zeigt, dass bei einem Ereignis zum Zusammenführen eines Stapels beide Elemente eines Stapels mit zwei Elementen ohne Anzeichen eines Flapping-Stack-Ports gesehen wurden. Der Ring [0] wird mit CRCs auf Stack-Port-1 von Switch 1 inkrementiert. Um dieses Problem zu überwinden, ersetzen Sie das Stack-Kabel.

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

Weitere Tipps

1. Archiv Crashinfo Verzeichnisse

Mehr Switches im Stack bedeuten, dass mehr Berichtsdateien gesammelt werden können. Es ist leicht, von der Anzahl der erstellten Berichte überwältigt zu werden. Die Organisation ist von entscheidender Bedeutung, um einen Misserfolg zu isolieren. Konsistenz mit Zeitstempeln für den Zeitpunkt, zu dem jeder Switch nach Möglichkeit eine Berichtsdatei für einen bestimmten Vorfall geschrieben hat. Erkundigen Sie sich dort nach den sehr spezifischen Berichten der Switches, damit der Client nicht mehrere Dateien hochlädt. Das crashinfo-Verzeichnis kann auch archiviert werden, sodass der Cisco-Benutzer ein einziges Archiv mit den interessierten Berichten senden kann. Im nächsten Beispiel kann ein Archiv mit dem Namen crashinfo-archive.tar im Flash-Verzeichnis erstellt werden:

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

2. Wiederherstellen eines instabilen Stapels

Es kann Situationen geben, in denen mehrere Elemente in einem Stack beim Hochfahren nach der Stapelauswahl neu geladen werden. Wenn ein neu geladener Switch sich als aktiv einstuft, kann dies häufig zu einem Ereignis beim Zusammenführen des Stacks führen und in einen Bootschleifenzustand übergehen. In dieser Situation kann es ratsam sein, den Cisco Client zu fragen:

• Schalten Sie den gesamten Stack aus, und setzen Sie alle Stack-Kabel wieder fest.
• Schalten Sie jeden Switch im Stack einzeln ein, bis alle Switches in den erwarteten Status konvergiert sind.
• Wenn ein Element dem Stack nicht beitritt, entfernen Sie diesen aus dem Stack, und versuchen Sie, den Stack als Standalone-Gerät zu starten, um die Fehlerbehebung fortzusetzen.

3. Systemberichte manuell erstellen

Für manuell erstellte Systemberichte muss der interne Service aktiviert sein. Dadurch wird ein Systembericht als Textdatei geschrieben, die auf Switch-Basis erstellt werden kann.

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>

Zugehörige Informationen

• Technischer Support und Downloads von Cisco