Switches : Switches Cisco Catalyst 4500 Series

Compreensão e Troubleshooting de Tempo Limite Esgotado de Astro/Lemans/NiceR nos Catalyst 4000/4500 Series Switches

17 Outubro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (7 Outubro 2015) | Feedback


Índice


Introdução

A série do interruptor do catalizador 4000/4500 usa um projeto do stub ASIC na arquitetura do switch. Switch manages these linecard stub ASICs (Astro/Leman/NiceR) through internal management control protocol. Quando essas solicitações e respostas desse gerenciamento interno são perdidas ou atrasadas, são geradas mensagens do console e do syslog. Como os motivos dessas perdas de comunicação variam, a causa principal não fica evidente com essas mensagens de erro.

A intenção deste documento é ajudar a compreender a mensagem Astro/Leman/Nicer Timeout gerada na plataforma Cat4000 e a resolvê-los com a assistência do TAC da Cisco. As versões futuras de CatOS e Cisco IOS� oferecerão Mensagens de Erro melhorados, e se possível, identificam a causa de raiz do problema.

Quando o stub asic (ASTRO/LEMANS/NICER) timeout ocorre, as mensagens similares ao seguimento obtêm relatadas em um interruptor do catalizador baseado 4000/4500 de CatOS:

%SYS-4-P2_WARN: 1/Astro(4/3) - timeout occurred
%SYS-4-P2_WARN: 1/Astro(4/3) - timeout is persisting

Observe que, dependendo das versões do software, o teor da mensagem de erro pode variar. Astro, Lemans e Nicer referem-se a diferentes tipos de ASIC de stub. Mais detalhes estão descritos na seção Material de Suporte deste documento.

Em Supervisores baseados em Cisco IOS (Supervisor II+, III e IV), a mensagem de erro aparece da seguinte maneira:

%C4K_LINECARDMGMTPROTOCOL-4-INITIALTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - management 
request timed out. 
%C4K_LINECARDMGMTPROTOCOL-4-ONGOINGTIMEOUTWARNING: Astro 5-2(Fa5/9-16) - consecutive 
management requests timed out.

Nota: Este documento endereça primeiramente o Troubleshooting em supervisores ou no Switches CatOS-baseado. Alguma da informação é aplicável ao supervisor baseado Cisco IOS quando notável.

Nota: Este documento também discute a ASIC Astro stub, mas a maioria das seções pode ser aplicada a outro tipo de placas de linha ASIC stub (Lemans e Nicer), que serão observadas nas seções adequadas.

Depois de ler este documento, o leitor terá uma compreensão do seguinte:

  • A função de ASICs de stub no Catalyst 4000/4500.

  • As condições que podem levar às mensagens de timeout dos pacotes de gerenciamento interno.

  • As etapas a serem executadas e os comandos a serem reunidos para o Cisco TAC ao Troubleshoot essa condição.

As seções de Troubleshooting e de Intervalo Astro, oferecem explicações e informações detalhadas sobre cada problema. Como alternativa, é possível saltar diretamente para a seção Formas Simples de Fazer Troubleshooting, neste documento.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento é específico ao supervisor ou às placas de linha do catalizador 4000/4500 usando o asics stub.

Material de Suporte

ASIC de stub Astro, que consulta os ASICs de stub 10/100, controla um grupo de oito portas 10/100 adjacentes que se comunicam com o Supervisor por meio de uma conexão de largura de banda Gigabit com o backplane, conforme mostra a figura abaixo.

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe5.gif

Os supervisores se comunicam com o ASIC do stub da placa de linha por meio do componente SERDES (SERealizer-DESerializer). Há um componente no lado do Supervisor que se conecta ao painel traseiro e outro SERDES na placa de linha de cada ASIC de stub para se conectar ao painel traseiro.

O diagrama acima pode ser usado geralmente para pesquisar defeitos o tipo diferente de placas de linha. O stub ASIC consultado nos mensagens de timeout seria diferente segundo o tipo de placa de linha. Veja a tabela abaixo para uma lista de nomes ASIC e de sua descrição.

ASICs stub Descrição Exemplo
Astro ASIC stub do controlador 10/100 de 8 portas WS-X4148-RJ45V
NiceR 4 stub ASIC do controlador da porta 1000 WS-X4418-GB (portas 3 a 18)
Le Mans 8 stub ASIC do controlador da porta 10/100/1000 WS-X4448-GB-RJ

O tráfego de gerenciamento interno corre através de ambos o componente de SERDES junto com o tráfego de dados normal. O tráfego de gerenciamento interno é usado ao read/write o stub ASIC e registros de Phy. As operações mais comuns incluem a leitura de estado de enlace e estatísticas.

Maneiras Simples de Analisar Falhas

As seguintes seções explicam o significado e as causas possíveis do %SYS-4-P2_WARN: 1/(Stub)(module_number/) Stub_reference – o intervalo ocorreu Mensagem de Erro no catalizador 4000/4500.

As mensagens do intervalo Astro (stub) foram adicionadas à versão de software começando pela 6.2.3 e 6.3.1 e aprimoradas posteriormente na versão 6.4.4 (CSCea73908) para indicar que o Supervisor perdeu os pacotes de controle de gerenciamento interno na comunicação com o Astro stub ASIC em placas de ingresso 10/100. Há várias causas para essa perda de comunicação, conforme explicado em detalhes abaixo na seção Troubleshooting.

O fluxograma de Troubleshooting a seguir apresenta uma maneira rápida e fácil de isolar o problema dentre as diversas causas principais possíveis:

http://www.cisco.com/c/dam/en/us/support/docs/switches/catalyst-4000-series-switches/45640-astroe8.gif

** As várias causas de raiz podem exibir sintomas similares. Contacte por favor o TAC para um Troubleshooting mais adicional.

Limites de tempo esgotado de ASIC de stub (Astro/Lemans/NiceR)

O Astro/Le Mans/Nicer timeout é relatado quando o software supervisor não recebe várias respostas de gerenciamento interno do stub ASIC da placa de linha. Isto pode ocorrer se:

  • A solicitação de gerenciamento está perdida ou atrasada

  • Resposta de gerenciamento perdida ou atrasada

Um “intervalo ocorreu…” a mensagem é imprimida uma vez que o software cronometrou para fora as épocas 10 consecutivas ao esperar a resposta do pacote de gerenciamento. Os intervalos consequentes conduzem Gerenciamento consecutivo à impressão “….” ou “. .timeout que persistem.” mensagens, segundo a versão do software.

Essa mensagem de registro é limitada por taxa para uma vez a cada 10 minutos. O encaminhamento de pacote ao asics stub afetado continua quando os intervalos estão ocorrendo. Contudo nenhuma mudanças ao link/à velocidade/duplex da autonegociação não são consideradas porque o software não recebe as respostas do pacote de gerenciamento. Além disso, o processo de atualização das estatísticas de tráfego do grupo de interfaces é afetado quando ocorrem intervalos.

Troubleshooting

Há umas várias causas para o Astro/mensagens de Le Mans/Nicer timeout a aparecer. Cada um deles é descrito abaixo.

Causa 1: Carga de tráfego intenso, loop de camada 2 ou tráfego excessivo na rede em direção à CPU

O seguinte pode causar condições do intervalo do stub:

  • Problemas de rede

  • Problemas de configuração

  • Elementos vizinhos

  • Outros fatores fora de um Catalyst Switch

Um loop da camada 2 ou uma tempestade de broadcast que resulte em uma alta carga de tráfego pode causar perda de pacotes de controle de gerenciamento interno. Em geral, isto acontece por causa da CPU estar ocupada (hog de CPU) e não ser possível processar as filas).

O tráfego de controle de gerenciamento interno usa o mesmo caminho de dados para o Supervisor que o tráfego normal de dados no Astro (ou qualquer outro chip de Stub). Assim, os pacotes de controle podem obter perdido devido à congestão.

Com a correção para o ID de bug Cisco CSCea73908 (somente clientes registrados), o período de timeout de requisição de gerenciamento interno é melhor manipulado na versão de CatOS 6.4(4) e versões mais recentes. Esse aprimoramento pode evitar muitos timeouts de pacotes de controles temporários causados pelo fato de a CPU estar ocupada.

Ação: Pesquise defeitos o laço da camada 2; ou configuração da mudança para resolver testes padrão de tráfego.

Solução: Mova a relação do gerenciamento de switch (sc0) para o tráfego VLAN do não utilizador em switch com base em CAToS. Use o comando do <vlan-id> da relação sc0 do grupo mover o vlan da relação sc0.

Nota: Começando com o Cisco IOS 12.1(20)EW, o Cisco IOS com base em Supervisors apresenta uma otimização no tratamento do mecanismo de tratamento de pacote de gerenciamento interno pela CPU. Este aperfeiçoamento ajudará a evitar perda de pacotes de controle de gerenciamento internos, devido a tráfego de prioridade baixa que ocupa desnecessariamente a CPU.

Solução: Consulte a solução temporária acima.

Causa 2: Cabeamento semi-duplex/ tipo 1A

As portas de usuário do painel frontal estão configuradas em semi-duplex. As colisões do tráfego de saída com o tráfego de entrada no ASIC de stub podem fazer com que o buffer do stub seja esvaziado muito lentamente. Esse problema pode fazer com que as filas TX no Supervisor sejam completadas e que novas requisições de gerenciamento interno sejam descartadas, o que pode resultar em mensagens de erro de intervalo de parada.

Uma rede com cabeamento Type1A também pode provocar esse problema. Quando uma estação de trabalho conectada ao Baluns do Tipo1A com uma correção de programa RJ-45 é desligada, o Balun dá laços - em traseiro internamente e faz com que o tráfego de saída retorne. Esta situação simula a conexão de um loopback externo na porta do painel frontal. Antes que a porta se mova para o estado de bloqueio, o tráfego de saída é loop no interruptor. Isto pode fazer com que os bufferes do stub transbordem, segundo a taxa de tráfego.

Ação: Consulte solução.

Solução: Evite a configuração semi-duplex. No caso do Tipo1A que cabografa, evite obstruir para fora o fio de correção RJ-45 do Balun do Tipo1A para evitar formar um loopback interno no Balun.

Solução: Consulte solução.

Causa 3: Falha do componente SERDES

Se os erros estão considerados somente em um Astro (ou em outro stub ASIC) em um módulo, e um laço da camada 2 não está ocorrendo, o problema é mais provável um componente DERDES com falha no supervisor ou na placa de linha. Por exemplo, se o Mensagem de Erro está sempre no Astro 4 no módulo 3 como mostrado abaixo, a seguir o componente de SERDES no módulo 3 ou o componente de SERDES no supervisor são defeituoso.

%SYS-4-P2_WARN: 1/Astro(3/4) – timeout occurred

No Mensagem de Erro acima, o número "4" no parêntese refere o Astro #, e não a porta real 3/4. Este número provê um grupo de oito portas (3/33-3/40), porque é o quarto Astro no módulo 3.

Um componente SERDES defeituoso pode gerar conectividade intermitente para o tráfego de controle e de dados para Astro/Lemans/NiceR, o que resultará em timeouts. Tipicamente, contudo, o Mensagem de Erro será indicado continuamente se o SERDES é defeituoso.

Ação: Para determinar qual SERDES (Supervisor ou placa de linha) é inválido, execute as seguintes etapas:

  1. Move a placa de linha para um slot reserva no chassi ou para outro chassi. Se o entalhe livre está disponível, troque entalhes com o módulo de funcionamento conhecido.

  2. Se você continua a obter o Astro/Le Mans/Nicer timeout no mesmo Astro/Le Mans/mais agradável no entalhe novo, a seguir muito provavelmente o SERDES ou o Astro/Le Mans/mais agradável na placa de linha falharam e a placa de linha precisa de ser substituída

    Nota: Reintroduzindo o módulo em um entalhe de reposição, os diagnósticos on-line são executados na placa de linha. Se um SERDES defeituoso ou o Astro/Le Mans/mais agradável são encontrados, a seguir o interruptor marcará a porta como defeituosa.

  3. Se os tempos limites não continuarem a ocorrer na placa de linha original Astro/Lemans/Nicer, é possível que o Supervisor SERDES esteja com defeito. Para verificar isso, insira módulo em bom estado de operação no slot original e veja se os tempos limites ocorrem com o novo módulo.

    Se trabalha, é possivelmente um SERDES está no supervisor. Refira o Field Notice parcial da perda de conectividade das exibições do supervisor do catalizador WS-X4013 para uma lista de números de série afetados com o componente de SERDES falhando.

Solução: Nenhum

Solução: Entre em contato com o TAC para o Troubleshooting de outras falhas.

Causa 4: Falha transitória/SRAM de hardware

Os dispositivos conectados a um catalizador 4000 com um Supervisor I ou II ou III ou motor ou Catalyst 2948G IV, Cat2980G podem experimentar a perda de conectividade de rede parcial ou completa. Alguns ou todas as portas podiam ser afetados. Esses sintomas serão acompanhados de um rápido aumento das mensagens de erro de pacotes descartados por CRC inválido no Supervisor baseado em CatOS, e das mensagens de erro de intervalo do ASIC de stub.

O problema é devido a uma falha da memória de buffer de pacote de informação (SRAM), que seja um tipo duro ou transiente.

Ação: Selecione o curso de ação segundo que das duas Assinaturas com Falha transientes da memória de buffer de pacote de informação abaixo ocorreram:

  1. Assinatura de falha da memória de buffer do pacote transitório para SUP I , SUP II, 2948G, 2980G

    A seguir, estão os sintomas deste problema:

    • InvalidPktBufferCRC's incrementa rapidamente com uma mensagem similar a esta

      %SYS-4-P2_WARN: 1/Invalid crc, dropped packet, count = xxxx
    • Uma reinicialização de software com uso do comando reset provocaria falha do Supervisor em passar o POST.

    • Se uma reinicialização difícil (desligar/religar) for executada, o Supervisor passará POST e não sofrerá mais falha.

    Nota: Em caso de uma falha dura da memória de buffer de pacote de informação para o Supervisor I, II, 2948G, 2980G, um hard reset não resolveriam o problema e o supervisor ou o interruptor ainda falhariam o CARGO.

    Para obter mais informações sobre esse assunto, consulte Cisco Bug ID CSCdy46288 (somente clientes registrados) para Supervisor II, Cisco Bug ID CSCeb56266 (somente clientes registrados) para Supervisor I/2948G/2980G e Cisco Bug ID CSCeb56325 (somente clientes registrados) para o WS-C2980G-A.

  2. Assinatura de Falha de Memória de Buffer de Pacotes Transitório para SUP III, SUP IV

    A seguir, estão os sintomas deste problema:

    • O contador VlanZeroBadCrc é incrementado rapidamente e exibido na saída do seguinte comando:

      show platform cpuport all (prior to 12.1(11b)EW1 ) 
      or  show platform cpu packet statistics all (Since 12.1(11b)EW1) 
      depending upon the software version. Starting from 12.1(19)EW, 
      you should also see the following error message rapidly incrementing errors: 
      
      %C4K_SWITCHINGENGINEMAN-2-PACKETMEMORYERROR3: Persistent Errors in 
      Packet Memory xxxx
      
    • Um soft reset faria com que o supervisor falhasse o CARGO. Use o comando do show diagnostics power-on verificar a falha.

    • Uma reinicialização total (desligamento e religamento) irá recuperar o Supervisor e aprovará o POST.

    Nota: No caso de uma falha total de SRAM do Supervisor III/IV, uma reinicialização não recuperará o Supervisor e continuará reprovando o POST.

    Para obter mais informações sobre esse problema no Supervisor III/IV, consulte a ID de bug Cisco CSCdz57255 (apenas clientes registrados).

Solução: Põe o ciclo ou o hard reset o interruptor no caso do problema de SRAM transitório. O problema de SRAM difícil não tem solução alternativa.

Solução: Entre em contato com o TAC para o Troubleshooting de outras falhas.

Causa 5: Falha do relógio do Supervisor

Se o Astro/Mensagens de Erro de Le Mans/Nicer timeout é visto que referem números do módulo múltiplo ou o Astro múltiplo/Le Mans/mais agradável, a seguir este poderia indicar uma falha do relógio possível no supervisor. Geralmente, uma falha de relógio é acompanhada da mensagem de erro de timeout Astro/Lemans/Nicer e das mensagens de erro BlockTXQueue e BlockedGigaport, conforme indicado abaixo:

%SYS-4-P2_WARN: 1/Blocked queue on gigaport ...

Ação: Entre em contato com o TAC para obter informações de Troubleshooting adicional sobre os IDs de bug CSCdp89537 e CSCdp93187 da Cisco (apenas para clientes registrados).

Solução: Nenhum

Solução: Entre em contato com o TAC para o Troubleshooting de outras falhas.

Causa 6: Interrupção por falta de alimentação

Um Catalyst 4000 Series Switch com um Supervisor II (WS-X4013) pode incorporar um estado em que o supervisor e as placas de linha são incapazes de se comunicar corretamente um com o otro. Quando o interruptor incorpora este estado, o diodo emissor de luz do status de módulo será (piscamento vermelho) e/ou os LED de porta piscarão em ordem similares a uma restauração do módulo ou do interruptor. Isso será acompanhado pelas mensagens de tempo limite esgotado Astro/Lemans/NiceR.

Este problema é causado por uma interrupção provisória da potência ao interruptor (menos Senhora de 500). A interrupção temporária de energia pode ser devido às alimentações instáveis em um ambiente de produção.

Ação: Veja a solução alternativa abaixo.

Solução: Restauração (macio ou duro (ciclo de energia)) o interruptor.

Solução: Upgrade para imagem de software com a correção de um ID de bug da Cisco, CSCea14710, (clientes registrados apenas) ou em versões posteriores.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 45640