Fehlerbehebung bei unerwarteten Neustarts oder Abstürzen auf dem Nexus 9000
Inhalt
Einleitung
Dieses Dokument beschreibt die Fehlerbehebung bei unerwarteten Neuladevorgängen oder Abstürzen auf Nexus 9000-Switches.
Voraussetzungen
Für dieses Dokument bestehen keine Voraussetzungen.
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.
So bricht der Nexus 9000-Switch
Cisco NX-OS ist ein ausfallsicheres Betriebssystem, das speziell für hohe Verfügbarkeit auf Netzwerk-, System- und Prozessebene entwickelt wurde. Ein unerwartetes Neuladen kann auf einem Nexus 9000-Switch aus drei Gründen erfolgen:
- Bei einem Prozess im Benutzerbereich kann es zu einem Absturz kommen.
- Bei einem Prozess oder einer Hardwarekomponente kann ein Watchdog-Timeout oder ein Heartbeat-Fehler auftreten.
-
Der Kernel selbst befindet sich in einem nicht wiederherstellbaren Zustand und stürzt ab.
Wichtige Daten zur Fehlerbehebung bei Neuladen und Absturz
- Das genaue Datum und die Uhrzeit des erneuten Ladens.
- Was geschah vor dem Neuladen? Irgendwelche Konfigurationsänderungen? Irgendwelche Skalierungsänderungen? Gibt es Protokolle auf dem Gerät? Irgendwelche Umweltveränderungen? Wird die CPU-/Speichernutzung erhöht?
- Sobald der Switch hochgefahren und stabil ist, erfassen und überprüfen Sie die Ausgabe.
- Wenn der Switch nicht gebootet werden kann, greifen Sie über die Konsole zu, und überprüfen Sie, ob eine Ausgabe vorhanden ist. Überprüfen Sie auch die Switch-LEDs. Details zu LEDs finden Sie in der Hardware-Installationsanleitung.
Zurücksetzen des Systems - Grund
N9K#show system reset-reason module 1 ----- reset reason for Supervisor-module 1 (from Supervisor in slot 1) --- 1) At 21301 usecs after Tue Jan 17 20:29:20 2023 Reason: Reset Requested due to Fatal Module Error Service: ipfib hap reset Version: 9.3(8)
Core-Datei
N9K#show cores
VDC Module Instance Process-name PID Date(Year-Month-Day Time)
--- ------ -------- --------------- -------- -------------------------
A B C D E 2024-01-04 19:17:25
copy core://<module-number>/<process-id>[/instance-num]
copy core://B/E/C ftp://<address>/<directory>
Onboard-Protokolle
show logging onboard
show logging onboard kernel-trace
show logging onboard stack-trace
**************************************************************
STACK TRACE GENERATED AT Sun Sep 10 19:06:39 2023 CCT
**************************************************************
<snip> >>>dumps kernel massages before reload
<0>[10925084.972289] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.980666] [1694343998] cctrl_set_card_offline - EOBC switch reset failed
<0>[10925084.987824] [1694343998] sysServices Unexpected call in interrupt context, serviceId=824
<0>[10925084.996200] [1694343998] cctrl_set_card_offline - EPC switch reset failed
<snip>
<4>[10925085.040600] [1694343998] Dumping interrupt statistics >>>dump interrupt statictics
<4>[10925085.045928] [1694343998] CPU0 CPU1
<4>[10925085.051732] [1694343998] 3: 0 0 axp_irq Armada Error Handler
<4>[10925085.059909] [1694343998] 4: 0 0 axp_irq Armada MBUS unit Error Handle
<4>[10925085.068957] [1694343998] 5: 1012335907 809985523 axp_irq axp_local_clockevent
<4>[10925085.077136] [1694343998] 8: 1260801154 0 axp_irq mv_eth
<4>[10925085.084108] [1694343998] 31: 11230 0 axp_irq mv64xxx_i2c
<4>[10925085.091508] [1694343998] 41: 7111 1 axp_irq serial
<4>[10925085.098471] [1694343998] 51: 2 0 axp_irq mv_xor.0
<4>[10925085.105602] [1694343998] 52: 2 0 axp_irq mv_xor.1
<4>[10925085.112760] [1694343998] 94: 1 0 axp_irq mv_xor.2
<4>[10925085.119890] [1694343998] 95: 1 0 axp_irq mv_xor.3
<4>[10925085.127029] [1694343998] 107: 0 0 axp_irq axp-temp
<4>[10925085.134200] [1694343998] 168: 0 0 axp_irq cctrl_mrv_nmi_irq
<4>[10925085.142134] [1694343998] 195: 29 0 axp_msi_irq cctrl_sc_msi_irq
<4>[10925085.150225] [1694343998] 196: 0 2399172865 axp_msi_irq linux-kernel-bde
<4>[10925085.158325] [1694343998] IPI0 : 0 0 Timer broadcast interrupts
<4>[10925085.166130] [1694343998] IPI1 : 1711470501 3532640372 Rescheduling interrupts
<4>[10925085.173672] [1694343998] IPI2 : 0 0 Function call interrupts
<4>[10925085.181302] [1694343998] IPI3 : 44582 118572 Single function call interrupts
<4>[10925085.189541] [1694343998] IPI4 : 0 0 CPU stop interrupts
<4>[10925085.196734] [1694343998] PMU: : 0 0
<4>[10925085.202186] [1694343998] Err : 0
show logging onboard exception-log >>>Check if any exception is raised before reload
Prozessprotokoll
N9K# show processes log details >>>detail process memory usage prior to crash
Service: ethpm
Description: Test Ethernet Port Manager
Executable: /isan/bin/ethpm
Started at Wed Jun 5 18:20:46 2023 (251615 us)
Stopped at Sat Jun 8 00:08:53 2023 (661042 us)
Uptime: 2 days 5 hours 48 minutes 7 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Last heartbeat 48.10 secs ago
System image name:
System image version: 7.0(3)I7(6)
PID: 28914
Exit code: signal 5 (core dumped)
CWD: /var/sysmgr/work
RLIMIT_AS: 1019819820 >>>limit memory usage
Virtual Memory:
CODE 1007E000 - 1068DBD4
DATA 1068E000 - 106DC3E8
BRK 1194F000 - 11CF9000
STACK FFA28650
TOTAL 576004 KB >>>memory usage before crash
Protokolldateien von Logflash
Der Nexus 9000 verfügt über einen integrierten Logflash, sodass die Protokolldateien nach dem Neuladen erhalten bleiben.
N9K#dir logflash:log | grep messages
3714961 Jan 13 18:05:31 2024 messages
4194331 Jan 13 17:30:14 2021 messages.1
5497842 May 11 15:59:00 2021 messages.2
4194341 Jul 30 07:25:36 2022 messages.3
4194510 Feb 09 14:50:50 2023 messages.4
4194426 Jun 04 05:00:40 2023 messages.5
N9K#show file logflash:log/messages
N9K#show file logflash:log/messages.1
N9K#show file logflash:log/messages.2
N9K#show file logflash:log/messages.3
N9K#show file logflash:log/messages.4
N9K#show file logflash:log/messages.5
Häufige Zurücksetzungsgründe
Neuladen im Zusammenhang mit Stromversorgung
N9K#show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 280125 usecs after Fri Aug 4 02:01:14 2023
Reason: Module PowerCycled
Service: HW check by card-client
Version:
Erläuterung
Der Nexus 9000-Switch unterstützt N+1-Redundanz bei der Energieversorgung. Bei einem Stromausfall an den meisten oder allen Stromquellen erfolgt ein erneutes Laden.
Empfehlung
- Überprüfen Sie die Netzkabel aller Netzteile.
- Prüfen Sie, ob andere Geräte, die den gleichen Einlasskreis nutzen, ebenfalls ausgefallen sind.
- Prüfen Sie, ob ein Alarm zur Stromversorgung beim Nexus 9000 oder der Stromverteilungseinheit ausgelöst wird.
Prozessabsturz
N9K#show system reset-reason module 1
----- reset reason for Supervisor-module 1 (from Supervisor in slot 1)
1) At 21301 usecs after Tue Jan 17 20:29:20 2023
Reason: Reset Requested due to Fatal Module Error
Service: ipfib hap reset >>>ipfib process reset
Version: 9.3(8)
Erläuterung
Jeder Service verfügt über eine eigene HA-Richtlinie, einschließlich eines Heartbeat-Timers, einer Neustartmethode und eines Stateful Restart mit max. Wiederholungsversuch. Die Cisco NX-OS Software ermöglicht Stateful-Neustarts der meisten Prozesse und Services. Das Neuladen erfolgt, wenn die HA-Richtlinie des Prozesses zurückgesetzt wird (NX-OS kann während eines Prozessneustarts nicht funktionieren) oder wenn ein Prozessneustart den maximalen Wiederholungsversuch erreicht.
Empfehlung
`show cores` VDC Module Instance Process-name PID Date(Year-Month-Day Time) --- ------ -------- --------------- -------- ------------------------- 1 1 1 ipfib 27446 2023-01-17 20:30:30
copy core://1/27446/1 ftp://<address>/<directory>
Die meisten Prozessabstürze sind Softwarefehler, und die Kerndatei wird gespeichert. Öffnen Sie zur Bestätigung ein Serviceticket.
- Kerndateien können von einem TAC-Techniker entschlüsselt werden.
- Um die Serviceanfrage zu öffnen, wählen Sie Product > Unexpected Reboot > Software Failure (Produkt > Unerwarteter Neustart > Softwarefehler), um sicherzustellen, dass das Ticket mit dem richtigen Team geöffnet wird.
EOBC-Ausfall
2018 Jan 21 01:56:42.789 N9K#%KERN-0-SYSTEM_MSG: [4590707.849157] [1516460202] EMON: module 2 is not responding on EOBC path. Reloading module. - kernel 2018 Jan 21 01:56:43.071 N9K#%MODULE-2-MOD_DIAG_FAIL: Module 2 (Serial number: xxxxxxxxxx) reported failure due to EOBC heartbeat failure in device DEV_EOBC_MAC (device error 0xc0a1b137)
Erläuterung
Die regulären EOBC-Keepalives (Ethernet Out of Band Channel) werden zwischen Supervisor und Line Cards übertragen. Die Fehlermeldungen, die Sie erhalten, zeigen an, dass zwischen SUP und der Linecard ein Takt fehlt. Wenn ein einzelner Herzschlag fehlt, kann er automatisch ignoriert werden. Wenn jedoch mehrere Heartbeats gleichzeitig verloren gehen, wird die Linecard zurückgesetzt.
Es gibt in der Regel drei Gründe für einen EOBC-Ausfall:
- EOBC-Überlastung. Sie sehen mehr als 1 Linecard EOBC verloren.
- CPU-Hog in einem bestimmten Modul bzw. bestimmten Modulen. Die Linecard-/Supervisor-CPU ist ausgelastet und kann EOBC-Nachrichten nicht verarbeiten. Ab Nexus 9000 gibt es eine Softwareerweiterung, die mit 7.0(3)I7(3) beginnt.
- Hardwarefehler.
Empfehlung
- Überprüfen Sie, ob die CPU auf eine Linecard um den Neuladen herum schrumpft.
- Überprüfen Sie, ob bei einer anderen Linecard beim erneuten Laden ein EOBC-Verlust auftritt.
- Überprüfen Sie, ob eine Bereitstellung auf der BFD- oder Netflow-CPU in letzter Zeit Dienste beansprucht.
- Erfolgt die Fehlerbehebung mehrmals ohne Angaben von Informationen, ersetzen Sie die Hardware.
Paritätsfehler
N9K#show logging onboard stack-trace
**************************************************************
STACK TRACE GENERATED AT Tue Sep 21 02:27:58 2021 UTC
**************************************************************
<0>[88302546.800770] [1632158876] ERROR: MACHINE: Uncorrectable
<0>[88302546.809202] [1632158876] L2CACHE ERROR: Cause 0x88
<0>[88302546.814368] [1632158876] TAG Parity Error >>>>>Parity error
<0>[88302546.818750] [1632158876] Kernel panic - not syncing: L2CACHE ERROR
<4>[88302546.825212] [1632158876] Cpu: 0 Pid: 0, comm: swapper/0
Erläuterung
Ein Paritätsfehler tritt auf, wenn ein Informationsbit von 1 auf 0 oder 0 auf 1 gekippt wird.
Die meisten Paritätsfehler werden durch elektrostatische oder magnetbezogene Umgebungsbedingungen verursacht. Diese Ereignisse treten zufällig auf und können nicht verhindert werden. Systeme erkennen diesen Fehler und erzwingen einen Systemabsturz, um die Verarbeitung falscher Daten zu verhindern. Ein Vorkommen ist kein Hinweis auf ein Hardware- oder Softwareproblem.
Empfehlung
Paritätsfehler können ein vorübergehendes Single-Event-Upset (SEU) oder eine fehlerhafte Hardware sein. Um festzustellen, um was es sich handelt, müssen Sie das Gerät 48 Stunden lang überwachen, um festzustellen, ob eine Wiederholung auftritt.
Wenn innerhalb von 48 Stunden kein zweites Auftreten auftritt, wird das Problem als vorübergehend angesehen, und es ist keine Aktion erforderlich. Häufige oder wiederholbare (harte) Paritätsfehler werden durch eine physische Fehlfunktion des Speichers oder der zum Lesen und Schreiben verwendeten Schaltkreise verursacht. Tauschen Sie in diesem Fall die Hardware aus.
PCIE-Fehler
N9K#show logging onboard stack-trace
<6>[ 105.196227] CCTRL PANIC DUMP <6>[ 105.196229] ========================= <6>[ 105.196231] WDT last punched at 105192052644 <6>[ 105.196234] REG(0x60) = 3c <6>[ 105.196238] REG(0x64) = 0 <6>[ 105.196241] REG(0x300) = baadbeef <6>[ 105.196245] REG(0x304) = baadbeef <6>[ 105.196246] ========================= <0>[ 105.197303] nxos_panic: Kernel panic - not syncing: PCIE Uncorrectable error >>>>>PCIE Uncorrectable error
Erläuterung
PCIE-Fehler werden in zwei Arten unterteilt: behebbare und nicht behebbare Fehler. Diese Klassifizierung basiert auf den Auswirkungen dieser Fehler, die zu Leistungseinbußen oder Funktionsfehlern führen.
- Korrigierbare Fehler haben keine Auswirkungen auf die Funktionalität der Schnittstelle. Das PCIE-Protokoll kann ohne Softwareintervention oder Datenverlust wiederhergestellt werden. Diese Fehler werden von der Hardware erkannt und behoben.
- Nicht korrigierbare Fehler wirken sich auf die Funktionalität der Schnittstelle aus. Nicht korrigierbare Fehler führen dazu, dass eine bestimmte Transaktion oder eine bestimmte PCIE-Verbindung unzuverlässig ist. Abhängig von diesen Fehlerbedingungen werden nicht korrigierbare Fehler in nicht schwerwiegende Fehler und schwerwiegende Fehler klassifiziert.
- Nicht schwerwiegende Fehler führen dazu, dass die jeweilige Transaktion unzuverlässig ist, die PCIE-Verbindung selbst ist jedoch voll funktionsfähig.
- Schwerwiegende Fehler führen dagegen dazu, dass die Verbindung unzuverlässig ist.
Nexus 9000 erkennt schwerwiegende PCIE-Fehler und erzwingt ein Neuladen des Systems, um die Verarbeitung falscher Daten zu verhindern.
Empfehlung
Dies gilt auch für Paritätsfehler. Tritt innerhalb von 48 Stunden kein zweites Auftreten auf, wird das Problem als vorübergehend angesehen, es ist keine Aktion erforderlich. Häufige oder wiederholbare Fehler werden durch physische Fehlfunktionen verursacht. Tauschen Sie in diesem Fall die Hardware aus.
Watchdog-Zeitüberschreitung
N9K#show system reset-reason ----- reset reason for module 1 (from Supervisor in slot 1) --- 1) At 88659 usecs after Mon Sep 24 18:33:04 2023 Reason: Watchdog Timeout Service: Version: 7.0(3)I7(9)
Erläuterung
Watchdog-Zeitgeber sind häufig in eingebetteten Systemen und anderen computergesteuerten Geräten zu finden, auf die Benutzer nicht ohne Weiteres zugreifen können oder die nicht in der Lage wären, rechtzeitig auf Fehler zu reagieren. Nexus 9000 stellt eine Watchdog-Zeitgeberfunktion über FPGA bereit. So wird sichergestellt, dass der Nexus 9000 Softwareprobleme erkennen und den Switch umgehend neu starten kann.
Empfehlung
- Überprüfen Sie, ob bekannte Softwarefehler die aktuelle Version beeinträchtigen.
- Wenn das Problem erneut auftritt, sammeln Sie eine Kernel-Ablaufverfolgung und zusätzliche Protokollierungsdaten.
- Öffnen Sie ein Serviceticket.
Manuelles Neuladen aufgrund von CLI oder Upgrade
N9K# show system reset-reason
----- reset reason for module 1 (from Supervisor in slot 1) ---
1) At 343832 usecs after Sat Jan 13 17:58:53 2024
Reason: Reset Requested by CLI command reload
Service:
Version: 10.2(5)
>
4) At 282886 usecs after Fri Jan 12 07:42:33 2024
Reason: Reset due to upgrade
Service:
Version: 10.3(4a) >>>>>version prior to upgrading
Erläuterung
Die Nexus Switches der Serie 9000 unterstützen standardmäßig unterbrechungsfreie Software-Upgrades und -Downgrades. Der Nexus 9000 wird während eines Upgrades neu geladen.
Empfehlung
erwartetes Verhalten; Weitere Details zu CLI-Sitzungen finden Sie im Accounting-Protokoll.
Beispiel für CLI-Neuladen:
Sat Jan 13 17:58:40 2024:type=update:id=console0:user=admin:cmd=reload (REDIRECT)
Sat Jan 13 17:58:47 2024:type=update:id=console0:user=admin:cmd=Rebooting the switch
Beispiel für Upgrade-Neuladen:
Fri Jan 12 07:35:52 2024:type=update:id=console0:user=admin:cmd=install all nxos bootflash:/nxos64-cs.10.2.5.M.bin (SUCCESS)
Cisco Bug-IDs
Einige Fehler können ein unerwartetes erneutes Laden auf Nexus 9000-Switches verursachen. Um zu bestätigen, dass Sie einen bekannten Software-Fehler gefunden haben, öffnen Sie ein TAC-Ticket.
| Cisco Bug-ID | Bug-Titel | Version reparieren |
| Cisco Bug-ID CSCwd53591 | Aufgrund von Watchdog-Zeitüberschreitung ohne Kerne/Leiterbahnen neu laden | 9.3(13) |
| Cisco Bug-ID CSCvz65993 | tahoe0 heruntergefahren, was zu einem In-Band-Verbindungsausfall geführt hat | 9.3(9) |
| Cisco Bug-ID CSCvs00400 | Kernel-Panik und Neuladen aufgrund von Watchdog-Zeitüberschreitung nach Verbindungs-Flaps | 9.3(3) und 7.0(3)I7(8) |
| Cisco Bug-ID CSCvr57551 | Cisco Nexus 9000 wird mit Kernel Panic neu geladen - Kernel Paging-Anforderung kann nicht verarbeitet werden | 7.0(3)I7(8) und 9.3(4) |
| Cisco Bug-ID CSCvo86286 | Kernel-Panic bei 7.0(3)I7(x) mit Nexus 9500 Line Cards der 1. Generation | 7,0(3)I7(7) |
| Cisco Bug-ID CSCvx38752 | Speicherleck führt dazu, dass Nexus 9k "ipfib" neu lädt | 7.0(3)I7(9) und 9.3(2) |
| Cisco Bug-ID CSCvh13039 | LC/FM-Neuladevorgänge aufgrund von EOBC-Heartbeat als CPU-Auslastungs-Timer | 7.0(3)I4(8) und 7.0(3)I7(3) |
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
05-Jun-2026
|
Aktualisierte Rechtschreibung, Grammatik, Satzstruktur und Abstände. |
1.0 |
07-Feb-2024
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)