Fehlerbehebung bei 3650/3850-Neuladungen durch Stack Manager über einen Systembericht

Einführung

Die Fehlerbehebung für Stack-Neuladungen durch einen Systembericht wird in der Regel auf NGWC-Switching-Plattformen mit Stackwise-Technologie durchgeführt. 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 speziell auf die Catalyst 3650/3850 Switching-Architekturen mit IOS-XE zugeschnitten, die Stacking-Funktionen unterstützen.

Die Mehrzahl der Probleme mit der Stack-Wise-Technologie resultiert aus einem Kommunikationsproblem zwischen den Elementen innerhalb eines Stacks. Jegliche Inkonsistenz der Informationen zwischen den Elementen oder der Verlust der Konnektivität kann zu einem Problem führen, das den gesamten Stack durchdringt und letztendlich zu einer Zurücksetzung mit dem Stack-Manager führt. In diesem Dokument werden einige häufige Fehlertypen beim erneuten Laden des Stack-Managers, die Verwendung eines Systemberichts und relevante CLIs für die Diagnose und verschiedene Arten von Problemen beschrieben.

Hintergrundinformationen:

Systembericht und Switch-Berichte

Ein Systembericht ist ein umfassender Bericht des Mitglieds, aus dem hervorgeht, wie er den Zustand des Stacks wahrnimmt. Dies ist kein Crashinfo (der Speicher für das weitere Debuggen ausspuckt), sondern ein Bericht, der Protokolle und Debuginformationen für verschiedene Dienste enthält, die unter IOS-XE ausgeführt werden. Dieser Bericht ist für die Entwicklung hilfreich, um den Zustand dieses Dienstes nachzuverfolgen. Ein Systembericht kann erstellt werden, wenn der Switch vom Stack-Manager neu geladen, ein Prozessabsturz aufgetreten oder vom Benutzer während des Live-Betriebs manuell generiert wird.

In vielen Fällen kann es vorkommen, dass ein einzelner Switch in einem Stack ausfällt, die übrigen Elemente jedoch intakt bleiben. Um Informationen über den Status des Stacks zum gegebenen Zeitpunkt zu sammeln, wurden Switch_Reports eingeführt, sodass die verbleibenden Member einen generieren, wenn sie feststellen, dass ein Member ausgefallen ist. Der switch_report ist ein lokaler Bericht darüber, wie dieser Member den aktuellen Status des Stacks wahrnimmt.

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

Erfassung von System-/Switch-Berichten

Systemberichte werden in der Regel in folgende Bereiche geschrieben: des Mitglieds in diesem Stapel. Wenn es z. B. einen Switch-Stack mit x-Elementen gibt, verfügt jeder Switch über ein eigenes Crashinfo-Verzeichnis, auf das mit "dir crashinfo-x" zugegriffen werden kann, wobei "x" für dieses Element im Stack steht.

3850#dir crashinfo-1:

Verzeichnis der 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-11342-UTC.gz

3850#dir crashinfo-2:

Verzeichnis der 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 "show tech" die verfügbaren Dateisysteme oder Crashinfo-Dateien nicht auflistet. Es ist wichtig, dass Sie das gesamte Bild jedes einzelnen Elements in diesem Stack haben. Aktualisieren: Ab neueren IOS-XE-Versionen >3.6E spiegelt die show tech die ''dir crashinfo:' + 'show file systems' Ausgabe wider. Siehe CSCun50428 .

Interessante Abschnitte im Systembericht

Aus TAC-Sicht sind dies einige der am häufigsten angezeigten Einträge im Systembericht, die bei der Diagnose von Ereignissen eines bestimmten Problems helfen können. Es gibt weitere Protokolle von anderen Diensten, die hier enthalten sind, die die Entwicklung möglicherweise überprüfen möchte.

Protokolldatei: /mnt/pss/sup_sysmgr_reset.log

Dies ist eine kurze Ausgabe, um sehr allgemein zu verstehen, warum ein Zurücksetzen gesehen wurde. Im folgenden Abschnitt zu Fehlertypen können Sie die Bedeutung und den Kontext der unterschiedlichen Ursachen nachlesen.

Protokolldatei: IOS

Dies ist der Protokollpuffer, der innerhalb von IOSd verwaltet wird. Alle Befehle, die vom Benutzer oder in IOSd generierte Syslogs ausgegeben wurden, finden Sie in diesem Abschnitt. Die letzten Protokolle nähern sich dem Ende dieser Ausgabe.

Trace-Puffer: stack-mgr-events

Verfolgt Ereignisse, die im Stack-Manager sichtbar sind. Dies beinhaltet auch, wenn andere Elemente dem Stack beitreten/daraus entfernt werden oder der Stack-Port die Nachrichten durchläuft.

               

Trace-Puffer: Redundanz-timer-ha_mgr

Zeigt Keep-Alive-Ereignisse zwischen Switches im Stack an. Die Zeitstempel können dabei helfen zu bestimmen, wann die Störung in der Kommunikation begann.

Arten von Ausfällen

In diesem Abschnitt werden einige häufig verwendete Zurücksetzungen aus einem Systembericht hervorgehoben, die normalerweise vom Stapelverwaltungsprozess aufgerufen werden. Stack Manager ist ein Linux-Prozess, der die Mitglieder im Stack verwaltet und alle Änderungen der Rollen zwischen Switches im Stack überwacht. Wenn der Stack Manager ein Problem bei der Initialisierung oder Rollenauswahl feststellt, sendet er ein Neuladesignal an einzelne Switches, damit der Stack zurückgesetzt werden kann. Im Folgenden werden auch bekannte Fehler aufgelistet, die dem jeweiligen Fehlertyp zugeordnet wurden.

Hinweis: Nicht alle Stack-Manager-Neuladungen sind auf ein Softwareproblem zurückzuführen. Tatsächlich ist es häufiger, dass diese Probleme als sekundäres/opferspezifisches Problem eines zugrunde liegenden Hardwareproblems auftreten.

Grund für die Zurücksetzung:Zurücksetzen/erneutes Laden erforderlich von [Stack-Manager]. [ISSU-Inkompatibilität]

Sie sehen diese Art des Zurücksetzens, wenn bei dem Versuch, die Konfiguration auf dem aktiven Gerät zwischen allen Elementen im Stack zu synchronisieren, ein Fehler bei der Massensynchronisierung auftritt. Protokolldatei wird geprüft: 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] ungewöhnlich beendet [11].

Dies wird beobachtet, wenn der Switch im IOSd-Prozess abstürzt. Wenn Sie sich die Crashinfo-Verzeichnisse für Crashinfo-Dateien + Core Dumps anschauen, können Sie diesen Fehler weiter debuggen.

hap_sup_reset: Grund für die Zurücksetzung:Zurücksetzen/erneutes Laden erforderlich von [Stack-Manager]. [Stapelzusammenführung]

Eine Stapelzusammenführung wird angezeigt, 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 wird (d. h. zwei Kabel sind vom Stack getrennt), sodass sowohl der aktive als auch der Standby-Switch die Kommunikation mit den anderen Elementen verliert. Wenn einem vorhandenen Stack ein bereits eingeschalteter Switch hinzugefügt wird, kann es zu einer Stapelzusammenführung kommen, da zwei aktive Switches im Stack vorhanden sind.

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

CSCui56058 - Aktivieren der Debounce-Logik für Stack-Kabel

CSCup53338 - 3850 IOSD-Absturz | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: Ursachencode:[4] Reset Reason:Reset/Reloadrequest by [stack-manager]. [Stack-Zusammenführung aufgrund von Inkompatibilität]

Dies wurde in Situationen beobachtet, in denen ein aktiver und Standby-Switch im Stack vorhanden ist. Wenn der aktive Switch die Kommunikation mit dem Standby-Switch verliert, versucht der Standby-Switch, die Funktion als aktiver Switch zu übernehmen, obwohl der aktive Switch noch aktiv ist.

CSCuo49555 /CSCup58016 - 3850/3650 stürzt aufgrund von Unicast Flood am Mgmt-Port ab

CSCur07909 - Stack-Verschmelzung aufgrund der verlorenen aktiven und Standby-Konnektivität

Grund für die Zurücksetzung:Zurücksetzen/erneutes Laden erforderlich von [Stack-Manager]. [Falscher Nachbar nach ASIC-Wahl]

Switches werden während des Hochfahrens in einem ASIC-Wählplan eingesetzt, um die benachbarten Switches im Stack zu ermitteln. Dieser Rücksetzvorgang kann angezeigt werden, wenn ein Timer abläuft, damit sich ein Nachbar selbst deklarieren kann, oder wenn während des Gesprächs über den nbrcast ein logischer Fehler auftritt. Dies wurde bei fehlerhaften Stack-Kabeln beobachtet, die durch den Austausch behoben wurden.

CSCun60777 - Switch aufgrund eines falschen Nachbarn nach ASIC-Stimmzettel neu geladen

CSCud93761 - Switch aufgrund eines falschen Nachbarn nach ASIC-Stimmzettel neu geladen

hap_sup_reset: Ursachencode:[4] Reset Reason:Reset/Reload angefordert von [stack-manager]. [Sowohl aktiv als auch im Standby-Modus verloren]

Dies wird in der Regel von einem Stack-Element aus beobachtet, das sich nicht in einer aktiven oder Standby-Rolle befindet. Wenn der aktive Switch ausfällt und kein Standby-Switch die aktive Rolle für den Stack übernehmen kann, wird der gesamte Stack zurückgesetzt. Wenn es sich bei dem Stack um einen instabilen Zustand handelt oder die Redundanzrichtlinie noch nicht synchronisiert wurde, wird dies angezeigt. Dies ist wahrscheinlich ein Grund für den Ausfall der Aktiv/Standby-Switches oder ein Hinweis darauf, dass die Redundanz nicht korrekt synchronisiert wird. Dies ist auch bei der Konfiguration von Stacks in einer Half-Ring-Konfiguration zu beobachten.

CSCup53882 - Teilnehmer-Switches in einem 3850-Stack-Neustart - [Verlust von Aktiv und Standby]

hap_sup_reset: Ursachencode:[1] Grund für die Zurücksetzung:Zurücksetzen/erneutes Laden angefordert von [stack-manager]. [Keepalive_Timeout]

Es wird angezeigt, wenn Keep-Alive-Nachrichten nicht vom Switch im Stack empfangen werden. Blick auf "Trace Buffer: "redundancy-timer-ha_mgr" sollte den Austausch von Keep-Alive-Nachrichten anzeigen und eine Zeitperspektive für den Beginn der Kommunikationsunterbrechung bieten. Hier kann es hilfreich sein, Switch-Berichte vom Rest des Stacks zu sammeln und Protokolle während des Zeitrahmens zu betrachten.

hap_sup_reset: Grund für die Zurücksetzung:Zurücksetzen/erneutes Laden erforderlich von [Stack-Manager]. [Befehl erneut laden]

Dies ist ein relativ intuitiver Grund für das Zurücksetzen. Dies zeigt sich, wenn der Stack-Manager eine Anforderung zum erneuten Laden erhält, die über die CLI oder extern über das Management-Gerät (SNMP) aufgerufen werden kann. In Fällen von CSCuj17317 wird dies auch als "reload command" angezeigt. Aus der Protokolldatei: IOS:

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

Relevante Bugs

CSCur76872 - Der Stack-Manager fällt aus, wenn der SDP-Puffer des Systems ausfällt.

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

Diagnose eines potenziellen Stack-Verkabelungs-/Port-Problems

Symptom 1) Anzeichen für ein Problem mit der Stack-Verkabelung werden durch Flapping des Stack-Ports vor dem Zurücksetzen sichtbar. Schauen Sie sich die "Logfile: Der IOS-Bericht vor dem Zurücksetzen ist in der Regel ein guter Ausgangspunkt. Hier sehen Sie ein Beispiel für die Flapping des Stack-Ports, der sowohl auf dem aktuellen SW2 als auch auf dem Standby-SW1 registriert ist. Der gleiche Stack-Port flatterte in jeder Instanz des Reset-Ports und wurde durch den Austausch des Stack-Kabels aufgelöst:

=====================  log file: 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 Konfiguration im Stapelmodus (180, 480 plus) variiert die Anzahl der Übertragungsringe pro Port-ASIC. Mit diesen Befehlen werden globale Register abgefragt, in denen die Anzahl der Lesefehler, die für jeden Übertragungsring sichtbar sind, laufend angegeben wird. "Port-asic 0" entspricht Stack-Port 1 und "port-asic 1" dem Stack-Port 2. Dieser Wert sollte für jeden Switch ausgestellt werden, und alle Anzeichen für inkrementelle Zählungen können isolieren, ob ein Problem am Port oder mit dem Stack-Kabel vorliegt.

Diese können mehrere Male über ein paar Minuten gesammelt werden, um die Deltas in der Zahl zu vergleichen:

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

• Segmentierung mit Daten-CRC-Fehler

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

• Erhöht bei fehlgeschlagener CRC-Prüfung

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

• Erhöht auf ungültigen PCS-Code, unbekanntes PCS-Codewort, wird ein Fehler bei der Ausführung erkannt

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

• Bitfehler im Stapel verursacht CRC-Fehler des Klingelworts

Für Polaris (Code 16.x) sind die Befehle:

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

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

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

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

Das folgende Beispiel zeigt ein Ereignis zum Zusammenführen eines Stacks, das beide Elemente eines Stacks mit zwei Elementen ohne Anzeichen für einen Flapping-Stack-Port erkennt. Sie sehen Ring[0], der mit CRCs auf Stack-Port-1 von Switch 1 inkrementiert wird und das Stack-Kabel ersetzt hat, um dieses Problem zu umgehen.

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

Hinweis: Je nach betrachtetem Register kann die Maske in jedem Fall unterschiedlich sein. Im obigen Beispiel wird die Maske auf den letzten 14 Bit umwickelt. Wenn der Zähler 0 x00003FFF erreicht, wird er auf 0 x 0000000 zurückgesetzt.

Zusätzliche Tipps

1.  Archivieren von Crashinfo-Verzeichnissen

Mehr Switches im Stack bedeuten, dass mehr Berichtsdateien gesammelt werden müssen. Die Anzahl der generierten Berichte ist leicht zu hoch. Organisation ist für die Isolierung eines Fehlers unerlässlich. Ermitteln Sie eine Konsistenz, indem Sie Zeitstempel dafür verwenden, wann jeder Switch nach Möglichkeit eine Berichtsdatei für einen bestimmten Vorfall geschrieben hat. Fragen Sie von dort nach diesen spezifischen Berichten der angegebenen Switches, damit der Kunde nicht mehrere Dateien hochlädt. Das Crashinfo-Verzeichnis kann auch archiviert werden, sodass der Kunde ein einziges Archiv mit den interessierten Berichten senden kann. Im Flash-Verzeichnis wird ein Archiv mit dem Namen 'crashinfo-archive.tar' erstellt.

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 Stacks

Es kann vorkommen, dass beim Hochfahren nach dem Stack-Auswahlprozess mehrere Elemente in einem Stack neu geladen werden. Wenn sich ein neu geladener Switch selbst als aktiv ansieht, kann dies häufig zu einem Stapelzusammenführungsereignis führen und in einen Boot-Loop-Zustand übergehen. In diesem Fall kann es ratsam sein, den Kunden zu fragen:

- Schalten Sie den gesamten Stack aus, und schließen Sie alle Stack-Kabel wieder fest an.

- Schalten Sie jeden Switch im Stack einzeln ein, bis alle Switches in den erwarteten Zustand konvertiert sind.

- Falls ein Mitglied nicht am Stack teilnehmen kann, entfernen Sie es aus dem Stack, und versuchen Sie, diesen Benutzer als Standalone zu starten, um eine weitere Fehlerbehebung durchzuführen.

3. Manuelles Erstellen von Systemberichten

Für die manuelle Erstellung von Systemberichten muss "service internal" 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>