Resolución de problemas de recargas o fallos inesperados en Nexus 9000

Introducción

Este documento ddescribe cómo resolver problemas de recargas o caídas inesperadas en switches Nexus 9000.

Prerequisites

No hay requisitos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Cómo se rompe el switch Nexus 9000

Cisco NX-OS es un sistema operativo resistente diseñado específicamente para ofrecer una alta disponibilidad en los niveles de red, sistema y proceso.

Hay 3 razones por las que puede producirse una recarga inesperada en Nexus 9000:

• Un proceso en el espacio de usuario podría experimentar una caída.
• Un proceso o pieza de hardware podría experimentar un tiempo de espera de vigilancia o un fallo de latido.

• El núcleo mismo encuentra una condición irrecuperable y falla.

Datos importantes para solucionar problemas de recarga y desperfecto

• La fecha y hora exactas de la recarga.
• ¿Qué pasaba antes de la recarga? ¿Algún cambio de configuración? ¿Algún cambio de escala? ¿Algún registro en el dispositivo? ¿Algún cambio ambiental? ¿Aumenta el uso de memoria/CPU?
• Una vez que el switch se inicie y sea estable, recopile y verifique la salida. 
• Si el switch no puede encenderse, acceda a través de la consola y compruebe si hay alguna salida. Compruebe también los LED del switch. Encontrará los detalles de los indicadores LED en la guía de instalación de hardware. 

System Reset-reason

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)

Archivo principal

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>

Registros incluidos

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

Registro de procesos

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

Archivos de registro desde Logflash

Hay un logflash integrado en Nexus 9000, los archivos de registro sobreviven después de la recarga.

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

Razones comunes de reinicio

Recarga relacionada con la alimentación

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: 

Explicación

El switch Nexus 9000 admite redundancia de alimentación N+1. Si se produce un corte de energía en la mayoría o en todas las fuentes de energía, se produce una recarga.

Recomendado:

1. Compruebe los cables de alimentación de las fuentes de alimentación.

2. Verifique si otros dispositivos que comparten el mismo circuito de entrada también tuvieron una interrupción.

3. Compruebe si hay alguna alarma relacionada con la alimentación en Nexus 9000 o PDU.

Bloqueo de procesos

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)

Explicación

Cada servicio tiene su propia política de alta disponibilidad (HA), que incluye un temporizador de latidos, un método de reinicio y un reintento máximo de reinicio stateful. El software Cisco NX-OS permite reinicios stateful de la mayoría de los procesos y servicios. La recarga se produce si se restablece la política del proceso (NX-OS no puede funcionar durante el reinicio del proceso) o si las horas del reinicio del proceso alcanzan el máximo de reintentos.  

Recomendado

`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 mayor parte de la caída del proceso es un defecto de software y el archivo principal se guarda, abra un caso de solicitud de servicio para confirmar. 

• El ingeniero del TAC puede descodificar los archivos de núcleo. 
• Para abrir la solicitud de servicio, seleccione Product > Unexpected Reboot > Software Failure para abrir el caso con el equipo adecuado.

Falla de 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)

Explicación

El EOBC es la abreviatura de Ethernet Out of Band Channel (Canal fuera de banda Ethernet). Las señales de mantenimiento regulares se transmiten entre el supervisor y las tarjetas de línea. Los mensajes de error que ha recibido indican que falta un latido entre el SUP y la tarjeta de línea. Si falta un solo latido, se puede ignorar automáticamente. Sin embargo, si se pierden varios latidos simultáneamente, se restablecerá la tarjeta de línea.

Generalmente hay 3 razones para la falla del EOBC:
1. Congestión de la EOBC. Puede ver más de 1 experiencia de tarjeta de línea EOBC perdida.
2. Bloqueo de CPU en módulos específicos. La CPU de la tarjeta de línea/supervisor está ocupada y no puede gestionar los mensajes de EOBC. Hay una mejora de software a partir de Nexus 9000 de 7.0(3)I7(3). 
3. Falla de hardware. 

Recomendado

1. Verifique si algún CPUhog encuentra la tarjeta de línea afectada alrededor de la recarga.

2. Compruebe si otra tarjeta de línea experimenta pérdida EOBC al recargar. 

3. Compruebe si BFD implementado o el servicio que consume la CPU de Netflow recientemente. 

4. Si ocurre varias veces sin ninguna información, reemplace el hardware. 

Error de paridad

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

Explicación

Se produce un error de paridad cuando un bit de información se voltea de 1 a 0 o de 0 a 1.

La mayoría de los errores de paridad se deben a condiciones ambientales electrostáticas o magnéticas. Estos acontecimientos se producen de forma aleatoria y no pueden prevenirse.

Los sistemas detectan que se ha producido este error y obligan al sistema a bloquearse para evitar que se procesen datos incorrectos. Una aparición no es un indicio de un problema de hardware o software.

Recomendado

Los errores de paridad pueden ser alteraciones transitorias de un solo evento (SEU) o pueden ser causados por hardware defectuoso. Para determinar cuál es, debe supervisar el dispositivo durante 48 horas para ver si se repite.

Si no se produce una segunda incidencia en el plazo de 48 horas, el problema se considera transitorio, no es necesario realizar ninguna acción. 

Los errores de paridad frecuentes o repetibles (graves) son causados por un mal funcionamiento físico de la memoria o del circuito utilizado para leer y escribir. En estos casos, sustituya el hardware.

Error 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

Explicación

Los errores PCIE se clasifican en dos tipos: errores corregibles y errores incorregibles. Esta clasificación se basa en el impacto de esos errores, que da lugar a un rendimiento degradado o a un fallo de la función.

Los errores corregibles no afectan a la funcionalidad de la interfaz. El protocolo PCIE puede recuperarse sin intervención del software ni pérdida de datos. El hardware detecta y corrige estos errores.

Los errores incorregibles afectan a la funcionalidad de la interfaz. Los errores incorregibles pueden hacer que una transacción en particular o un link PCIE en particular no sea confiable. Dependiendo de esas condiciones de error, los errores incorregibles se clasifican además en errores no fatales y errores fatales. Los errores no fatales hacen que la transacción en particular no sea confiable, pero el link PCIE en sí es completamente funcional. Los errores fatales, por otro lado, hacen que el link no sea confiable.

Nexus 9000 detecta errores PCIE fatales y obliga al sistema a recargarse para evitar que se procesen datos incorrectos. 

Recomendado

Igual con error de paridad. 

Si no se produce una segunda incidencia en el plazo de 48 horas, el problema se considera transitorio, no es necesario realizar ninguna acción. 

Los errores frecuentes o repetibles se deben a un mal funcionamiento físico. En estos casos, sustituya el hardware.

Tiempo de espera

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)

Explicación

Los temporizadores de vigilancia se encuentran comúnmente en sistemas integrados y otros equipos controlados por computadora donde los humanos no pueden acceder fácilmente al equipo o no podrían reaccionar a los fallos de manera oportuna.
Nexus 9000 implementa una función de temporizador de vigilancia mediante FPGA. Esto garantiza que Nexus 9000 pueda detectar el software y colgar y reiniciar el switch rápidamente.

Recomendado

1. Verifique si algún error de software conocido afecta a la versión actual.

2. Si el problema vuelve a ocurrir, recopile el seguimiento del núcleo y cualquier dato de registro adicional.

3. Abra un caso de solicitud de servicio.

Recarga manual debido a CLI o actualización

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

Explicación

De forma predeterminada, los switches Nexus serie 9000 admiten actualizaciones y reversiones de software que provocan interrupciones. Nexus 9000 se recarga durante la actualización.

Recomendado

Comportamiento esperado. Consulte el registro de cuentas para obtener más detalles de la sesión CLI. 

Ejemplo de recarga de 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

Ejemplo de recarga de actualización:

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 de errores de Cisco

Algunos de los defectos pueden causar una recarga inesperada en los switches Nexus 9000. Para confirmar si se ha producido un error de software conocido, abra un caso TAC.

ID de falla de funcionamiento de Cisco	Título del error	Versión de corrección
ID de bug de Cisco CSCwd53591	Recarga debido al tiempo de espera de vigilancia sin núcleos/seguimientos	9.3(13)
ID de bug de Cisco CSCvz65993	tahoe0 se ha caído, lo que provoca un fallo de conectividad dentro de la banda	9.3(9)
ID de bug de Cisco CSCvs00400	Pánico del núcleo y recarga debido al tiempo de espera del vigilante después de inestabilidades del link	9.3(3) y 7.0(3)I7(8)
ID de bug de Cisco CSCvr57551	Cisco Nexus 9000 se recarga con el pánico del núcleo; no se puede gestionar la solicitud de localización del núcleo	7.0(3)I7(8) y 9.3(4)
ID de bug de Cisco CSCvo86286	Panorama del núcleo observado en 7.0(3)I7(x) con tarjetas de línea Nexus 9500 de 1ª generación	7.0(3)I7(7)
ID de bug de Cisco CSCvx38752	Pérdida de memoria que hace que Nexus 9k recargue "ipfib"	7.0(3)I7(9) y 9.3(2)
ID de bug de Cisco CSCvh13039	LC/FM se recarga debido al latido EOBC mientras la CPU está ocupada con el temporizador de servicio	7.0(3)I4(8) y 7.0(3)I7(3)