Risoluzione dei problemi relativi a ricariche o arresti anomali imprevisti su Nexus 9000

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a ricaricamenti imprevisti o arresti anomali del sistema sugli switch Nexus 9000.

Prerequisiti

Non sono previsti prerequisiti per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Interruzione dello switch Nexus 9000

Cisco NX-OS è un sistema operativo resiliente progettato specificamente per l'alta disponibilità (HA, High Availability) a livello di rete, sistema e processo. Esistono tre motivi per cui può verificarsi un ricaricamento imprevisto su uno switch Nexus 9000:

• Un processo nello spazio utente potrebbe subire un arresto anomalo.
• Un processo o un componente hardware può sperimentare un timeout di watchdog o un errore di heartbeat.

• Il kernel stesso rileva una condizione irreversibile e si blocca.

Dati importanti per la risoluzione dei problemi di ricaricamento e arresto anomalo

• Data e ora esatte del ricaricamento.
• Cosa è successo prima del ricaricamento? Sono state apportate modifiche alla configurazione? Sono state apportate modifiche alla scala? Sono presenti registri nel dispositivo? Qualche cambiamento ambientale? L'utilizzo di CPU/memoria aumenta?
• Una volta avviato lo switch e stabilizzato, raccogliere e controllare l'output. 
• Se lo switch non si avvia, accedere tramite la console e verificare se è presente alcun output. Controllare inoltre i LED dello switch. I dettagli dei LED sono disponibili nella guida all'installazione dell'hardware. 

Motivo reimpostazione sistema

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)

File di base

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>

Registri integrati

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

Log di processo

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

File di registro da Logflash

Su Nexus 9000 è presente un logflash incorporato. I file di log vengono conservati dopo il ricaricamento.

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

Motivi di reimpostazione comuni

Ricaricamento relativo all'alimentazione

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: 

Spiegazione

Lo switch Nexus 9000 supporta la ridondanza dell'alimentazione N+1. Se si verifica un'interruzione dell'alimentazione sulla maggior parte o su tutte le fonti di alimentazione, si verifica un ricaricamento.

Suggerimento

1. Verificare i cavi di alimentazione di tutti gli alimentatori.
2. Verificare se anche altri dispositivi che condividono lo stesso circuito di ingresso hanno subito un'interruzione.
3. Controllare se sono presenti allarmi relativi all'alimentazione su Nexus 9000 o PDU.

Arresto anomalo del processo

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)

Spiegazione

Ogni servizio dispone di criteri HA specifici, inclusi un timer di heartbeat, un metodo di riavvio e un numero massimo di tentativi di riavvio con stato. Il software Cisco NX-OS consente il riavvio stateful della maggior parte dei processi e dei servizi. Il ricaricamento si verifica se il criterio HA del processo viene reimpostato (NX-OS non è in grado di funzionare durante un riavvio del processo) o quando un riavvio del processo raggiunge il numero massimo di tentativi.  

Suggerimento

`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>

La maggior parte dei arresti anomali dei processi sono difetti del software e il file principale viene salvato. Aprire una richiesta di assistenza per confermarla. 

• I file core possono essere decodificati da un tecnico TAC. 
• Per aprire la richiesta di assistenza, scegliere Prodotto > Riavvio imprevisto > Errore software per assicurarsi che la richiesta venga aperta con il team corretto.

Errore EOBC

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)

Spiegazione

I normali pacchetti keepalive EOBC (Ethernet Out of Band Channel) vengono scambiati tra il supervisore e le schede di linea. I messaggi di errore ricevuti indicano che manca un heartbeat tra SUP e la scheda di linea. Se manca un solo heartbeat, è possibile ignorarlo automaticamente. Tuttavia, se più heartbeat vengono persi contemporaneamente, la scheda di linea viene reimpostata.

In genere un errore EOBC è dovuto a tre motivi:

1. Congestione EOBC. Si vede più di 1 linecard EOBC perso.
2. Hop CPU in uno o più moduli specifici. La CPU di Linecard/Supervisor è occupata e non è in grado di gestire i messaggi EOBC. È disponibile un miglioramento del software a partire da Nexus 9000 a partire da 7.0(3)I7(3). 
3. Guasto hardware. 

Suggerimento

1. Verificare se il bug della CPU è associato a una scheda di linea interessata dal ricaricamento.
2. Verificare se un'altra scheda di linea ha subito una perdita EOBC durante il ricaricamento.
3. Verificare se una distribuzione nella CPU BFD o Netflow sta utilizzando servizi di recente.
4. Se si verifica più volte senza alcuna informazione, sostituire l'hardware. 

Errore di parità

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

Spiegazione

Un errore di parità si verifica quando un bit di informazioni viene invertito da 1 a 0 o da 0 a 1.

La maggior parte degli errori di parità è causata da condizioni ambientali elettrostatiche o magnetiche. Questi eventi si verificano casualmente e non possono essere prevenuti. I sistemi rilevano questo errore e forzano il sistema a bloccarsi per impedire l'elaborazione di dati errati. Un'occorrenza non è un'indicazione di un problema hardware o software.

Suggerimento

Gli errori di parità possono essere un problema temporaneo a singolo evento (SEU, Single-Event Turbo) o possono essere causati da hardware difettoso. Per determinare quale sia, è necessario monitorare il dispositivo per 48 ore per verificare se ha una ricorrenza.

Se non si verifica una seconda occorrenza entro 48 ore, il problema è considerato transitorio e non è necessaria alcuna azione. Errori di parità frequenti o ripetibili (rigidi) sono causati da malfunzionamento fisico della memoria o dei circuiti utilizzati per la lettura e la scrittura. In questi casi, sostituire l'hardware.

Errore PCIE

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

Spiegazione

Gli errori PCIE sono classificati in due tipi: errori correggibili ed errori non correggibili. Questa classificazione si basa sull'impatto di tali errori, che determinano una riduzione delle prestazioni o un errore funzionale.

• Gli errori correggibili non incidono sulla funzionalità dell'interfaccia. Il protocollo PCIE può essere ripristinato senza alcun intervento del software o perdita di dati. Questi errori vengono rilevati e corretti dall'hardware.

• Errori non correggibili influiscono sulla funzionalità dell'interfaccia. Errori non correggibili causano l'inaffidabilità di una particolare transazione o di un particolare collegamento PCIE. A seconda delle condizioni di errore, gli errori non correggibili vengono classificati come errori non irreversibili e come errori irreversibili.
  • Gli errori non irreversibili causano l'inaffidabilità della transazione specifica, tuttavia il collegamento PCIE stesso è completamente funzionante.
  • Errori irreversibili, invece, rendono il collegamento inaffidabile.

Nexus 9000 rileva errori PCIE irreversibili e forza il sistema a ricaricarsi per impedire l'elaborazione di dati non corretti. 

Suggerimento

Lo stesso vale per gli errori di parità. Se non si verifica una seconda occorrenza entro 48 ore, il problema è considerato transitorio, non è necessaria alcuna azione. Errori frequenti o ripetibili sono causati da malfunzionamenti fisici. In questi casi, sostituire l'hardware.

Timeout watchdog

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)

Spiegazione

I timer di watchdog si trovano comunemente nei sistemi incorporati e in altre apparecchiature controllate dal computer in cui gli esseri umani non possono accedere facilmente alle apparecchiature o non sarebbero in grado di reagire tempestivamente ai guasti. Nexus 9000 installa una funzionalità di timer di watchdog tramite FPGA. In questo modo Nexus 9000 è in grado di rilevare il blocco del software e riavviare lo switch immediatamente.

Suggerimento

1. Verificare se eventuali bug noti del software influiscono sulla versione corrente.
2. Se il problema si verifica di nuovo, raccogliere una traccia del kernel ed eventuali dati di registrazione aggiuntivi.
3. Apri una richiesta di assistenza.

Ricaricamento manuale a causa di CLI o aggiornamento

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

Spiegazione

Per impostazione predefinita, gli switch Nexus serie 9000 supportano le interruzioni delle attività di aggiornamento e downgrade del software. Nexus 9000 viene ricaricato durante un aggiornamento.

Suggerimento

comportamento previsto; per ulteriori dettagli sulla sessione CLI, controllare il registro di accounting. 

Esempio di ricaricamento CLI:

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

Esempio di ricaricamento aggiornamento:

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)

ID bug Cisco

Alcuni difetti possono causare un ricaricamento imprevisto sugli switch Nexus 9000. Per verificare se è stato rilevato un bug software noto, aprire una richiesta TAC.

ID bug Cisco	Titolo bug	Correggi versione
ID bug Cisco CSCwd53591	Ricarica a causa del timeout di Watchdog senza core/tracce	9.3(13)
ID bug Cisco CSCvz65993	tahoe0 interrotta con conseguente errore di connettività in banda	9.3(9)
ID bug Cisco CSCvs00400	Si è verificato un errore irreversibile del kernel e il caricamento è dovuto al timeout di Watchdog dopo i flap del collegamento	9.3(3) e 7.0(3)I7(8)
ID bug Cisco CSCvr5751	Cisco Nexus 9000 viene ricaricato con errore irreversibile del kernel. Impossibile gestire la richiesta di paging del kernel	7.0(3)I7(8) e 9.3(4)
ID bug Cisco CSCvo86286	Problema kernel su schede di linea 7.0(3)I7(x) con Nexus 9500 di prima generazione	7.0(3)I7(7)
ID bug Cisco CSCvx38752	Perdita di memoria che causa il ricaricamento di "ipfib" di Nexus 9k	7.0(3)I7(9) e 9.3(2)
ID bug Cisco CSCvh13039	Ricaricamenti LC/FM dovuti a heartbeat EOBC come CPU occupata a servire il timer	7.0(3)I4(8) e 7.0(3)I7(3)

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
2.0	05-Jun-2026	Controllo ortografico, grammaticale, struttura della frase e spaziatura aggiornati.
1.0	07-Feb-2024	Versione iniziale