Resolución de problemas de recargas o caídas inesperadas en Nexus 9000

Introducción

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

Prerequisites

No hay requisitos previos 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 la alta disponibilidad (HA) en los niveles de red, sistema y proceso. Existen 3 razones por las que puede producirse una recarga inesperada en un switch 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é pasó 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 el resultado. 
• Si el switch no puede arrancar, acceda a través de la consola y compruebe si hay algún resultado. Compruebe también los LED del switch. Encontrará los detalles de los indicadores LED en la guía de instalación de hardware. 

Restablecimiento del sistema - Motivo

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 el 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.

Recomendación

1. Compruebe los cables de alimentación de todas las fuentes de alimentación.
2. Compruebe si otros dispositivos que comparten el mismo circuito de entrada también han sufrido 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 HA, incluido 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 de HA del proceso (NX-OS no puede funcionar durante un reinicio del proceso) o las veces que un reinicio del proceso alcanza su reintento máximo.  

Recomendación

`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ía de las caídas de procesos son defectos de software y el archivo principal se guarda. Abra un caso de solicitud de servicio para confirmarlo. 

• Un ingeniero del TAC puede descodificar los archivos de núcleo. 
• Para abrir la solicitud de servicio, elija Product > Reinicio inesperado > Error de software para asegurarse de que el caso se abra con el equipo correcto.

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

Los keepalives regulares EOBC (Ethernet Out of Band Channel) van entre el supervisor y las tarjetas de línea. Los mensajes de error que recibe 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 reinicia la tarjeta de línea.

Normalmente, hay tres razones por las que se produce un fallo del EOBC:

1. Congestión de EOBC. Verá que se ha perdido más de 1 tarjeta de línea EOBC.
2. Bloqueo de CPU en un módulo o módulos específicos. La CPU de la tarjeta de línea/supervisor está ocupada y no puede gestionar los mensajes EOBC. Hay una mejora de software a partir de Nexus 9000 de 7.0(3)I7(3). 
3. Falla de hardware. 

Recomendación

1. Verifique si el CPU acopla alguna tarjeta de línea afectada alrededor de la recarga.
2. Compruebe si alguna otra tarjeta de línea experimenta una pérdida EOBC durante la recarga.
3. Verifique si una implementación en la CPU de BFD o Netflow está consumiendo algún servicio recientemente.
4. Si se produce varias veces sin ninguna información, cambie 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 son causados por condiciones ambientales electrostáticas o magnéticas. Estos acontecimientos se producen de forma aleatoria y no pueden evitarse. Los sistemas detectan 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.

Recomendación

Los errores de paridad pueden ser un problema transitorio de evento único (SEU) o pueden estar causados por un 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 aparición en el plazo de 48 horas, el problema se considera transitorio y no se requiere ninguna acción. Los errores de paridad frecuentes o repetibles (graves) se deben a 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 hacen que una transacción determinada o un link PCIE determinado no sea confiable. En función de esas condiciones de error, los errores incorregibles se clasifican en errores no fatales y errores fatales.
  • Los errores no fatales hacen que la transacción en particular no sea confiable; sin embargo, 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. 

Recomendación

Esto es lo mismo con los errores de paridad. Si no se produce una segunda incidencia en el plazo de 48 horas, el problema se considera transitorio, por lo que no es necesario realizar ninguna acción. Los errores frecuentes o repetibles se deben a fallos de 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. Esto garantiza que Nexus 9000 pueda detectar el software y colgar y reiniciar el switch rápidamente.

Recomendación

1. Verifique si algún error de software conocido afecta a la versión actual.
2. Si el problema vuelve a ocurrir, recopile un 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. El Nexus 9000 se recarga durante una actualización.

Recomendación

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 defectos pueden provocar 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 Watchdog 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 de Watchdog 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)

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
2.0	05-Jun-2026	Ortografía, gramática, estructura de oraciones y espaciado actualizados.
1.0	07-Feb-2024	Versión inicial