In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
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.
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 .
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.
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.
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.
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.
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
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
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
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]
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.
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
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 ...
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#>
show platform-port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>
show platform-port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>
show platform-port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>
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.
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:
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.
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>