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.
Dieses Dokument gbeschreiben wie unerwartete Neuladevorgänge oder Abstürze auf Nexus 9000-Switches behoben werden.
Für dieses Dokument bestehen keine Anforderungen.
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.
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:
Der Kernel selbst befindet sich in einem nicht wiederherstellbaren Zustand und stürzt ab.
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)
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>
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
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
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
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:
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.
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.
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)
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.
`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.
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)
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.
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.
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
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.
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.
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
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.
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.
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)
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.
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.
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
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.
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)
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) |
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
07-Feb-2024 |
Erstveröffentlichung |