Pesquisando defeitos 3650/3850 dos reloads pelo gerente da pilha através de um sistema relate

 

Introdução

Pesquisar defeitos reloads da pilha com um relatório do sistema na ausência de um impacto é feita geralmente em plataformas de switching NGWC usando a tecnologia do stackwise. A documentação atual é limitada nos usos de um relatório do sistema e este guia está sendo escrito para explicar como você pode leverage estes relatórios para diagnosticar os problemas encontrados tipicamente com empilhamento de edições. Este guia é alinhado particularmente para as arquiteturas de switching do catalizador 3650/3850 que executam IOS-XE que apoia o empilhamento de capacidades.

A maioria das edições com a haste da tecnologia do stackwise de um problema de comunicação entre os membros dentro de uma pilha. Toda a inconsistência da informação entre os membros ou a perda de conectividade pode conduzir a um problema que permee através da pilha inteira que conduz finalmente a uma restauração com gerente da pilha. Este documento destacará alguns dos tipos comuns de falhas consideradas com reloads do pilha-gerente, usos de um relatório do sistema, e os CLI relevantes disponíveis diagnosticar e tipos de problema diferentes.

Informações de fundo:

Relatório do sistema contra relatórios do interruptor

Um sistema-relatório é um relatório detalhado do membro de como percebe o estado da pilha. Este não é um crashinfo (que despejará para fora a memória para uma eliminação de erros mais adicional), mas pelo contrário, é um relatório que tenha logs e informação sobre debugging para vários serviços que executa sob IOS-XE que seria útil para que o desenvolvimento siga o estado desse serviço. Um sistema-relatório pode ser gerado quando o interruptor é recarregado pelo gerente da pilha, um impacto do processo ocorreu, ou gerado manualmente pelo usuário durante a operação viva.

 

Em muitos casos, há as situações em que um switch único pôde falhar em uma pilha mas o resto dos membros pode permanecer intacto. Para recolher como a informação no estado da pilha no tempo concedido, os switch_reports estiveram introduzidos de modo que os membros restantes gerassem um quando detecta que um membro foi para baixo. O switch_report será um relatório local de como esse membro percebe o estado atual da pilha.

 

Nota: Estes relatórios são escritos e comprimidos assim que não podem ser imprimidos ao terminal usando “mais”. Deverão ser transferidos fora do interruptor e ser descomprimidos para ver o log.

 

Onde recolher relatórios do sistema/interruptor

Os relatórios do sistema serão escritos tipicamente no crashinfo: diretório do membro nessa pilha. Por exemplo, se há uma pilha do interruptor do x-membro, a seguir cada interruptor terá seu próprio diretório do crashinfo que pode ser acessível usando do “o crashinfo-x dir” onde “x” corresponde a esse membro dentro da pilha.

 

3850#dir crashinfo-1:

Diretório do crashinfo: /    

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

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 - last_systemreport_log do rwx 357 14 de agosto de 2015 07:50:49 -04:00  

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

 

Nota: Seja certo recolher a saída para do “o crashinfo-x dir: ” para cada interruptor nessa pilha porque “a tecnologia da mostra” não alistará para fora os sistemas de arquivos disponíveis ou os arquivos crashinfo (informaçoes de travamento). É importante que você tem a imagem inteira de cada membro nessa pilha. Atualização: Até à data de umas liberações mais novas >3.6E IOS-XE, a tecnologia da mostra refletirá do '' o crashinfo dir: '+ saída do “show file systems”. Veja CSCun50428 .

 

Seções interessantes no relatório do sistema

De uma perspectiva TAC, estes são algumas das entradas mais comumente vistas dentro do relatório do sistema que pode ajudar a diagnosticar eventos de uma edição específica. Há outros logs dos outros serviços contidos em aqui que o desenvolvimento pode encontrar para querer rever.

 

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

Esta é uma saída curto a compreende muito genericamente porque uma restauração foi considerada. Veja os tipos abaixo de seção das falhas para olhar o significado e o contexto em como estas razões variarão.

 

arquivo de registro: IOS

Este é o buffer de registro mantido de dentro de IOSd. Os comandos any que foram emitidos pelo usuário ou pelos Syslog gerado dentro de IOSd serão encontrados nesta seção. A maioria de logs recentes são para a extremidade desta saída.

 

Trace buffer: pilha-mgr-eventos

Mantém-se a par dos eventos vistos do gerente da pilha de que incluirão quando outros membros são se juntar/removidos da pilha ou de que a porta de pilha as mensagens entra através.

               

Trace buffer: redundancy-timer-ha_mgr

Indica eventos da manutenção de atividade entre o Switches na pilha. Os timestamps podem ajudar a determinar quando a divisão em uma comunicação começou.

 

Tipos de falhas

Esta seção destacará algum geralmente - as restaurações consideradas de um relatório do sistema que são invocadas tipicamente pelo processo de gerenciador da pilha. O gerente da pilha é um processo do linux que controle os membros na pilha e vigie todas as mudanças nos papéis entre o Switches na pilha. Se o gerente da pilha detecta um problema durante a eleição da iniciação ou do papel, enviará um sinal do reload ao Switches individual para que a pilha restaure. Abaixo da vontade igualmente aliste os Bug conhecido que foram associados ao tipo de falha respectivo.

 

Nota: Não todos os reloads do pilha-gerente são atribuídos a um problema de software. De fato, é mais comum ver estes problemas manifestos como uma edição secundária/vítima a um problema de hardware subjacente.

 

Razão de reinicialização: Restaure/Reload pedido pelo [stack-manager]. [ISSU Incompatibility]

Você pôde ver este tipo de restauração quando há uma falha de sincronização maioria ao tentar sincronizar a configuração no mestre entre todos os membros na pilha. Verificando o arquivo histórico: Os IO ou o os logs do interruptor ativo puderam destacar as configurações que contribuíram a esta restauração.

Razão de reinicialização: Preste serviços de manutenção ao [iosd] pid: o [xyz] terminou anormalmente [11].

Isto visto quando o interruptor causar um crash no processo de IOSd. Olhar os diretórios do crashinfo para todos os arquivos crashinfo (informaçoes de travamento) + dumps principais pode ser usada para debugar mais esta falha.

 

hap_sup_reset: Razão de reinicialização: Restaure/Reload pedido pelo [stack-manager]. [stack merge]

Uma fusão da pilha está considerada quando há dois ou mais Switches que o acredita é o mestre da pilha. Isto pode ser visto quando lá é uma ruptura no anel de uma pilha (isto é dois cabos estão desligados da pilha) assim que o ativo e o à espera perdem uma comunicação aos outros membros. A adição de um interruptor já posto a uma pilha existente pode causar uma fusão da pilha porque haverá dois Switches ativos na pilha.

 

CSCuh58098 - 3850 pilhas podem recarregar quando as questões de cabeamento da pilha estam presente

CSCui56058 - Permitindo a lógica do debounce para o cabo da pilha

CSCup53338 - impacto 3850 IOSD | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

 

hap_sup_reset: Razão de reinicialização da razão Code:[4]: Restauração/Reloadrequested pelo [stack-manager]. [stack merge due to incompatibility]

Isto esteve visto nas situações quando um interruptor ativo e à espera existe na pilha. Se o interruptor ativo perde uma comunicação ao apoio, o apoio tentará tomar sobre como o active mesmo que o active seja ainda acima.

 

CSCuo49555 /CSCup58016 - 3850/3650 dos impactos devido ao unicast inundam na porta do mgmt

CSCur07909 - Empilhe a fusão devido ao active e à Conectividade perdida à espera

 

 

Razão de reinicialização: Restaure/Reload pedido pelo [stack-manager]. [Wrong neighbor encountered after ASIC ballot]

O Switches participa em uma cédula ASIC durante a bota determina até seus switch confinante dentro da pilha. Esta restauração pode ser considerada quando um temporizador expira para que um vizinho se declare ou se há um erro lógico durante a conversação do nbrcast. Isto foi visto no contexto dos cabos defeituosos da pilha que foram resolvidos através da substituição.

 

CSCun60777 - Comute devido recarregado lesar o vizinho encontrado após a cédula ASIC

CSCud93761 - Comute devido recarregado lesar o vizinho encontrado após a cédula ASIC

 

 

 

hap_sup_reset: Razão de reinicialização da razão Code:[4]: Restaure/Reload pedido pelo [stack-manager]. [lost both ative and standby]

Isto é visto tipicamente de um membro na pilha que não é no um active ou papel de standby. Quando o active falha, se não há nenhum interruptor à espera para supor o papel ativo para a pilha, a seguir a pilha inteira restaurará. Se a pilha é um estado instável ou política da Redundância tem não sincronizado ainda, esta pode ser vista. Isto é provável uma vítima do porque Switches ativo/à espera foi para baixo ou potencialmente uma indicação que a Redundância não é em sincronismo corretamente. Isto pode igualmente ser visto em quando as pilhas são configuradas em uma instalação do metade-anel.

 

CSCup53882 - Switch membros em uma repartição de 3850 pilhas - [lost both ative and standby]

 

hap_sup_reset: Razão de reinicialização da razão Code:[1]: Restaure/Reload pedido pelo [stack-manager]. [Keepalive_Timeout]

Visto quando as mensagens da manutenção de atividade não forem recebidas do interruptor na pilha. Olhando a “trace buffer: o redundancy-timer-ha_mgr” deve mostrar a troca de mensagens da manutenção de atividade e fornecer uma perspectiva da hora para quando a divisão em uma comunicação começou. Recolher relatórios do interruptor do resto da pilha e olhar logs durante o tempo de frame podem ajudar aqui.

 

 

hap_sup_reset: Razão de reinicialização: Restaure/Reload pedido pelo [stack-manager]. [Reload command]

Esta é uma razão de reinicialização consideravelmente intuitiva – esta é vista quando o pilha-gerente recebe um pedido do reload que poderia ser invocado com o CLI ou externamente através do gerenciamento de dispositivo (SNMP). Nos casos de CSCuj17317 , isto igualmente aparecerá como um “comando reload” emitiu também. Do arquivo de registro: IO 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

 

Erros relevantes

CSCur76872 - O gerente da pilha vai abaixo de quando o sistema é executado fora do buffer SDP.

CSCup49704 - 3850 ALIMENTADOS o impacto - SPI de espera canaliza FED_SPI_FLCD, FED_SPI_FAST…

 

 

 

Diagnosticando uma edição de expedição de cabogramas da /porta da pilha potencial

Sintoma 1) Todos os sinais de uma questão de cabeamento da pilha serão aparentes por qualquer flapping da porta de pilha antes da restauração. Olhando o “arquivo histórico: Os IO” relatam antes de uma restauração são tipicamente um bom lugar a começar. Está aqui um exemplo de onde você vê o flapping da porta de pilha que é registrada no SW2 atual e no SW1 à espera. Esta mesma porta de pilha batia cada um em cada exemplo da restauraçã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) Segundo a instalação do stackwise é usado (180, 480, mais), o número de anéis da transmissão pela porta ASIC variará. Estes comandos votarão os registros globais que mantêm um funcionamento total de quantos erros de leitura são considerados para cada anel da transmissão. o “Porta-ASIC 0" corresponde à porta de pilha 1 e o “porta-ASIC 1" corresponde à porta de pilha 2. Isto deve ser emitido para cada interruptor e todos os sinais de incrementar contagens podem isolar-se se lá talvez um problema na porta ou com o cabo da pilha.

 

 

 

 

Estes podem ser recolhidos diversas vezes sobre alguns minutos comparar os deltas na contagem:

 

mostre o <switch#> lido <0-1> do interruptor de SifRacDataCrcErrorCnt do registro da plataforma porta-ASIC

• Segmento com erro CRC dos dados

mostre o <switch#> lido <0-1> do interruptor de SifRacRwCrcErrorCnt do registro da plataforma porta-ASIC

• Incrementado em alguma verificação falhada CRC

mostre o <switch#> lido <0-1> do interruptor de SifRacPcsCodeWordErrorCnt do registro da plataforma porta-ASIC

• Incrementado no código inválido PCS, as palavras de código desconhecidas PCS, erro running da disparidade são detectadas

mostre o <switch#> lido <0-1> do interruptor de SifRacInvalidRingWordCnt do registro da plataforma porta-ASIC

• Erro de bit no erro CRC causado pilha do ringword

 

 

O seguinte é um exemplo onde você teve um evento da fusão da pilha visto ambos os membros de uma pilha 2-member sem nenhuns sinais de uma porta de pilha do flapping. Você vê ring[0] incrementar com os CRC na pilha port-1 do interruptor 1 e terminado acima de substituir o cabo da pilha para obter após esta edição.

 

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

 

Nota: Segundo o registro que está sendo olhado, a máscara talvez diferente em cada caso. No exemplo acima, a máscara envolverá ao redor nos últimos 14 bit. Assim, quando o contador alcança 0x00003FFF, envolverá de volta a 0x00000000.

 

Pontas adicionais

1. Arquivando diretórios do crashinfo

Mais Switches na pilha significa que haverá mais arquivos de relatório a ser recolhidos. É fácil obter oprimido pelo número de relatórios que são gerados. A organização é vital a isolar uma falha. Encontre uma consistência usando timestamps de quando cada interruptor redigiu o arquivo de relatório para um incidente dado se possível. De lá, peça aqueles relatórios muito específicos daquele Switches dado assim que o cliente não transfere arquivos pela rede diversos arquivos. O diretório do crashinfo pode igualmente ser arquivado assim que o cliente pode enviar um único arquivo que contém os relatórios interessados. O seguinte criará um arquivo nomeado “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. Recuperando uma pilha instável

Pode haver algumas situações onde você vê diversos membros em uma pilha que recarrega durante a bota acima depois que o processo de eleição da pilha ocorre. Se um interruptor recarregado se acredita para ser o mestre da pilha então este pode frequentemente conduzir a um evento da fusão da pilha e participará em um estado do laço da bota. Nesta situação, pode ser aconselhável perguntar ao cliente:

- Põe para baixo a pilha inteira e assente todos os cabos da pilha firmemente.

- Ligar cada switch membro na pilha um por um até que todos os membros convirjam a seu estado previsto.

- Nos casos onde um membro não se junta à pilha, não se remove isto da pilha e não se tenta carreg este indivíduo como um autônomo para pesquisar defeitos mais.

 

3. Gerencia relatórios do sistema manualmente

Manualmente criar relatórios do sistema exige o “serviço interno” ser permitida. Isto escreverá um relatório do sistema como um arquivo de texto que possa ser feito pela base do interruptor.

 

 

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>