Solução de problemas de recargas 3650/3850 por gerenciador de pilha através de um relatório do sistema

Introduction

A pilha de solução de problemas é recarregada por meio de um relatório do sistema, na ausência de um travamento, normalmente é feita em plataformas de switching NGWC usando tecnologia empilhadeira. A documentação atual é limitada ao uso de um relatório do sistema e este guia está sendo escrito para explicar como você pode aproveitar esses relatórios para diagnosticar problemas normalmente encontrados com problemas de empilhamento. Este guia é especialmente voltado para as arquiteturas de switching Catalyst 3650/3850 executando o IOS-XE que suporta recursos de empilhamento.

A maioria dos problemas com tecnologia empilhadeira tem origem em 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, levando, em última análise, a uma redefinição com o gerenciador de pilha. Este documento destacará alguns dos tipos comuns de falhas observadas com recargas de gerenciador de pilha, usos de um relatório de sistema e CLIs relevantes disponíveis para diagnóstico e diferentes tipos de problemas.

Informações de Apoio:

Relatórios de sistema versus de switch

Um relatório do sistema é um relatório abrangente do membro de como ele percebe o estado da pilha. Isso não é uma informação de travamento (que descartará memória para mais depuração), mas, em vez disso, é um relatório que tem logs e informações de depuração para vários serviços executados no IOS-XE que seriam úteis para o desenvolvimento para rastrear o estado desse serviço. Um relatório do sistema pode ser gerado quando o switch é recarregado pelo gerenciador de pilha, ocorre um travamento do processo ou é 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 pode permanecer intacto. Para coletar como informações sobre o estado da pilha no momento especificado, switch_reports foram introduzidos de modo que os membros restantes gerem um quando detectam que um membro está inoperante. O switch_report será um relatório local de como esse membro percebe o estado atual da pilha.

Note: Esses relatórios são gravados e compactados para que não possam ser impressos no terminal usando "more". Eles precisarão ser transferidos do switch e descompactados para visualizar o registro.

Onde coletar relatórios de sistema/switch

Geralmente, os relatórios do sistema serão gravados nas informações de travamento: diretório do membro nessa pilha. Por exemplo, se houver uma pilha de switches x-member, cada switch terá seu próprio diretório crashinfo, que pode ser acessado usando "dir crashinfo-x", onde 'x' corresponde a esse membro na pilha.

3850#dir crashinfo-1:

Diretório de informações de travamento:/    

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

12 -rwx 724015 Out 15 2014 07:14:32 -04:00 system-report_1_20141015-11342-UTC.gz

3850#dir crashinfo-2:

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

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

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

Note: Certifique-se de coletar a saída de "dir crashinfo-x:" para cada switch nessa pilha, pois o "show tech" não listará os sistemas de arquivos disponíveis ou os arquivos crashinfo. É importante que você tenha a imagem completa de cada membro nessa pilha. Atualizar: A partir das versões mais recentes do IOS-XE >3.6E, o show tech refletirá a saída ''dir crashinfo:' + 'show file systems'. Veja CSCun50428 .

Seções interessantes no relatório do sistema

Do ponto de vista do TAC, essas são algumas das entradas visualizadas 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 aqui contidos que o desenvolvimento pode querer revisar.

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

Esta é uma pequena saída para entender genericamente por que uma redefinição foi vista. Consulte a seção de tipos de falhas abaixo para ver o significado e o contexto em como esses motivos vão variar.

arquivo de log: IOS

Este é o buffer de log mantido no IOSd. Todos os comandos que foram emitidos pelo usuário ou syslogs gerados no IOSd serão encontrados nesta seção. Os registros mais recentes estão no final dessa saída.

Buffer de rastreamento: stack-mgr-events

Mantém o controle dos eventos vistos pelo gerenciador de pilha, que incluirão quando outros membros estiverem ingressando/removendo da pilha ou por qual porta da pilha as mensagens entram.

               

Buffer de rastreamento: redundancy-timer-ha_mgr

Exibe eventos de manutenção de atividade entre os switches na pilha. Os timestamps podem ajudar a determinar quando a falha na comunicação começou.

Tipos de falhas

Esta seção destacará algumas redefinições comumente vistas de um relatório do sistema que são normalmente chamadas pelo processo do gerenciador de pilha. O gerenciador de pilha é um processo linux que gerencia os membros na pilha e supervisionará quaisquer alterações 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 enviará um sinal de recarga para switches individuais para que a pilha seja redefinida. Abaixo também serão listados bugs conhecidos que foram associados ao respectivo tipo de falha.

Note: Nem todas as recargas do gerenciador de pilha são atribuídas a um problema de software. Na verdade, é mais comum ver esses problemas se manifestarem como um problema secundário/vítima para um problema de hardware subjacente.

Motivo da redefinição: reinicialização/recarregamento solicitado por [stack-manager]. [Incompatibilidade de ISSU]

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

Motivo da redefinição: pid do serviço [iosd]:[xyz] terminado anormalmente [11].

Isso é visto quando o switch trava no processo IOSd. A análise dos diretórios de informação de travamento para qualquer arquivo de informação de travamento + lixões de núcleo pode ser usada para depurar ainda mais essa falha.

header_sup_reset: Motivo da redefinição: reinicialização/recarregamento solicitado por [stack-manager]. [mesclagem de pilha]

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

CSCuh58098 - A pilha 3850 pode recarregar quando houver problemas de cabeamento de pilha

CSCui56058 - Ativação da lógica de devolução para cabo de pilha

CSCup53338 - 3850 travamento de IOSD | Sinal=SIGSEGV(11) @ pm_port_data_from_swidb

header_sup_reset: Código de razão:[4] Motivo da redefinição:Reinicialização/recarregamento solicitado por [stack-manager]. [mesclagem de pilha devido a incompatibilidade]

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

CSCuo49555 /CSCup58016 - 3850/3650 travamentos devido a inundação unicast na porta mgmt

CSCur07909 - Mesclagem de pilha devido à perda de conectividade ativa e em standby

Motivo da redefinição: reinicialização/recarregamento solicitado por [stack-manager]. [Vizinho errado encontrado após a votação do ASIC]

Os switches participam de uma votação ASIC durante a inicialização para determinar seus switches vizinhos dentro da pilha. Essa redefinição pode ser vista quando um temporizador expira para que um vizinho se declare ou se há um erro lógico durante a conversação de nbrcast. Isso foi observado no contexto de cabos de pilha defeituosos que foram resolvidos por meio da substituição.

CSCun60777 - Switch recarregado devido ao vizinho incorreto encontrado após a votação ASIC

CSCud93761 - Switch recarregado devido ao vizinho incorreto encontrado após a votação ASIC

header_sup_reset: Código de razão:[4] Motivo da redefinição:Reinicialização/recarregamento solicitado por [stack-manager]. [perdeu ativo e standby]

Normalmente, isso é visto de um membro na pilha que não está em uma função ativa ou em standby. Quando o ativo falhar, se não houver um switch em standby para assumir a função ativa da pilha, toda a pilha será redefinida. Se a pilha for 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 ficaram inativos ou, potencialmente, uma indicação de que a redundância não está sincronizando corretamente. Isso também pode ser visto quando as pilhas são configuradas em uma configuração de meio anel.

CSCup53882 - Switches membro em uma reinicialização da pilha 3850 - [perdeu ativos e em standby]

header_sup_reset: Código de razão:[1] Motivo da redefinição:Reinicialização/recarregamento solicitado por [stack-manager]. [Keepalive_Timeout]

Exibido quando mensagens de manutenção de atividade não são recebidas do switch na pilha. Observando "Trace Buffer: redundancy-timer-ha_mgr" deve mostrar a troca de mensagens keep alive e fornecer uma perspectiva de tempo para quando a falha na comunicação começou. A coleta de relatórios de switch do resto da pilha e a observação de registros durante o intervalo de tempo podem ajudar aqui.

header_sup_reset: Motivo da redefinição: reinicialização/recarregamento solicitado por [stack-manager]. [Recarregar comando]

Esse é um motivo de reinicialização bastante intuitivo - isso é visto quando o gerenciador de pilha recebe uma solicitação de recarga que pode ser invocada por meio da CLI ou externamente através do dispositivo de gerenciamento (SNMP). Nos casos de CSCuj17317 , isso também será exibido como um "comando reload" emitido. Do arquivo de log: IOS que 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 relevantes

CSCur76872 - O gerenciador de pilha fica inativo quando o sistema fica sem o buffer SDP.

CSCup49704 - 3850 FED Crash - Aguardando canais SPI FED_SPI_FLCD,FED_SPI_FAST ...

Diagnosticando um possível problema de porta/cabeamento da pilha

Sintoma 1) Qualquer sinal de um problema de cabeamento da pilha será aparente por qualquer oscilação da porta da pilha antes da redefinição. Olhando para o "arquivo de registro: O relatório do IOS" antes de uma redefinição normalmente é um bom ponto de partida. Aqui está um exemplo de onde você vê oscilação da porta da pilha registrada no SW2 atual e no SW1 em standby. Essa mesma porta da pilha estava oscilando cada uma em cada instância da redefinição e foi resolvida substituindo o cabo da pilha:

=====================  log file: 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) Dependendo da configuração em sentido de pilha usada (180, 480 e mais), o número de anéis de transmissão por porta ASIC irá variar. Esses comandos pesquisarão os registros globais que mantêm um total em execução de quantos erros de leitura são 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 crescente pode isolar se há algum problema na porta ou com o cabo da pilha.

Eles podem ser coletados várias vezes em 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 PCS desconhecida, erro de disparidade de execução detectado

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

• O erro de bit na pilha causou um erro de CRC de palavra de chamada

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

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>

Veja a seguir um exemplo em que você teve um evento de mesclagem de pilha visto por ambos os membros de uma pilha de 2 membros sem nenhum sinal de uma porta de pilha oscilante. Você vê o aumento do anel[0] com CRCs na porta-1 da pilha do switch 1 e acabou substituindo o cabo da pilha para superar esse problema.

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

Note: Dependendo do registro que está sendo examinado, a máscara pode ser diferente em cada caso. No exemplo acima, a máscara será envolta nos últimos 14 bits. Assim, quando o contador atingir 0x00003FFF, ele será finalizado em 0x00000000.

Dicas adicionais

1.  Arquivando diretórios de informação de travamento

Mais switches na pilha significa que haverá mais arquivos de relatório a serem coletados. É fácil ficar sobrecarregado pelo número de relatórios gerados. A organização é vital para isolar uma falha. Encontre uma consistência usando os timestamps 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 desses switches para que o cliente não carregue vários arquivos. O diretório crashinfo também pode ser arquivado para que o cliente possa enviar um único arquivo contendo os relatórios interessados. O seguinte 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. Recuperação de uma pilha instável

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

- Desligue toda a pilha e recoloque todos os cabos da pilha com firmeza.

- Ligue cada switch membro na pilha um a 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 solucionar problemas ainda mais.

3. Gerar relatórios do sistema manualmente

A criação manual de relatórios de sistema exige que o ‘serviço interno’ seja ativado. Isso gravará 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>