Solucionar recargas ou travamentos inesperados no Nexus 9000

Introdução

Este documento descreve como solucionar problemas de recarregamentos inesperados ou travamentos em switches Nexus 9000.

Pré-requisitos

Não há pré-requisitos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Como o switch Nexus 9000 quebra

O Cisco NX-OS é um sistema operacional resiliente projetado especificamente para alta disponibilidade (HA) nos níveis de rede, sistema e processo. Há três motivos para uma recarga inesperada em um switch Nexus 9000:

• Um processo no espaço do usuário pode sofrer um travamento.
• Um processo ou peça de hardware pode sofrer um timeout de vigilante ou falha de pulsação.

• O próprio kernel encontra uma condição irrecuperável e trava.

Dados importantes para solucionar problemas de recarregamento e travamento

• A data e a hora exatas do recarregamento.
• O que aconteceu antes do recarregamento? Alguma alteração de configuração? Alguma mudança de escala? Algum registro no dispositivo? Alguma mudança ambiental? Algum uso de CPU/memória aumenta?
• Quando o switch for inicializado e estiver estável, colete e verifique a saída. 
• Se o switch não conseguir inicializar, acesse através do console e verifique se há alguma saída. Verifique também os LEDs do switch. Você pode encontrar detalhes de LED no guia de instalação de hardware. 

Razão da redefinição do 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)

Arquivo de núcleo

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>

Logs integrados

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

Arquivos de log do Logflash

Há um flash de log integrado no Nexus 9000, os arquivos de log sobrevivem após o recarregamento.

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

Razões comuns de reinicialização

Recarga relacionada à energia

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: 

Explicação

O switch Nexus 9000 comporta redundância de energia N+1. Se ocorrer uma queda de energia na maioria das fontes de alimentação ou em todas elas, ocorrerá uma recarga.

Recomendação

1. Verifique os cabos de alimentação de todas as fontes de alimentação.
2. Verifique se outros dispositivos que compartilham o mesmo circuito de entrada também tiveram uma interrupção.
3. Verifique se há algum alarme relacionado à alimentação no Nexus 9000 ou PDU.

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

Explicação

Cada serviço tem sua própria política de HA, incluindo um temporizador de pulsação, método de reinicialização e repetição máx. de reinicialização stateful. O software Cisco NX-OS permite reinicializações stateful da maioria dos processos e serviços. O recarregamento ocorre se a política de HA do processo for redefinida (o NX-OS não pode funcionar durante uma reinicialização do processo) ou quando uma reinicialização do processo atinge seu máximo de repetição.  

Recomendação

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

A maioria dos travamentos de processo são defeitos de software e o arquivo principal é salvo. Abra um caso de solicitação de serviço para confirmar. 

• Os arquivos principais podem ser decodificados por um engenheiro do TAC. 
• Para abrir a solicitação de serviço, escolha Product > Unexpected Reboot > Software Failure para garantir que o caso seja aberto com a equipe correta.

Falha 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)

Explicação

Os keepalives regulares do EOBC (Ethernet Out of Band Channel) vão entre o supervisor e as placas de linha. As mensagens de erro que você recebe indicam que uma pulsação foi perdida entre o SUP e a placa de linha. Se uma única pulsação for perdida, ela poderá ser ignorada automaticamente. No entanto, se várias pulsações forem perdidas simultaneamente, a placa de linha será redefinida.

Geralmente, há três motivos para uma falha de EOBC:

1. Congestionamento de EOBC. Você vê mais de 1 EOBC de placa de linha perdido.
2. CPU hog em um módulo específico. A CPU da placa de linha/supervisor está ocupada e não pode tratar mensagens EOBC. Há um aprimoramento de software a partir do Nexus 9000 da versão 7.0(3)I7(3). 
3. Falha do hardware. 

Recomendação

1. Verifique se a CPU está sobrecarregada em busca de qualquer placa de linha afetada ao redor da recarga.
2. Verifique se alguma outra placa de linha está sofrendo perda de EOBC ao redor do recarregamento.
3. Verifique se uma implantação para a CPU BFD ou Netflow está consumindo algum serviço recentemente.
4. Se ocorrer várias vezes sem nenhuma informação, substitua o hardware. 

Erro de paridade

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

Explicação

Um erro de paridade ocorre quando um bit de informação é invertido de 1 para 0 ou de 0 para 1.

A maioria dos erros de paridade é causada por condições ambientais eletrostáticas ou relacionadas à magnética. Esses eventos ocorrem aleatoriamente e não podem ser evitados. Os sistemas detectam que esse erro ocorreu e forçam o sistema a travar para evitar que dados incorretos sejam processados. Uma ocorrência não é uma indicação de um problema de hardware ou software.

Recomendação

Os erros de paridade podem ser um conjunto de evento único (SEU) transitório ou podem ser causados por hardware defeituoso. Para determinar qual é, você deve monitorar o dispositivo por 48 horas para ver se ele tem uma recorrência.

Se não houver uma segunda ocorrência em 48 horas, o problema será considerado transitório e nenhuma ação será necessária. Erros de paridade frequentes ou repetitivos (hard) são causados por mau funcionamento físico da memória ou do circuito usado para ler e gravar. Nesses casos, substitua o hardware.

Erro de 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

Explicação

Os erros de PCIE são classificados em dois tipos: erros corrigíveis e erros incorrigíveis. Essa classificação é baseada no impacto desses erros, que resulta em desempenho degradado ou falha de função.

• Erros corrigíveis não causam impacto na funcionalidade da interface. O protocolo PCIE pode ser recuperado sem qualquer intervenção de software ou perda de dados. Esses erros são detectados e corrigidos pelo hardware.

• Erros incorrigíveis afetam a funcionalidade da interface. Erros incorrigíveis fazem com que uma transação específica ou um link PCIE específico não seja confiável. Dependendo dessas condições de erro, os erros incorrigíveis são classificados em erros não fatais e erros fatais.
  • Erros não fatais fazem com que a transação específica não seja confiável, no entanto, o próprio link PCIE é totalmente funcional.
  • Os erros fatais, por outro lado, fazem com que o link não seja confiável.

O Nexus 9000 detecta erros fatais de PCIE e força o sistema a ser recarregado para evitar que dados incorretos sejam processados. 

Recomendação

Isso é o mesmo com erros de paridade. Se não houver uma segunda ocorrência em 48 horas, o problema será considerado transitório, nenhuma ação será necessária. Erros frequentes ou repetidos são causados por defeitos físicos. Nesses casos, substitua o hardware.

Tempo Limite do 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)

Explicação

Temporizadores watchdog são comumente encontrados em sistemas incorporados e outros equipamentos controlados por computador onde humanos não podem facilmente acessar o equipamento ou seriam incapazes de reagir a falhas de uma maneira oportuna. Nexus 9000 implanta um recurso de temporizador watchdog via FPGA. Isso garante que o Nexus 9000 possa detectar o travamento do software e reinicializar o switch imediatamente.

Recomendação

1. Verifique se algum bug de software conhecido afeta a versão atual.
2. Se o problema ocorrer novamente, colete um rastreamento de kernel e quaisquer dados de registro adicionais.
3. Abra um caso de solicitação de serviço.

Recarregar manualmente devido a CLI ou atualização

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

Explicação

Por padrão, os switches Nexus 9000 Series oferecem suporte a atualizações e downgrades de software que causam interrupções. O Nexus 9000 é recarregado durante uma atualização.

Recomendação

Comportamento previsto; verifique o registro de contabilização para obter mais detalhes da sessão CLI. 

Exemplo de recarregamento 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

Exemplo de recarregamento de atualização:

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)

IDs de bug da Cisco

Alguns defeitos podem causar uma recarga inesperada nos switches Nexus 9000. Para confirmar se você detectou um bug de software conhecido, abra um caso no TAC.

ID de bug da Cisco	Título do Erro	Corrigir Versão
ID de bug da Cisco CSCwd53591	Recarregar devido ao tempo limite do Watchdog sem núcleos/rastreamentos	9.3(13)
ID de bug da Cisco CSCvz65993	tahoe0 desativado, resultando em falha de conectividade inband	9.3(9)
ID de bug da Cisco CSCvs00400	Pane e recarga do kernel devido ao tempo limite do Watchdog após oscilações de link	9.3(3) e 7.0(3)I7(8)
ID de bug da Cisco CSCvr57551	Recarregamento do Cisco Nexus 9000 com pânico de kernel - não é possível lidar com a solicitação de paginação de kernel	7.0(3)I7(8) e 9.3(4)
ID de bug da Cisco CSCvo86286	Pane de kernel observada no 7.0(3)I7(x) com placas de linha Nexus 9500 de primeira geração	7.0(3)I7(7)
ID de bug da Cisco CSCvx38752	Vazamento de memória, fazendo com que o Nexus 9k recarregue o "ipfib"	7.0(3)I7(9) e 9.3(2)
ID de bug da Cisco CSCvh13039	Recarregamentos de LC/FM devido à pulsação de EOBC como temporizador de serviço ocupado da CPU	7.0(3)I4(8) e 7.0(3)I7(3)

Histórico de revisões

Revisão	Data de publicação	Comentários
2.0	05-Jun-2026	Ortografia, gramática, estrutura de frases e espaçamento atualizados.
1.0	07-Feb-2024	Versão inicial