O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento ddescreve como solucionar problemas de recarregamentos ou travamentos inesperados nos switches Nexus 9000.
Não há requisitos para este documento.
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.
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:
O próprio kernel encontra uma condição irrecuperável e trava.
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)
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>
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
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
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
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:
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.
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.
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)
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.
`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.
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)
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.
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.
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
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.
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.
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
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.
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.
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)
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.
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.
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
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.
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)
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) |
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
07-Feb-2024 |
Versão inicial |