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

Introduzione

Questo documento ddescrizioni come risolvere i problemi relativi a ricariche impreviste o arresti anomali sugli switch Nexus 9000.

Prerequisiti

Nessun requisito previsto 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 garantire un'elevata disponibilità a livello di rete, sistema e processo.

Esistono 3 motivi per cui può verificarsi un ricaricamento imprevisto su 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 stava succedendo 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 della CPU e della memoria è aumentato?
• Una volta avviato lo switch e stabilizzato, raccogliere e controllare l'output. 
• Se lo switch non si solleva, accedere tramite la console e controllare se sono presenti uscite. 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.

Consigliato:

1. Verificare i cavi di alimentazione degli alimentatori.

2. Verificare se anche altri dispositivi che condividono lo stesso circuito di ingresso hanno subito un'interruzione.

3. Verificare 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 di disponibilità elevata, 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 può funzionare durante il riavvio del processo) o se l'ora di riavvio del processo raggiunge il numero massimo di tentativi.  

Consigliato

`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 del processo di arresto anomalo è difetto del software e il file principale viene salvato. Aprire una richiesta di assistenza per confermare. 

• I file core possono essere decodificati dal tecnico TAC. 
• Per aprire la richiesta di assistenza, scegliere Prodotto > Riavvio imprevisto > Errore software per aprire la richiesta con il team appropriato.

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

L'EOBC è l'abbreviazione di Ethernet Out of Band Channel. Normalmente i pacchetti keepalive passano tra il supervisore e le schede di linea. I messaggi di errore ricevuti indicano che manca un heartbeat tra SUP e linecard. Se manca un solo heartbeat, è possibile ignorarlo automaticamente. Tuttavia, se più heartbeat vengono persi contemporaneamente, la scheda di linea viene reimpostata.

Di solito ci sono 3 motivi per il fallimento di EOBC:
1. Congestione dell'EOBC. È possibile vedere più di 1 linecard esperienza EOBC perso.
2. Teppo della CPU in 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. 

Consigliato

1. Verificare se CPUhog ha problemi con la scheda di linea in fase di ricaricamento.

2. Verificare se altre linecard subiscono perdite EOBC durante il ricaricamento. 

3. Verificare se il servizio di utilizzo CPU BFD o Netflow è stato recentemente distribuito. 

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 che si è verificato 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.

Consigliato

Gli errori di parità possono essere temporanei guasti a singoli eventi (SEU) oppure possono essere causati da hardware difettoso. Per determinare la ricorrenza, è 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, non è necessaria alcuna azione. 

Errori di parità frequenti o ripetibili (rigidi) sono causati da malfunzionamento fisico della memoria o dei circuiti utilizzati per leggere e scrivere. 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 possono rendere inaffidabile una particolare transazione o un particolare collegamento PCIE. A seconda di tali condizioni di errore, gli errori non correggibili vengono ulteriormente classificati come errori non irreversibili ed errori irreversibili. Gli errori non irreversibili rendono la transazione particolare inaffidabile, ma 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. 

Consigliato

Lo stesso vale per l'errore 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 malfunzionamento fisico. 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 dove gli esseri umani non possono accedere facilmente alle apparecchiature o sarebbero incapaci di reagire tempestivamente ai guasti.
Nexus 9000 implementa una funzione di timer di watchdog tramite FPGA. In questo modo Nexus 9000 è in grado di rilevare il blocco del software e riavviare lo switch immediatamente.

Consigliato

1. Verificare se eventuali bug software noti influiscono sulla versione corrente.

2. Se il problema si ripresenta, raccogliere la traccia del kernel ed eventuali dati di registrazione aggiuntivi.

3. Aprire 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 l'aggiornamento.

Consigliato

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 errori 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 è stato causato dal timeout del watchdog dopo i link flap	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)