Fehlerbehebung bei unerwarteten Neustarts oder Abstürzen des Nexus 9000

Einleitung

Dieses Dokument gbeschreiben wie unerwartete Neuladevorgänge oder Abstürze auf Nexus 9000-Switches behoben werden.

Voraussetzungen

Für dieses Dokument bestehen keine Anforderungen.

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 eine hohe Verfügbarkeit auf Netzwerk-, System- und Prozessebene konzipiert wurde.

Es gibt drei Gründe für ein unerwartetes Neuladen auf dem Nexus 9000:

• 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, wird die Ausgabe erfasst und geprüft. 
• Wenn der Switch nicht hochgefahren werden kann, greifen Sie über die Konsole auf 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. 

Grund für das Zurücksetzen des Systems

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.

Empfohlen:

1. Überprüfen Sie die Netzkabel der Netzteile.

2. Überprüfen Sie, ob andere Geräte, die den gleichen Einlasskreis nutzen, ebenfalls ausgefallen sind.

3. Überprüfen Sie, ob ein Alarm zur Stromversorgung beim Nexus 9000 oder der PDU vorliegt.

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 (High Availability), 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 der Prozess eine Richtlinie hat, zurückgesetzt wird (NX-OS kann während des Prozessneustarts nicht funktionieren) oder wenn die Zeiten des Prozessneustarts die maximale Anzahl an Wiederholungen erreichen.  

Empfohlen

`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 Prozess Absturz ist Software-Defekt und die Kerndatei gespeichert wird, öffnen Sie einen Service-Anfrage Fall zu bestätigen. 

• Kerndateien können vom TAC-Engineer decodiert werden. 
• Um die Serviceanfrage zu öffnen, wählen Sie Product > Unexpected Reboot > Software Failure (Produkt > Unerwarteter Neustart > Softwarefehler), um das Ticket mit dem richtigen Team zu öffnen.

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

Das EOBC ist die Kurzform für Ethernet Out of Band Channel (Ethernet Out-of-Band-Kanal). Zwischen dem Supervisor und den Line Cards finden regelmäßige Keepalives statt. Die Fehlermeldungen, die Sie erhalten haben, zeigen an, dass zwischen SUP und 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.

Für das EOBC-Versagen gibt es in der Regel drei Gründe:
1. EOBC-Überlastung. Sie können sehen, mehr als 1 Linecard Erfahrung EOBC verloren.
2. CPU-Hog in bestimmten Modulen Die Linecard-/Supervisor-CPU ist ausgelastet und kann EOBC-Meldungen nicht verarbeiten. Ab Nexus 9000 gibt es eine Softwareerweiterung, die mit 7.0(3)I7(3) beginnt. 
3. Hardwarefehler. 

Empfohlen

1. Überprüfen Sie, ob CPUhog für die Linecard betroffen beim Neuladen.

2. Überprüfen Sie, ob andere Linecards EOBC-Verlust beim Neuladen erleben. 

3. Überprüfen Sie, ob kürzlich ein BFD- oder Netflow CPU-Nutzungsservice bereitgestellt wurde. 

4. Wenn es mehrere Male ohne Informationen auftritt, 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 magnetische Umgebungsbedingungen verursacht. Diese Ereignisse treten zufällig auf und können nicht verhindert werden.

Systeme erkennen, dass dieser Fehler aufgetreten ist, und zwingen das System zum Absturz, um zu verhindern, dass falsche Daten verarbeitet werden. Ein Vorkommen ist kein Hinweis auf ein Hardware- oder Softwareproblem.

Empfohlen

Paritätsfehler können vorübergehende Einzelereignisstörungen (SEU) sein oder durch defekte Hardware verursacht werden. Um dies zu bestimmen, müssen Sie das Gerät 48 Stunden lang überwachen, um festzustellen, ob es eine Wiederholung aufweist.

Wenn das Problem innerhalb von 48 Stunden kein zweites Mal auftritt, wird es als vorübergehend angesehen, und es ist keine Maßnahme erforderlich. 

Häufige oder wiederholbare (harte) Paritätsfehler werden durch eine physikalische Fehlfunktion des Speichers oder der zum Lesen und Schreiben verwendeten Schaltung 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: korrigierbare Fehler und nicht korrigierbare 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 können dazu führen, dass eine bestimmte Transaktion oder eine bestimmte PCIE-Verbindung unzuverlässig ist. Abhängig von diesen Fehlerbedingungen werden nicht korrigierbare Fehler weiter in nicht schwerwiegende Fehler und schwerwiegende Fehler unterteilt. Nicht schwerwiegende Fehler führen dazu, dass die jeweilige Transaktion unzuverlässig ist, aber die PCIE-Verbindung selbst ist 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. 

Empfohlen

Gleiches gilt für Paritätsfehler. 

Wenn das Problem innerhalb von 48 Stunden kein zweites Mal auftritt, wird es als vorübergehend angesehen, und es ist keine Maßnahme erforderlich. 

Häufige oder wiederholbare Fehler werden durch physikalische Störungen 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 kommen häufig in eingebetteten Systemen und anderen computergesteuerten Geräten vor, wenn der Mensch nicht ohne Weiteres auf diese Geräte zugreifen kann oder nicht in der Lage wäre, rechtzeitig auf Fehler zu reagieren.
Der Nexus 9000 stellt über FPGA eine Watchdog-Zeitgeberfunktion bereit. So wird sichergestellt, dass der Nexus 9000 Softwareprobleme erkennen und den Switch umgehend neu starten kann.

Empfohlen

1. Überprüfen Sie, ob bekannte Softwarefehler die aktuelle Version beeinträchtigen.

2. Wenn das Problem erneut auftritt, sammle die Kernelablaufverfolgung und alle zusätzlichen Protokolldaten.

3. Ö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 des Upgrades neu geladen.

Empfohlen

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 der Fehler können ein unerwartetes Neuladen auf Nexus 9000-Switches verursachen. Um zu bestätigen, dass Sie einen bekannten Softwarefehler gefunden haben, öffnen Sie ein TAC-Ticket.

Cisco Bug-ID	Bug-Titel	Version reparieren
Cisco Bug-ID CSCwd53591	Aufgrund einer 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 Verbindungsflaps	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)