Solucionar problemas comuns de hardware e arquitetura nos switches Nexus 7000 Series

Introduction

Este documento fornece uma breve explicação e soluções para problemas comuns de hardware e arquitetura para os switches Cisco Nexus 7000 Series que executam o software de sistema Cisco NX-OS.

Note: O formato exato do syslog e das mensagens de erro que este documento descreve podem variar ligeiramente. A variação depende da release do software executada no Supervisor Engine.

Problema: Falha de SpineControlBus

O teste de controle spine falha para o supervisor do Nexus 7000:

Nexus7000# show module internal exceptionlog module 5
...
System Errorcode  : 0x418b0022 Spine control test failed
Error Type        : Warning
PhyPortLayer      : 0x0
Port(s) Affected  : none
Error Description : Module 10 Spine Control Bus test Failed
...
         11) SpineControlBus E
                Error code ------------------> DIAG TEST ERR DISABLE
                Total run count -------------> 1597800
                Last test execution time ----> Mon May 27 21:57:17 2013
                First test failure time -----> Sun Nov 20 00:30:55 2011
                Last test failure time ------> Mon May 27 21:57:17 2013
                Last test pass time ---------> Mon May 27 21:56:47 2013
                Total failure count ---------> 33
                Consecutive failure count ---> 1
                Last failure reason ---------> Spine control test failed

Solução

Esse problema está relacionado à ID de bug da Cisco CSCuc72466. Consulte as FAQ do Nexus 7000: Qual é a ação recomendada quando o teste SpineControlBus falha?.

Problema: Blocos defeituosos encontrados na NVRAM

Erros de NVRAM aparecem em eventos de diagnóstico:

Nexus7000#show diagnostic events
1) Event:E_DEBUG, length:97, at 9664 usecs after Wed Dec  5 01:03:42 2012
    [103] Event_ERROR: TestName->NVRAM TestingType->health monitoring module->5 
Result->fail Reason->
#show diagnostic result module 5 test NVRAM detail
 4) NVRAM-------------------------> E
                Error code ------------------> DIAG TEST ERR DISABLE
                Total run count -------------> 52596
                Last test execution time ----> Wed Dec  5 01:03:41 2012
                First test failure time -----> Tue Dec  4 23:28:45 2012
                Last test failure time ------> Wed Dec  5 01:03:42 2012
                Last test pass time ---------> Tue Dec  4 23:23:41 2012
                Total failure count ---------> 20
                Consecutive failure count ---> 20
                Last failure reason ---------> Bad blocks found on nvram

Esse é um problema de hardware, uma falha do Supervisor Engine ou um problema transitório.

Solução

1. Execute novamente o teste da NVRAM para ver se este é um alarme falso. Insira estes comandos para desabilitar e reabilitar o teste de diagnóstico (por exemplo, se fornecido para o módulo de problema 5):
   • no diagnostic monitor module 5 test NVRAM
   • módulo de monitor de diagnóstico 5 teste NVRAM

   Insira o comando show diagnostic result module 5 test NVRAM detail para ver os resultados do comando test.

2. Se o teste de NVRAM falhar novamente, recoloque o módulo 5. Observe o resultado dos comandos show diagnostic result module 5 e show module.
3. Se o módulo falhar novamente, gere uma solicitação de RMA (Return Material Authorization, Autorização de devolução de material) para o Supervisor no slot do problema.

Problema: Falha de Compact Flash do Módulo 9

Uma ou todas elas são vistas no Supervisor 2/Supervisor 2E:

• Mensagem de Erro:

  DEVICE_TEST-2-COMPACT_FLASH_FAIL: Module 5 has failed test CompactFlash 
  20 times on device Compact Flash due to error The compact flash power test failed.

• Não é possível salvar a configuração.
• Falhas no teste de diagnóstico:

         Test results: (. = Pass, F = Fail, I = Incomplete,
         U = Untested, A = Abort, E = Error disabled) 
         7) CompactFlash E 
                 Error code ------------------> DIAG TEST ERR DISABLE
                 Total run count -------------> 23302
                 Last test execution time ----> Sun Apr 13 10:07:30 2014
                 First test failure time -----> Sun Apr 13 00:37:41 2014
                 Last test failure time ------> Sun Apr 13 10:07:40 2014
                 Last test pass time ---------> Sun Apr 13 00:07:41 2014
                 Total failure count ---------> 20
                 Consecutive failure count ---> 20
                 Last failure reason ---------> The compact flash power test
                                                 failed
                 Next Execution time ---------> Sun Apr 13 10:37:30 2014

Causa raiz

Os supervisores Nexus 7000 de segunda geração são fornecidos com dois flashes eUSB idênticos para redundância. Os flashes fornecem um repositório para flash de inicialização, configurações e outras informações pertinentes. Esses dois flashes são reconfigurados como uma matriz RAID 1 que implementa o espelhamento interno. Com a redundância, um Supervisor pode funcionar com a perda de um dos flashes, mas não ambos.

Há algumas instâncias no campo em que um ou ambos os flashes são marcados como ruins pelo software RAID durante um período de vários meses ou anos em serviço. Uma reinicialização da placa redescobre que esses flashes com falha estão saudáveis na próxima inicialização.

Solução

Conclua estes passos para verificar se este é ou não um problema de hardware:

1. Recarregue o supervisor do problema, se possível.
2. Se o problema for observado após o recarregamento, você precisará de uma substituição de hardware.
3. Se o problema for corrigido pelo recarregamento, a causa raiz está relacionada ao bug da Cisco ID CSCus22805.

Problema: Falha no teste de porta de loopback da placa de linha N7K-M132XP-12

A placa de linha relata uma falha de diagnóstico devido à falha de teste de PortLoopback 10 vezes consecutivas:

DIAG_PORT_LB-2-PORTLOOPBACK_TEST_FAIL  Module:16 Test:PortLoopback
 failed 10 consecutive times. Faulty module:Module 16 affected ports:5,7  
Error:Loopback test failed. Packets lost on the LC at the Queueing engine ASIC

MODULE-4-MOD_WARNING  Module 16 (serial: XXXX) reported warning on 
ports 16/5-16/5 (Ethernet) due to Loopback test failed.  
Packets lost on the LC at the Queueing engine ASIC in device 78 
(device error 0x41830059)

Causa raiz

Esta é uma mensagem de aviso e, na maioria dos casos, indica um problema de hardware na porta.

Solução

Verifique primeiro a ID de bug da Cisco CSCtn81109 e a ID de bug CSCti95293, pois isso pode ser um problema de software.

Recoloque o módulo primeiro para reinicializar a placa e executar novamente os testes de integridade do hardware de inicialização. Se os testes de diagnóstico ainda mostrarem falha na mesma placa, substitua a placa.

Recarregue a placa em um momento conveniente e colete as saídas destes comandos:

• show logging log
• show module
• show diagn result module all detail

Como alternativa, você pode executar novamente apenas este teste específico e não precisa recarregar a placa. Este exemplo mostra o módulo 16:

show diagnostic result module 16
diagnostic clear result module all
(config)# no diagnostic monitor module 16 test 5
(config)# diagnostic monitor module 16 test 5
diagnostic start module 16 test 5
show diagnostic result module 16 test 5

Problema: MÓDULO de placa de linha N7K-M132XP-12-4-MOD_WARNING

Esses erros são exibidos e há uma possível recarga do módulo:

2013 Mar 27 00:40:23 DC3-7000-PRODD2-A23  MODULE-4-MOD_WARNING  
Module 9 (serial: XXX) reported warning on ports 9/1-9/3 (Unknown) 
due to BE2 Arbiter experienced an error in device 65 (device error 0xc410f613)

Causa raiz

Esta é uma falha de hardware causada por erros de paridade ou problemas de hardware na placa auxiliar.

Solução

1. Verifique a saída destes comandos:
   • show version
   • show system reset-reason module X
   • show logging onboard reset-reason
   • show module internal event-history module X
   • show log
2. Se sua versão do Cisco NS-OX for anterior à versão 4.2, atualize para uma nova versão para garantir que as correções desses defeitos de software sejam integradas (minimize a possibilidade de erros de paridade):
   • ID de bug da Cisco CSCso72230 L1 D-cache travamentos de CPU 8541 habilitados para 8541 com erros de paridade de cache D L1
   • ID de bug da Cisco CSCsr90831 - L1 D-cache ativado para 8541 falhas de CPU com erros de paridade L1 D-cache Push
3. Se os erros ocorrerem repetidamente, recoloque a placa e o monitor.
4. Se os erros ainda estiverem repetindo, substitua o módulo com problema.

Defeito de software conhecido adicional

ID de bug da Cisco CSCtb98876

Problema: O chico N7K-M224XP-23L envia erro de perda de sincronização

Esses erros aparecem no módulo:

%MODULE-4-MOD_WARNING: Module # (Serial number: XXXX) reported warning 
Ethernet#/# due to chico serdes sync loss in device DEV_SKYTRAIN 
(device error 0xc9003600)

Causa raiz

Esses erros indicam que há um problema de perda de sincronização entre o módulo nº e o Xbar/ASIC. Na maioria dos casos, a causa é uma falha de hardware do módulo.

Se sua versão do Cisco NS-OX for anterior à 6.1(4) e a mensagem não for exibida continuamente, ela poderá ser afetada pela ID de bug da Cisco CSCud91672. A causa do defeito é que as configurações da série NX-OS são diferentes das configurações de diagnóstico nos dois canais entre a SKT <—>SAC.

Solução

Colete a saída destes comandos:

• show version
• show module
• show run
• show module internal event-history module X
• show module internal activity module X
• show module internal exception-log module X
• show module internal event-history errors
• show logging last 200
• show logging nvram

Atualize o switch para NS-OX versão 6.1(4) ou posterior para isolar a causa do defeito.

Execute este teste para confirmar se a placa está com defeito em vez do slot xbar ou do chassi:

1. Mova o módulo com problema para outro slot livre no chassi.
2. Se você tiver um módulo sobressalente, insira-o em um slot problemático.
3. Se os erros não forem vistos após a etapa 1, insira o módulo novamente no slot problemático e verifique.

Problema: Falhas de teste de N7K-F248XP-25 PrimaryBootROM e SecondaryBootROM

O Módulo N7K-F248XP-25 falha nos testes PrimaryBootROM e SecondaryBootROM:

show module internal exceptionlog module 1 | i Error|xception
********* Exception info for module 1 ********
exception information --- exception instance 1 ----
Error Description : Secondary BootROM test failed
 
exception information --- exception instance 2 ----
Error Description : Primary BootROM test failed

Causa raiz

Isso geralmente ocorre devido a corrupção de arquivo do BIOS ou falha de hardware da placa de linha.

Solução

O bug da Cisco ID CSCuf82089 adiciona código para mostrar informações mais descritivas sobre essas falhas para um melhor diagnóstico. Por exemplo, ele mostra um componente com falha em vez de um valor atualmente nulo.

Em alguns casos, o problema é causado pela corrupção do BIOS no módulo. Insira o comando install module X bios forced para resolver isso. Observe que esse comando pode potencialmente afetar o serviço. A recomendação é executá-lo somente durante uma janela de manutenção.

Siga estas etapas para resolver o problema:

1. Agende uma janela de manutenção e insira o comando install module X bios forced como uma possível solução alternativa. Insira este comando somente durante uma janela de manutenção para evitar um possível impacto no serviço.
2. Se a etapa 1 não ajudar ou não for possível ter uma janela de manutenção para esta ação, substitua o módulo. Este exemplo de saída mostra uma tentativa falhada:

Nexus7000# install module 1 bios forced
Warning: Installing Bios forcefully...!
Warning: Please do not remove or power off the module at this time
Upgrading primary bios
Started bios programming .... please wait
[#                            0%                             ]
BIOS install failed for module 1, Error=0x40710027(BIOS flash-type verify failed)
BIOS is OK ...
Please try the command again... 

Problema: Falha do sensor de temperatura

Este erro é visto na plataforma:

%PLATFORM-4-MOD_TEMPFAIL: Module-2 temperature sensor 7 failed

Causa raiz

Esse é um problema intermitente com o bloco de temperatura/voltagem no ASIC sob certas condições devido à temporização interna do ASIC. A ID de bug da Cisco CSCtw79052 descreve a causa conhecida para esse problema.

Esse é um problema de temporização entre o ASIC que trava a temperatura internamente e o software que coleta o bit válido. O problema é que ele pode atingir qualquer uma das 12 instâncias do Clipper. Não há um gatilho específico para esse problema e ele é intermitente. Esse problema não afeta o serviço e ocorre porque a lógica de leitura de temperatura tem um problema que exige mais tentativas no driver.

Solução

Colete a saída desses comandos e verifique o bug da Cisco ID CSCtw79052:

• show version
• show env temperature
• show sprom module <module #> 
• Nexus# attach module <module #>
• <module#>#show hardware internal sensor event-history errors

Problema: Erro Xbar/C7010-FAB-1 no estado de desligamento

O C7010-FAB-1 está em um estado de desligamento e esses erros aparecem:

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed, 
Left Ejector is OPEN, Right Ejector is CLOSE

%PLATFORM-3-EJECTOR_STAT_CHANGED: Ejectors' status in slot 13 has changed,
 Left Ejector is OPEN, Right Ejector is OPEN

%PLATFORM-2-XBAR_REMOVE: Xbar 3 removed (Serial number XXX)
 
Xbar Ports  Module-Type                         Model              Status
---  -----  ----------------------------------- ------------------ ----------
3    0      Fabric Module                       N/A                powered-dn
?
Xbar Power-Status  Reason
---  ------------  ---------------------------
3    powered-dn     failure(powered-down) since maximum number of bringups were exceeded

Como alternativa, os erros de ASIC do xbar são exibidos:

%MODULE-4-MOD_WARNING: Module 15 (serial: XXX) reported warning due to 
X-bar Interface ASIC Error in device 70 (device error 0xc4600248)

%OC_USD-SLOT15-2-RF_CRC: OC2 received packets with CRC error from MOD 15 
through XBAR slot 3/inst 2

Causa raiz

Esse problema deve-se a um módulo xbar com falha ou mal encaixado ou a um slot de chassi com defeito.

Solução

1. Verifique a saída destes comandos:
   • show version
   • show module
   • show logging
   • show logging nvram
   • show module internal exception-log
   • show module internal event-history
   • show core
   • show system reset-reason
   • show environment | em xbar
   • show system internal platform internal event-history xbar X é xbar #
   • show system internal xbar-client internal event-history errors
   • show system internal xbar all
   • show system internal xbar event-history errors
2. Execute uma reinstalação forçada do módulo xbar e verifique o status.
3. Se a recolocação falhar, teste xbar em outro slot ou teste o mesmo slot com outro módulo xbar para verificar se o chassi está bom.
4. Substitua o hardware com falha com base nos testes realizados nas etapas 2 e 3.

Problema: Módulo de ventilador N7K-C7010-FAN-F com falha

Um ou mais destes sintomas de falha do ventilador são observados:

%PLATFORM-5-FAN_STATUS: Fan module 3 (Serial number XXX) 
Fan3(fab_fan1) current-status is  FAN_FAIL
 
Nexus 7000#show environment fan
Fan3(fab_fan1)  N7K-C7010-FAN-F    1.1     Failure (Failed Fanlets: 2 6 7 8 9 10 14 15 )
Fan4(fab_fan2)  N7K-C7010-FAN-F    1.1     Ok 
...
 
#show hardware
----------------------------------
Chassis has 4 Fan slots
----------------------------------
Fan3(fab_fan1) failed
  Model number is N7K-C7010-FAN-F
...

Causa raiz

Na maioria dos casos, essa é uma falha do ventilador ou do slot do chassi.

Solução

1. Verifique a saída destes comandos:
   • show version
   • show module
   • show inventário
   • show log
   • show log nvram
   • show environment fan
2. Teste esse N7K-C7010-FAN-F em outro chassi em boas condições.
3. Substitua o ventilador ou o chassi com base nos resultados das etapas 1 e 2.

Problema: Alarme da fonte de alimentação %PLATFORM-2-PS_CAPACITY_CHANGE

Os alarmes são vistos para as mudanças de capacidade, às vezes com muita frequência.

%PLATFORM-2-PS_CAPACITY_CHANGE: Power supply PS2 changed its capacity. 
possibly due to On/Off or power cable removal/

2013 Oct 17 17:06:40 ... last message repeated 14 times

 

Causa raiz

Esse problema deve-se a um cabo de alimentação defeituoso ou desconectado ou a uma falha na fonte de alimentação.

Solução

Verifique a saída do comando show env power detail e pesquise o status da fonte de alimentação. Neste exemplo de saída, ambos os cordos estão conectados, mas o segundo mostra apenas a capacidade de 1200W em vez de 3000W e precisa ser para 220V AC no N7K-AC-6.0KW. A fonte de alimentação foi testada OK. Substitua a fonte de alimentação.

PS_2 total capacity:    4200 W   Voltage:50Vchord 1    capacity:    3000 W chord 1    
connected to 110v AC chord 2    capacity:    1200 W chord 2    connected to 220v AC

Problema: %PLATFORM-5-PS_STATUS: Alarme PowerSupply X PS_FAIL

Este alerta aparece na plataforma:

%PLATFORM-5-PS_STATUS: PowerSupply 3 current-status is PS_FAIL

%PLATFORM-2-PS_FAIL: Power supply 3 failed or shut down (Serial number xxxxx)

Causa raiz

Este alerta deve-se a um cabo de alimentação defeituoso ou desconectado ou a uma falha na fonte de alimentação.

Solução

1. Verifique a saída destes comandos:
   • show environment power detail
   • show power
2. Recoloque a fonte de alimentação que apresentou falha. Use a fonte de alimentação redundante para garantir que a alimentação não fique off-line.
3. Envie uma RMA para a fonte de alimentação. Use a fonte de alimentação redundante para garantir que a alimentação não fique off-line.

Referências

Redundância de fonte de alimentação do Cisco Nexus 7000 Series

Problema: Problema na fonte de alimentação no FEX

Esses alarmes são exibidos para a fonte de alimentação FEX:

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Module 1: Runtime diag detected major event:
Voltage failure on power supply: 1
%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 System minor alarm on power 
supply 1: failed

%SATCTRL-FEX104-2-SOHMS_DIAG_ERROR: FEX-104 Recovered: System minor alarm 
on power supply 1: failed 

Solução

Verifique se há problemas de hardware e energia. Se você tiver um problema de software, as mensagens de erro continuarão mesmo após a troca de hardware.

Os métodos para resolver esses problemas incluem:

1. Recoloque a fonte de alimentação FEX. Use a fonte de alimentação redundante para garantir que a alimentação não fique off-line.
2. Envie a RMA para a fonte de alimentação FEX. Use a fonte de alimentação redundante para garantir que a alimentação não fique off-line.
3. Repita essas etapas para a segunda fonte de alimentação.

Revise e responda a essas perguntas para ajudar a definir as circunstâncias da falha:

1. Quantas fontes de alimentação FEX são afetadas?
2. Para um pequeno alarme, você trocou a fonte de entrada, e isso fez alguma diferença?
3. Você tem outras fontes de alimentação FEX com problemas?
4. Você tem outras caixas da mesma fonte de alimentação?
5. Você substituiu o cabo de alimentação?
6. Houve um surto ou falha de energia no ambiente?

Colete a saída desses comandos para investigar as falhas:

• show sprom fex 100 all
• show logging log | não mais
• show tech fex 100 | não mais
• attach fex 100
• show platform software satctrl trace

Defeito de software conhecido

ID de bug da Cisco CSCtr77620

Problema: As fontes de alimentação N7K-AC-6.0KW são reportadas como com falha

As fontes de alimentação Emerson N7K-AC-6.0KW são reportadas como Fail / shut, mas o switch funciona bem e a saída real não-0 é vista para a fonte de alimentação com problema.

Causa raiz

Em uma fonte com ambas as entradas ativas, quando uma entrada é desconectada, reconectada e desconectada novamente em 1,5 segundo, a fonte de alimentação pode travar uma falha de subtensão e o NX-OS pode sinalizar a falha da fonte de alimentação. Em outra variação, em uma fonte com duas entradas, remova uma entrada e aguarde 20 a 30 segundos. A fonte de alimentação pode definir intermitentemente o alarme de falha interna e o NX-OS informa que a fonte de alimentação falhou.

O bug da Cisco ID CSCty78612 altera o firmware nas unidades de fonte de alimentação para corrigir o problema.

O bug da Cisco ID CSCuc86262 adiciona um aprimoramento de software para se recuperar dessas falhas falsas. O NX-OS agora monitora de forma autônoma o status da PSU (Power Supply Unit, unidade de fonte de alimentação) e o modifica para o status apropriado se o estado informado for diferente do estado real.

Solução

Insira o comando show env power detail e verifique a saída real para verificar a falha falsa:

Nexus7000# show env power
Power Supply:
Voltage: 50 Volts
Power Actual Total
Supply Model Output Capacity Status
 (Watts ) (Watts )
------- ------------------- ----------- ----------- --------------
1 N7K-AC-6.0KW 0 W 0 W Shutdown
2 N7K-AC-6.0KW 3888 W 6000 W Fail/Shut

O status de Fail/Close (Falha/Desligar) incorreto é limpo quando você desliga/liga a PSU.

O bug da Cisco ID CSCty78612 altera o firmware na PSU. O software foi aprimorado por meio do bug da Cisco ID CSCuc86262, que se recupera de notificações falsas de falha/fechamento com a correção dos bits falsos se a fonte de alimentação em tempo de execução opera normalmente. As versões 5.2(9), 6.1(3) e 6.2(2) do NX-OS e posteriores têm a melhoria presente que evita uma RMA.

Problema: Quedas de pacote de software

Parte dos pacotes de tamanho grande é descartada quando há uma alta taxa de pacotes IP com um comprimento maior que o MTU configurado na interface de saída do pacote.

Causa raiz

Este é um comportamento esperado. Quando o sistema recebe um pacote IP com um comprimento maior que o MTU configurado na interface de saída do pacote, o sistema envia esse pacote ao plano de controle, que cuida da fragmentação. No NX-OS 4.1.3 e posterior, um limitador de taxa é aplicado a esses pacotes perfurados. Isso o limita a um máximo de 500 pps por padrão.

Solução

Este é um defeito de software conhecido na ID de bug da Cisco CSCsu01048.

Problema: Erro do sistema de falha de autoteste de FIPS do USER-2-SYSTEM_MSG

O erro "USER-2-SYSTEM_MSG FIPS self test failure in DCOS_rand - netstack" é exibido.

Causa raiz

Sempre que um número aleatório é gerado, o autoteste de Criador de Números Aleatórios Condicional (CRNG) é executado. Se o teste falhar, uma mensagem de syslog será registrada. Isso é feito de acordo com a recomendação FIPS (Federal Information Processing Standards). No entanto, o impacto disso é inofensivo, já que o número aleatório é gerado novamente.

Há dois tipos de geradores de números aleatórios (RNGs) no NX-OS:

• FIPS RNG implementado na biblioteca de criptografia openssl
• RNG não FIPS que é o RNG linux

Conforme o FIPS, todos os RNGs devem implementar o Teste de Gerador de Números Aleatórios Condicionais (CRNGT). O teste compara o número aleatório gerado atualmente com o anterior. Se os números forem os mesmos, uma mensagem syslog será gerada e mais um número aleatório será gerado.

O ensaio é executado de modo a assegurar que o número aleatório é único. Não há impacto funcional porque o número é regenerado.

Solução

Esta mensagem é inofensiva para a operação do sistema. No Cisco NX-OS Versão 5.2x ou posterior, a gravidade da mensagem é reduzida de 2, portanto, ela não é mais vista com a configuração de registro padrão. Esse registro ocorre como parte dos autotestes internos do NX-OS para várias funções no switch.

Este é um defeito de software conhecido na ID de bug da Cisco CSCtn70083.