Solucione problemas de recarregamento inesperado ou travamento no Nexus 9000

Introdução

Este documento ddescreve como solucionar problemas de recarregamentos ou travamentos inesperados nos switches Nexus 9000.

Pré-requisitos

Não há 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 nos níveis de rede, sistema e processo.

Há três motivos para uma recarga inesperada ocorrer no 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 estava acontecendo antes do recarregamento? Alguma alteração de configuração? Alguma mudança de escala? Algum registro no dispositivo? Alguma mudança ambiental? Algum aumento no uso da CPU/memória?
• Quando o switch for inicializado e estiver estável, colete e verifique a saída. 
• Se o switch não puder ser ligado, 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. 

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)

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.

Recomendado:

1. Verifique os cabos de alimentação das 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 Alta Disponibilidade (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 ocorrerá se a política do processo for redefinida (o NX-OS não pode funcionar durante a reinicialização do processo) ou se os tempos de reinicialização do processo atingirem o máximo de tentativas.  

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>

A maior parte do travamento do processo é um defeito de software e o arquivo principal é salvo. Abra um caso de solicitação de serviço para confirmar. 

• Os arquivos principais podem ser decodificados pelo engenheiro do TAC. 
• Para abrir a solicitação de serviço, escolha Product > Unexpected Reboot > Software Failure para abrir o caso com a equipe certa.

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

O EOBC é a abreviação de Ethernet Out of Band Channel (Canal fora de banda Ethernet). As manutenções de atividade regulares ocorrem entre o supervisor e as placas de linha. As mensagens de erro recebidas 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 razões para a falha do EOBC:
1. Congestionamento de EOBC. Você pode ver mais de 1 EOBC de experiência de placa de linha perdido.
2. Porco de CPU em módulo(s) específico(s). A CPU da placa de linha/supervisor está ocupada e não consegue lidar com mensagens EOBC. Há um aprimoramento de software a partir do Nexus 9000 da versão 7.0(3)I7(3). 
3. Falha de hardware. 

Recomendado

1. Verifique se há algum CPUhog para a placa de linha afetada ao redor da recarga.

2. Verifique se outra placa de linha apresenta perda de EOBC ao recarregar. 

3. Verifique se a CPU BFD ou Netflow instalada recentemente consome serviços. 

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 ao magnético. Estes acontecimentos 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.

Recomendado

Os erros de paridade podem ser perturbações transitórias de evento único (SEU) ou podem ser causados por hardware defeituoso. Para determinar o que é isso, você precisa 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, nenhuma ação será necessária. 

Os erros de paridade frequentes ou repetíveis (hard) são causados por um mau funcionamento físico da memória ou dos circuitos usados 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 podem fazer 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, mas 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. 

Recomendado

O mesmo com erro 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 mau funcionamento físico. 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

Os temporizadores de vigilante são comumente encontrados em sistemas incorporados e outros equipamentos controlados por computador onde os seres humanos não podem facilmente acessar o equipamento ou seriam incapazes de reagir a falhas de uma maneira oportuna.
O 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.

Recomendado

1. Verifique se algum bug de software conhecido afeta a versão atual.

2. Se o problema ocorrer novamente, colete o rastreamento do 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 a atualização.

Recomendado

Comportamento esperado. 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 dos 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 a tempo limite de 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 recarregamento do kernel devido ao Timeout 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)