Solucione problemas de recarregamento do gerenciador de pilha 3650/3850

Introdução

Este documento descreve como aproveitar os relatórios do sistema para diagnosticar problemas da pilha.

Pré-requisitos

Requisitos

Não existem requisitos específicos 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.

Informações de Apoio

Se você solucionar problemas de recarregamento de pilha por meio de um relatório do sistema na ausência de um travamento, isso geralmente é feito nas plataformas de switching NGWC que você usa a tecnologia stackwise. A documentação atual é limitada aos usos de um relatório do sistema e este guia explica como você pode aproveitar esses relatórios para diagnosticar problemas normalmente encontrados com problemas de empilhamento. Este guia é especialmente voltado para as arquiteturas de Switch Catalyst 3650/3850 que executam o Cisco IOS® XE com recursos de empilhamento de suporte.

A maioria dos problemas com a tecnologia stackwise provém de um problema de comunicação entre os membros dentro de uma pilha. Qualquer inconsistência de informações entre os membros ou perda de conectividade pode resultar em um problema que permeia toda a pilha e, por fim, leva a uma redefinição com o gerenciador de pilha. Este documento pode destacar alguns dos tipos comuns de falhas observados com recarregamentos do gerenciador de pilha, usos de um relatório do sistema e CLIs relevantes disponíveis para diagnosticar e diferentes tipos de problemas.

Relatórios do sistema versus relatórios do switch

Um relatório de sistema é um relatório abrangente do membro de como ele percebe o estado da pilha. Este não é um crashinfo (que pode despejar memória para depuração adicional), mas, em vez disso, é um relatório que tem logs e informações de depuração para vários serviços executados no Cisco IOS XE que seriam úteis para o desenvolvimento rastrear o estado desse serviço. Um relatório do sistema pode ser gerado quando o switch é recarregado pelo gerenciador de pilha, quando ocorre uma falha no processo ou quando é gerado manualmente pelo usuário durante a operação em tempo real.

Em muitos casos, há situações em que um único switch pode falhar em uma pilha, mas o restante dos membros podem permanecer intactos. Para reunir informações sobre o estado da pilha no momento determinado, switch_reports foi introduzido de forma que os membros atuais possam gerar um quando detectarem que um membro foi desativado. O switch_report pode ser um relatório local de como esse membro percebe o estado atual da pilha.

Observação: esses relatórios são gravados e compactados para que não possam ser impressos no terminal com mais. Eles podem precisar ser transferidos do switch e descompactados para visualizar o registro.

Onde coletar relatórios do sistema/switch

Os relatórios do sistema podem ser gravados no diretório crashinfo: do membro nessa pilha. Por exemplo, se houver uma pilha de switches de x-member, cada switch pode ter seu próprio diretório crashinfo que pode ser acessível com dir crashinfo-x onde x corresponde ao membro dentro da pilha.

3850#dir crashinfo-1:

Diretório de informação de travamento:/    

11 -rwx 355 Aug 14 2015 07:48:17 -04:00 last_systemreport_log  

12 -rwx 724015 15 de outubro de 2014 07:14:32 -04:00 system-report_1_20141015-111342-UTC.gz

3850#dir crashinfo-2:

Diretório de crashinfo-2:/   

11 -rwx 357 Aug 14 2015 07:50:49 -04:00 last_systemreport_log  

12 -rwx 751340 15 de outubro de 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz

Observação: certifique-se de coletar a saída de dir crashinfo-x para cada switch nessa pilha porque o show tech não pode listar os sistemas de arquivos disponíveis ou os arquivos crashinfo. É importante que você tenha a imagem completa de cada membro nessa pilha. Atualização: a partir das versões mais recentes do Cisco IOS XE >3.6E, o show tech pode refletir a saída de dir crashinfo: + show file systems. Consulte o bug da Cisco ID CSCun50428.

Seções que Vale a Pena Anotar no Relatório do Sistema

Do ponto de vista do TAC, essas são algumas das entradas exibidas com mais frequência no relatório do sistema que podem ajudar a diagnosticar eventos de um problema específico. Há outros registros de outros serviços contidos aqui que o desenvolvimento pode achar que quer revisar.

arquivo de log: /mnt/pss/sup_sysmgr_reset.log

Esta é uma saída curta para entender muito genericamente por que uma reinicialização foi vista. Consulte a seção sobre os próximos tipos de falhas para ver o significado e o contexto de como esses motivos podem variar.

arquivo de registro: Cisco IOS

Esse é o buffer de registro mantido a partir do Cisco IOSd. Os comandos que foram emitidos pelo usuário ou syslogs gerados no Cisco IOSd podem ser encontrados nesta seção. Os logs mais recentes estão próximos ao final dessa saída.

Buffer de Rastreamento: stack-mgr-events

Controla os eventos vistos do gerenciador de pilha que podem incluir quando outros membros estão ingressando/removidos da pilha ou por qual porta da pilha as mensagens entram.

               

Buffer de Rastreamento: redundancy-timer-ha_mgr

Exibe eventos de keep alive entre switches na pilha. Os carimbos de data e hora podem ajudar a determinar quando a falha na comunicação começou.

Tipos de falhas

Esta seção pode destacar algumas reinicializações comumente vistas de um relatório do sistema que são normalmente invocadas pelo processo do gerenciador de pilha. O gerenciador de pilha é um processo do Linux que gerencia os membros da pilha e pode supervisionar qualquer alteração nas funções entre os switches na pilha. Se o gerenciador de pilha detectar um problema durante a inicialização ou eleição de função, ele poderá enviar um sinal de recarregamento para switches individuais para que a pilha seja redefinida. A próxima lista também pode listar bugs conhecidos que foram associados ao respectivo tipo de falha.

Motivo da redefinição:Reinicialização/Recarga solicitada por [stack-manager]. [Incompatibilidade de ISSU]

Você pode ver esse tipo de redefinição quando há uma falha de sincronização em massa quando tenta sincronizar a configuração ativa entre todos os membros da pilha. Verifique o arquivo de registro: o Cisco IOS ou os registros do switch ativo podem destacar as configurações que contribuíram para essa redefinição.

Motivo da redefinição:Serviço [iosd] pid:[xyz] terminou de forma anormal [11].

Isso é visto quando o switch trava no processo Cisco IOSd. Procure nos diretórios de informação de travamento por quaisquer arquivos de informação de travamento + os dumps principais podem ser usados para depurar ainda mais essa falha.

hap_sup_reset: Motivo da redefinição:Redefinição/Recarga solicitada por [stack-manager]. [mesclagem de pilha]

Uma mesclagem de pilha é vista quando há dois ou mais switches que acreditam ser o switch ativo da pilha. Isso pode ser visto quando há uma ruptura no anel de uma pilha (ou seja, dois cabos são desconectados da pilha) de modo que tanto o ativo quanto o standby perdem a comunicação com os outros membros. A adição de um switch já ligado a uma pilha atual pode causar uma mesclagem de pilha, pois pode haver dois switches ativos na pilha.

ID de bug Cisco CSCuh58098 - a pilha 3850 pode ser recarregada quando problemas de cabeamento de pilha estão presentes

ID de bug Cisco CSCui56058 - Habilita lógica de devolução para cabo de pilha

ID de bug Cisco CSCup53338 - travamento de 3850 IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: Código do motivo:[4] Motivo da redefinição:Reset/Reloadsolicitado por [stack-manager]. [mesclagem de pilha devido à incompatibilidade]

Isso foi visto em situações em que um switch ativo e em espera existe na pilha. Se o switch ativo perder a comunicação com o standby, o standby pode tentar assumir o controle como o ativo, mesmo que o ativo ainda esteja ativo.

ID de bug da Cisco CSCuo49555

ID de bug Cisco CSCup58016 - 3850/3650 trava devido a inundação de unicast na porta de gerenciamento

ID de bug da Cisco CSCur07909 - Mesclagem de pilhas devido à perda de conectividade ativa e em espera

Motivo da redefinição:Reinicialização/Recarga solicitada por [stack-manager]. [Encontrado vizinho incorreto após votação ASIC]

Os switches participam de uma votação ASIC durante a inicialização para determinar seus switches vizinhos na pilha. Essa reinicialização pode ser vista quando um temporizador expira para que um vizinho se declare ou se houver um erro lógico durante a conversação nbrcast. Isso foi visto no contexto de cabos de pilha defeituosos que foram resolvidos através da substituição.

ID de bug Cisco CSCun60777 - Switch recarregado devido ao vizinho errado encontrado após o voto ASIC

ID de bug Cisco CSCud93761 - Switch recarregado devido ao vizinho errado encontrado após o voto ASIC

ID de bug Cisco CSCun17506 - Amur:ng3k:o mesmo vizinho é visto em ambas as portas da pilha em uma pilha de 3 membros

hap_sup_reset: Código do motivo:[4] Motivo da redefinição:Reinicialização/Recarga solicitada por [stack-manager]. [perdeu ativo e em espera]

Isso é geralmente visto de um membro na pilha que não está em uma função ativa ou em espera. Quando o ativo falha, se não houver um switch em espera para assumir a função ativa para a pilha, a pilha inteira pode ser redefinida. Se a pilha é um estado instável ou a política de redundância ainda não foi sincronizada, isso pode ser visto. Isso é provavelmente uma vítima do motivo pelo qual os switches ativos/em espera foram desativados ou uma indicação de que a redundância não sincroniza corretamente. Isso também pode ser visto em quando as pilhas são configuradas em uma configuração de meio anel.

ID de bug Cisco CSCup53882- Switches membros em uma reinicialização de pilha 3850 - [perdeu ativos e em espera]

hap_sup_reset: Código do motivo:[1] Motivo da redefinição:Reinicialização/Recarga solicitada por [stack-manager]. [Keepalive_Timeout]

Visto quando mensagens de keep alive não são recebidas do switch na pilha. Examine o Buffer de Rastreamento: redundancy-timer-ha_mgr e ele mostra a troca de mensagens de keep alive e fornece uma perspectiva de tempo para quando a falha na comunicação começou. Se você coletar relatórios de switch do restante da pilha e examinar registros durante todo o período de tempo, isso pode ajudar.

hap_sup_reset: Motivo da redefinição:Redefinição/Recarga solicitada por [stack-manager]. [Comando Recarregar]

Este é um motivo de reinicialização bastante intuitivo - isso é visto quando o gerenciador de pilha recebe uma solicitação de recarregamento que pode ser chamada através de CLI ou externamente através do dispositivo de gerenciamento (SNMP). Em casos de bug da Cisco ID CSCuj17317, isso também aparece como um comando reload emitido também. No arquivo de registro: Cisco IOS, você pode ver:

CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr:  Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr:  Reloading due to reason Reload command

Bugs relacionados

ID de bug Cisco CSCur76872 - O gerenciador de pilha cai quando o sistema fica sem buffer SDP.

ID de bug Cisco CSCup49704 - Falha de FED do 3850 - Aguarda canais SPI FED_SPI_FLCD,FED_SPI_FAST ...

Diagnostique um possível problema de porta ou cabo de pilha

Sintoma 1) Quaisquer sinais de um problema no cabo da pilha são aparentes por qualquer oscilação da porta da pilha antes da redefinição. Examine o arquivo de registro: o relatório do Cisco IOS antes de uma reinicialização normalmente é um bom ponto de partida. Aqui está um exemplo de onde você vê a oscilação da porta da pilha registrada no SW2 atual e no SW1 em standby. Essa mesma porta de pilha não estava sincronizada em cada instância da redefinição e foi resolvida quando o cabo da pilha foi substituído:

=====================  log file: Cisco IOS  =====================
.
.
Aug  8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is down  (SW1-1)
Aug  8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr:  Stack port 1 on switch 1 is up  (SW1-1)
Aug  8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is down
Aug  8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr:  Stack port 2 on switch 2 is up
Aug  8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr:  Switch 1 has been removed from the stack.
Aug  8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1

Sintoma 2) Com base na configuração de stackwise usada (180, 480 e mais), o número de anéis de transmissão por ASIC de porta varia. Esses comandos sondam registros globais que mantêm um total que aumenta a quantidade de erros de leitura vistos para cada anel de transmissão. Port-asic 0 corresponde à porta de pilha 1 e port-asic 1 corresponde à porta de pilha 2. Isso deve ser emitido para cada switch e qualquer sinal de contagem que incrementar pode isolar se pode haver um problema na porta ou com o cabo da pilha.

Estes podem ser coletados várias vezes ao longo de alguns minutos para comparar os deltas na contagem:

show platform port-asic <0-1> read register SifRacDataCrcErrorCnt switch <switch#>

• Segmento com erro de CRC de dados.

show platform port-asic <0-1> read register SifRacRwCrcErrorCnt switch <switch#>

• Incrementado em qualquer verificação de CRC com falha.

show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt switch <switch#>

• Incrementado em código de PCS inválido, palavra de código de PCS desconhecida, que executa um erro de disparidade detectada.

show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>

• Um erro de bit na pilha causou um erro de CRC de palavra de toque.

Para Polaris (código 16.X), estes são os comandos:

show plat hardware fed sw <#/ative/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1> 

show plat hardware fed sw <#/ative/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>

show plat hardware fed sw <#/ative/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>

show plat hardware fed sw <#/ative/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>

Este exemplo mostra onde você teve um evento de mesclagem de pilha visto em ambos os membros de uma pilha de 2 membros sem nenhum sinal de porta de pilha oscilante. Você vê o incremento de anel[0] com CRCs na porta 1 da pilha do switch 1 e, para superar esse problema, substitua o cabo da pilha.

3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x00000031 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001
                               
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015

For asic 0

SifRacRwCrcErrorCnt on  Asic 0
[0]
               count 0x000000c9 <<
[1]
               count 0x00000001
[2]
               count 0x00000000
[3]
               count 0x00000001
[4]
               count 0x00000000
[5]
               count 0x00000001

Dicas adicionais

1. Arquivar Diretórios Crashinfo

Mais switches na pilha significa que pode haver mais arquivos de relatório a serem coletados. É fácil ficar sobrecarregado com o número de relatórios gerados. A organização é vital para separar uma falha. Encontre uma consistência com carimbos de data e hora de quando cada switch escreveu o arquivo de relatório para um determinado incidente, se possível. A partir daí, solicite esses relatórios muito específicos dos switches fornecidos para que o cliente não carregue vários arquivos. O diretório crashinfo também pode ser arquivado para que o usuário da Cisco possa enviar um único arquivo contendo os relatórios interessados. O próximo exemplo pode criar um arquivo chamado crashinfo-archive.tar no diretório flash:

F340.03.10-3800-1#archive tar /create ?
 WORD Tar filename

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
 WORD Dir to archive files from

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
 WORD File or Dir
 <cr>

F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:

2. Recuperar uma Pilha Instável

Pode haver algumas situações em que você vê vários membros em um recarregamento de pilha durante a inicialização após o processo de eleição da pilha ocorrer. Se um switch recarregado acredita ser o ativo, isso pode levar a um evento de mesclagem de pilhas e pode entrar em um estado de loop de inicialização. Nessa situação, pode ser aconselhável perguntar ao cliente da Cisco:

• Desligue toda a pilha e reinicie todos os cabos da pilha com firmeza.
• Ligue cada switch membro na pilha, um por um, até que todos os membros tenham convergido para o estado esperado.
• Nos casos em que um membro não consegue ingressar na pilha, remova-o da pilha e tente inicializar esse indivíduo como autônomo para fazer troubleshooting adicional.

3. Gerar Relatórios do Sistema Manualmente

Um relatório de sistema criado manualmente requer que o serviço interno esteja habilitado. Isso grava um relatório do sistema como um arquivo de texto que pode ser feito por switch.

3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit

3800-1#resource create_system_report ?
 WORD system report filename

3800-1#resource create_system_report sysreport.txt ?
 switch Switch number
 <cr>

3800-1#resource create_system_report sysreport.txt switch ?
 <1-1> Switch number

3800-1#resource create_system_report sysreport.txt switch 1 ?
 <cr>

Informações Relacionadas

• Suporte técnico e downloads da Cisco