O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento oferece uma breve explicação sobre mensagens de erro e do syslog comuns exibidas nos Cisco Catalyst 6500/6000 Series Switches que executam o software do sistema Cisco IOS®. Use o Cisco CLI Analyzer (somente clientes registrados) se você tiver uma mensagem de erro que não aparece neste documento. A ferramenta fornece os significados das mensagens de erro que o Cisco IOS Software e o software Catalyst OS (CatOS) geram.
Nota:O formato exato das mensagens do Syslog e de erro descritas neste documento pode variar ligeiramente. A variação depende da release do software executada no Supervisor Engine.
Observação: esta configuração mínima de registro no Catalyst 6500/6000 é recomendada:
Defina a data e a hora no switch ou configure o switch para utilizar o Network Time Protocol (NTP) a fim obter a data e a hora de um servidor NTP.
Certifique-se de que o registro e as marcas de data e hora do registo estejam habilitadas, que é o padrão.
Configure o switch para registrar em um servidor syslog, se possível.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
O switch informa esta mensagem de erro:
C6KPWR-SP-4-UNSUPPORTED: módulo sem suporte no slot [num], energia não permitida: [chars]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Oct 14 16:50:13: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type Oct 14 16:50:20: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allowed: Unknown Card Type
Esta mensagem indica que o módulo no slot especificado não possui suporte. [num] é o número do slot e [chars] fornece mais detalhes sobre o erro.
Atualize o software Supervisor Engine para uma versão que ofereça suporte ao módulo de hardware. Consulte a seção Hardware com Suporte das Release Notes dos Cisco Catalyst 6500 Series Switches para obter informações sobre o release relevante. Para resolver o problema que a mensagem descreve, execute uma destas ações:
Insira ou substitua o Módulo Switch Fabric.
Mova o módulo sem suporte para um slot diferente.
O switch informa esta mensagem de erro:
%DUAL-3-INTERNAL: IP-EIGRP 1: Erro Interno
A mensagem de erro indica que há um bug interno no Cisco IOS Software. O bug foi corrigido nestas releases:
Cisco IOS Software Release 12.2(0.4)
Cisco IOS Software Release 12.1(6.1)
Cisco IOS Software Release 12.2(0.5)T
Cisco IOS Software Release 12.1(6.5)E
Software Cisco IOS versão 12.1(6.5)EC
Cisco IOS Software Release 12.1(6)E02
Versão do Cisco IOS Software 12.2(0.18)S
Cisco IOS Software Release 12.2(2)B
Cisco IOS Software Release 12.2(15)ZN
Atualize o Cisco IOS Software para uma destas releases ou para a release mais recente.
O switch informa esta mensagem de erro:
%EARL_L3_ASIC-SP-4-INTR_THROTTLE: Acelerando "IP_TOO_SHRT"
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Jul 25 12:00:40.228 AEST: %EARL_L3_ASIC-SP-4-INTR_THROTTLE: Throttling "IP_TOO_SHRT"Intr. Exceeded permitted 1000/100 intrs/msec
Esta mensagem indica que o mecanismo de encaminhamento do switch recebe um pacote IP de um comprimento que é mais curto que o comprimento mínimo permitido. O switch descarta o pacote. Em versões anteriores, o pacote é descartado silenciosamente e contabilizado nas estatísticas do mecanismo de encaminhamento. Em versões posteriores, a mensagem de erro é gravada no syslog uma vez a cada 30 minutos. Estes problemas podem fazer com que o mecanismo de encaminhamento do switch receba este tipo de pacote IP:
Um driver de placa de rede (NIC) ruim
Um bug de driver de NIC
Um aplicativo com falha
O switch simplesmente informa que recebeu estes pacotes "ruins" e pretende descartá-los.
A origem do problema é externa ao switch. Infelizmente, o mecanismo de encaminhamento não mantém um registro do endereço IP de origem do dispositivo que envia esses pacotes ruins. A única maneira de detectar o dispositivo é utilizar um sniffer para rastrear a origem e substituir o dispositivo.
O switch informa esta mensagem de erro:
EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: interrupção não fatal [caracteres]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Apr 20 17:53:38: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt Apr 20 19:13:05: %EARL_L3_ASIC-SP-3-INTR_WARN: EARL L3 ASIC: Non-fatal interrupt Packet Parser block interrupt
A mensagem de erro %EARL_L3_ASIC-SP-3-INTR_WARN indica que o circuito integrado para aplicação específica (ASIC) da Camada 3 (L3) da Enhanced Address Recognition Logic (EARL) detectou uma condição não fatal inesperada. Isso indica que um pacote ruim, provavelmente um pacote que contenha um erro de checksum de IP da Camada 3, foi recebido e descartado. A causa do problema é um dispositivo na rede que envia pacotes ruins. Estes problemas, entre outros, podem causar os pacotes ruins:
NICs com falhas
Drivers de NICs com falhas
Aplicativos com falhas
Em releases mais antigas do Cisco IOS Software, esses pacotes são normalmente descartados sem serem registrados. O recurso de mensagens de erro de registro sobre este problema está disponível no Cisco IOS Software Release 12.2SX e posterior.
Esta mensagem é apenas para fins informativos. Como uma solução alternativa, use uma destas duas opções:
Use um sniffer de rede para identificar a origem que envia os pacotes incorretos. Em seguida, resolva o problema com o aplicativo ou o dispositivo de origem.
Desabilite as verificações de erro da Camada 3 no hardware do switch para:
Erros de checksum de pacotes
Erros de comprimento de pacotes
Pacotes que tiverem os mesmos endereços IP de origem e de destino
Use o comando no mls verify parar estas verificações de erro, como mostram estes exemplos:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
O switch informa esta mensagem de erro:
EARL_NETFLOW-4-TCAM_THRLD: limite de TCAM de Netflow excedido, Utilização de TCAM [[dec]%]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Aug 24 12:30:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%] Aug 24 12:31:53: %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM Utilization [97%]
Observação: se você quiser filtrar essa mensagem de erro específica, saiba que todas as mensagens de erro com o mesmo nível de gravidade serão filtradas. Uma mensagem de registro específica não pode ser filtrada sem afetar outros registros abaixo, que estão sob o mesmo nível de seriedade.
Esta mensagem indica que a memória endereçável por conteúdo ternário (TCAM) de Netflow está quase cheia. O envelhecimento agressivo será habilitado temporariamente. Se você alterar a máscara de Netflow para o modo FULL, a TCAM para Netflow poderá estourar devido a muitas entradas. Execute o comando show mls netflow ip count para verificar essa informação.
O Supervisor Engine 720 verifica i quão cheia está uma tabela de Netflow a cada 30 segundos. O Supervisor Engine ativa o envelhecimento agressivo quando o tamanho da tabela atinge quase 90%. A ideia atrás do envelhecimento agressivo é que a tabela está quase cheia, assim, há novos fluxos ativos que não podem ser criados. Portanto, faz sentido envelhecer agressivamente os fluxos menos ativos (ou fluxos inativos) na ordem de tablein para gerar espaço para fluxos mais ativos.
A capacidade para cada tabela de Netflow de placa de recurso de política (PFC) (IPv4), para PFC3a e PFC3b, é 128.000 fluxos. Para a PFC3bXL, a capacidade é 256.000 fluxos.
Para evitar esse problema, desabilite o modo FULL NetFlow. Execute o comando no mls flow ip.
Observação: Geralmente, o comando no mls flow ip não afeta o encaminhamento de pacotes porque o TCAM para encaminhamento de pacotes e o TCAM para contabilização do NetFlow são separados.
Para se recuperar deste problema, habilite o envelhecimento rápido MLS. Ao habilitar o tempo de envelhecimento rápido MLS, defina inicialmente o valor como 128 segundos. Se o tamanho do cache MLS continuar a crescer acima de 32 entradas K, diminua a configuração até que o tamanho do cache permaneça menor que 32 K. Se o cache continuar a crescer acima de 32 entradas, diminua o tempo de envelhecimento MLS normal. Qualquer valor de tempo de envelhecimento que não seja um múltiplo de 8 segundos será ajustado para o múltiplo mais próximo de 8 segundos.
Switch#configure terminal Switch(config)#mls aging fast threshold 64 time 30
Outra solução alternativa seria desabilitar o serviço interno, se estiver habilitado, e remover mls flow ip interface-full caso você não precise de um fluxo completo.
Switch(config)#no service internal Switch(config)#mls flow ip interface-full
O switch informa esta mensagem de erro e a porta é forçada para linkdown:
%ETHCNTR-3-LOOP_BACK_DETECTED : Loopback de pacote de manutenção de atividade detectado em [chars]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Oct 2 10:40:13: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected on GigabitEthernet0/1 Oct 2 10:40:13: %PM-4-ERR_DISABLE: loopback error detected on Gi0/1, putting Gi0/1 in err-disable state
O problema ocorre porque o pacote keepalive é retornado à porta que enviou o keepalive. Os keepalives são enviados nos Catalyst Switches para impedir loops na rede. Os keepalives são permitidos por padrão em todas as interfaces. Esse problema é observado no dispositivo que detecta e interrompe o loop, mas não no dispositivo que causa o loop.
Execute o comando de interface no keepalive para desabilitar keepalives. Desabilitar o keepalive evita errdisablement da interface, mas não remove o loop.
Observação: nas versões baseadas no Cisco IOS Software Release 12.2(x)SE e posteriores, os keepalives não são enviados em interfaces de fibra e uplink por padrão.
O switch informa esta mensagem de erro:
loadprog: erro - na inicialização aberta do arquivo: não é possível carregar "bootflash:c6msfc2-boot-mz.121-8a.EX"
O problema ocorre somente em uma gravação desalinhada no dispositivo próxima a um limite de 64 bytes interno. O problema pode ocorrer sob uma destas circunstâncias:
Durante a gravação de um arquivo de despejo de falhas
Algo faz com que o sistema falhe no momento da gravação do arquivo.
Quando o código está corrompido durante a migração do CatOS para o Cisco IOS Software
A solução alternativa é modificar o driver de dispositivo de modo que ele processe corretamente o acesso desalinhado. Se o erro ocorre devido a um corrompimento do código durante a migração do CatOS para o Cisco IOS Software, apague a Flash e baixe uma nova imagem válida do CatOS Software.
O switch informa esta mensagem de erro:
%L3_ASIC-DFC3-4-ERR_INTRPT: Ocorreu uma interrupção TF_INT:FI_DATA_INT no EARL %Layer 3 ASIC
Esta mensagem de erro indica que há um erro na Camada 3 (L3) que encaminha circuitos integrados para aplicações específicas (ASIC). Basicamente, o switch mostra essa mensagem quando algum tráfego transiente passa através do ASIC e o software informa simplesmente a ocorrência de uma condição de interrupção. Assim que essa condição for atendida, os contadores que o comando show earl statistics mostra aumentam. Cada vez o software tentar se recuperar de tal estado, o switch gerará essa mensagem do syslog. Geralmente, essa mensagem é informativa se sua ocorrência permanecer baixa. Entretanto, se a mensagem de erro ocorrer frequentemente, talvez haja um problema com o hardware.
Verifique os valores dos contadores na saída do comando show earl statistics. Se os contadores aumentarem rapidamente, isso indica um possível problema com o hardware.
O switch informa esta mensagem de erro:
%MLS_STAT-SP-4-IP_LEN_ERR: inconsistências no comprimento de MAC/IP
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
May 29 21:54:14 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies May 29 23:10:44 JST: %MLS_STAT-SP-4-IP_LEN_ERR: MAC/IP length inconsistencies
Estas mensagens indicam que pacotes onde o comprimento do IP não corresponde ao comprimento do MAC foram recebidos. O Supervisor Engine descartou esses pacotes. Não há nenhum efeito negativo no switch porque ele descarta os pacotes. O switch informa a mensagem para fins informativos. A causa do problema é um dispositivo na rede que envia pacotes ruins. Estes problemas, entre outros, podem causar os pacotes ruins:
NICs com falhas
Drivers de NICs com falhas
Aplicativos com falhas
Use um sniffer de rede para localizar a origem que envia os pacotes incorretos. Em seguida, resolva o problema com o aplicativo ou o dispositivo de origem.
A solução alternativa é utilizar uma configuração de switch que interrompa as verificações do switch para:
Erros de checksum de pacotes
Erros de comprimento de pacotes
Pacotes que tiverem os mesmos endereços IP de origem e de destino
Use estes comandos para interromper as verificações do switch:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet checksum errors.
Switch(config)#no mls verify ip length !--- This configures the switch to discontinue checks for packet length errors.
Switch(config)#no mls verify ip same-address !--- This configures the switch to discontinue checks for packets that have the
!--- same source and destination IP addresses.
O switch informa esta mensagem de erro:
%MLS_STAT-SP-4-IP_CSUM_ERR: erros de soma de verificação IP
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Jan 20 12:48:52: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors Jan 20 14:49:53: %MLS_STAT-SP-4-IP_CSUM_ERR: IP checksum errors
Estas mensagens indicam que o switch recebe pacotes IP com um valor de checksum inválido. Não há nenhum efeito negativo no switch porque ele descarta os pacotes. O switch informa a mensagem para fins informativos. A causa do problema é um dispositivo na rede que envia pacotes ruins. Estes problemas, entre outros, podem causar os pacotes ruins:
NICs com falhas
Drivers de NICs com falhas
Aplicativos com falhas
Como uma solução alternativa, use uma destas duas opções:
Use um sniffer de rede para identificar a origem que envia os pacotes incorretos. Em seguida, resolva o problema com o aplicativo ou o dispositivo de origem.
Desabilite as verificações de erro da Camada 3 no hardware do switch para ambos:
Erros de checksum de pacotes
Erros de comprimento de pacotes
Para interromper essas verificações de erro, use o comando no mls verify, como estes exemplos mostram:
Switch(config)#no mls verify ip checksum !--- This configures the switch to discontinue checks for packet
!--- checksum errors.
Switch(config)#no mls verify ip length {consistent | minimum} !--- This configures the switch to discontinue checks for packet
!--- length errors.
O switch informa esta mensagem de erro:
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK:
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%MCAST-SP-6-ADDRESS_ALIASING_FALLBACK: Address Aliasing detected for group 0100.5e00.0001 on vlan 632 from possible source ip 10.158.132.185 source mac 0000.bea6.82e0
Esta mensagem indica que o switch recebe o tráfego multicast excessivo que é destinado a um endereço MAC multicast no intervalo 01-00-5e-00-00-xx. Este intervalo de multicast é reservado para o tráfego de controle do Internet Group Management Protocol (IGMP), por exemplo:
Folhas
Junções
Consultas gerais
A CPU do switch normalmente processa todo o tráfego de controle IGMP. Portanto, o Cisco IOS Software fornece um mecanismo para ignorar o tráfego multicast IGMP excessivo que é destinado a endereços reservados. O mecanismo garante que a CPU não seja sobrecarregada. O uso desse mecanismo é referido como "modo de fallback".
Localize a origem do tráfego multicast ilegal. Em seguida, interrompa a transmissão ou modifique as características do fluxo de forma que a transmissão não mais recaia sobre o espaço de dados de controle IGMP. Além disso, use a mensagem de erro na seção Problema, a qual fornece a possível origem de rede que causa o problema.
O switch informa esta mensagem de erro:
c6k_pwr_get_fru_present(): não é possível encontrar fru_info para fru tipo 6, #
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #38 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43 Mar 10 08:30:53: SP: c6k_pwr_get_fru_present(): can't find fru_info for fru type 6, #43
Esta mensagem de erro é exibida devido a uma resposta incorreta do switch ao polling Simple Network Management Protocol (SNMP) dos adaptadores de porta que os módulos de WAN Flex usam. Essa mensagem de erro é cosmética por natureza, e não há problemas de desempenho prejudiciais ao switch. O problema está corrigido nestes releases:
Cisco IOS Software Release 12.1(11b)E4
Cisco IOS Software Release 12.1(12c)E1
Cisco IOS Software Release 12.1(13)E
Cisco IOS Software Release 12.1(13)EC
Releases posteriores
O switch informa esta mensagem de erro:
%MROUTE-3-TWHEEL_DELAY_ERR:
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%MROUTE-3-TWHEEL_DELAY_ERR: Exceeded maximum delay (240000 ms) requested: 7200000
Esta mensagem é exibida quando o switch recebe pacotes join/prune de Protocol Independent Multicast (PIM) que anunciam um valor de tempo de retenção alto. Os pacotes anunciam um valor de tempo de retenção mais alto do que o atraso máximo que o sistema operacional do switch permite, que é 4 minutos. Esses são pacotes de controle de multicast, como PIM, Distance Vector Multicast Routing Protocol (DVMRP) e os outros tipos.
releases posteriores do Cisco IOS Software para o Catalyst 6500/6000 aumentaram este atraso máximo para 65.535 segundos, ou aproximadamente 17 minutos. O problema está corrigido nestes releases:
Cisco IOS Software Release 12.1(12c)E
Cisco IOS Software Release 12.2(12)T01
Cisco IOS Software Release 12.1(13)E
Cisco IOS Software Release 12.1(13)EC
Releases posteriores
Configure o dispositivo de terceiro que gera os pacotes de PIM para utilizar temporizadores recomendados pelos padrões do protocolo.
O switch informa esta mensagem de erro:
%MCAST-SP-6-GC_LIMIT_EXCEEDED
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what=allowed (13000)
Esta mensagem de erro será registrada quando a função de snooping IGMP no switch tiver criado o número máximo de entradas permitidas da Camada 2 (L2). O número máximo padrão de entradas L2 que o switch pode criar para grupos de multicast é 15.488. Em versões posteriores do Cisco IOS Software, somente as entradas de multicast da L2 instaladas por hardware contam para o limite. Consulte o bug da Cisco ID CSCdx41473 ( somente clientes registrados) para obter mais detalhes. O problema é corrigido no Cisco IOS Software Release 12.1(13)E1 e posterior.
Você pode aumentar o limite de L2 manualmente. Execute o comando ip igmp l2-entry-limit.
O switch informa esta mensagem de erro:
%MISTRAL-SP-3-ERROR: Condição de erro detectada: TM_NPP_PARITY_ERROR
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Apr 19 22:14:18.237 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:14:25.050 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Apr 19 22:15:20.171 EDT: %MISTRAL-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
Esta mensagem de erro indica que havia um erro de paridade no ponteiro da próxima página do gerenciador de tabelas internas. Se o switch executar o Cisco IOS Software Release 12.1(8)E ou posterior, ele detectará o erro de paridade e redefinirá o Mistral ASIC. Em seguida, o switch poderá continuar, sem a necessidade de recarregar. Uma descarga estática aleatória ou outros fatores externos podem causar o erro de paridade de memória. Se a mensagem de erro for exibida somente uma vez ou raramente, monitore o syslog do switch para confirmar se a mensagem de erro é um incidente isolado. Se essas mensagens de erro ocorrerem novamente, crie uma solicitação de serviço ao Suporte Técnico da Cisco.
O switch informa esta mensagem de erro:
%MLS_STAT-4-IP_TOO_SHRT: pacotes IP muito curtos recebidos
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
*Apr 1 10:30:35 EST: %MLS_STAT-SP-4-IP_TOO_SHRT: Too short IP packets received
A mensagem indica que o mecanismo de encaminhamento do switch recebe um pacote IP de um comprimento mais curto que o comprimento mínimo permitido. O switch descarta o pacote. Em versões anteriores, o pacote é descartado silenciosamente e contabilizado nas estatísticas do mecanismo de encaminhamento. Isto se aplica às releases do software anteriores à versão 7.x ou anteriores ao Cisco IOS Software Release 12.1(13E). Nas releases do software posteriores à versão 7.x ou posteriores ao Cisco IOS Software Release 12.1(13E), a mensagem é gravada no syslog uma vez a cada 30 minutos.
Isso não afeta o lado do Switch. O switch descarta o pacote ruim, que o dispositivo receptor também descartaria. A única preocupação é que há um dispositivo que está enviando pacotes incorretos. As causas possíveis incluem:
Um driver de NIC com falha
Um bug de driver de NIC
Um aplicativo com falha
Devido às limitações do hardware, o Supervisor Engine não registra o IP, o endereço MAC ou a porta de origem do dispositivo que envia os pacotes ruins. Você deve utilizar um aplicativo de sniffing de pacotes para detectar esses dispositivos e rastrear o endereço de origem.
A mensagem na seção Problema é simplesmente um aviso/uma mensagem informativa do switch. A mensagem não fornece qualquer informação sobre a porta de origem, o endereço MAC ou o endereço IP.
Use um aplicativo de sniffing de pacotes dentro da rede. Tente desligar algumas interfaces ou remova algum dispositivo da rede para determinar se você pode isolar o dispositivo com defeito.
O switch informa esta mensagem de erro:
Processor [number] of module in slot [number] cannot service session requests
Este erro ocorre quando você executa o comando session slot number processor number em uma tentativa de estabelecer uma sessão nestas situações:
Você tenta estabelecer uma sessão para um módulo no qual uma sessão já foi estabelecida ao fazer login no switch.
Você tenta estabelecer uma sessão para um módulo indisponível no slot.
Você tenta estabelecer uma sessão para um processador indisponível no módulo.
O switch informa esta mensagem de erro:
%PM_SCP-1-LCP_FW_ERR: módulo de redefinição do sistema [dec] para se recuperar do erro: [chars]
Estes exemplos mostram as saídas do console que são exibidas quando este problema ocorre:
%PM_SCP-SP-1-LCP_FW_ERR: o sistema redefiniu o módulo 13 para se recuperar do erro: exceção de sistema recebida na placa de linha
or
%PM_SCP-SP-1-LCP_FW_ERR: Sistema redefinindo o módulo 4 para recuperar-se do erro: Erro de paridade de Pb Rx da bobina - Porta #14
A mensagem indica que o firmware do módulo especificado detectou um erro. O sistema redefine automaticamente o módulo para recuperar do erro. [dec] é o número de módulo e [chars] é o erro.
Reposicione o módulo ou o coloque em um slot diferente e permita que o módulo passe pelo teste de diagnóstico de inicialização completo. Para obter mais informações sobre diagnósticos online nos Catalyst 6500 Series Switches, consulte Configurando Diagnósticos Online. Após o teste de diagnóstico do módulo, monitore a recorrência da mensagem de erro. Se o erro ocorrer novamente ou se o teste de diagnóstico detectar quaisquer problemas, crie uma solicitação de serviço ao Suporte Técnico da Cisco para obter troubleshooting adicional.
O switch informa esta mensagem de erro:
%PM_SCP-2-LCP_FW_ERR_INFORM: o módulo [dec] está apresentando o seguinte erro: [chars]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: o Módulo 4 está apresentando o seguinte erro: Bus Asic #0 erro Pb transitório
O módulo relata uma condição de erro, onde [dec] é o número do módulo e [chars] é o erro. Essa condição é geralmente causada por uma placa de linha colocada incorretamente ou uma falha de hardware. Se a mensagem de erro for vista em todas as placas de linha, a causa é um módulo encaixado incorretamente.
Recoloque e reinicialize a placa de linha ou o módulo. Em seguida, emita o comando show diagnostic result module module_#."
Se a mensagem de erro persistir após a redefinição do módulo, crie uma solicitação de serviço ao Suporte Técnico da Cisco para obter troubleshooting adicional.
O switch informa esta mensagem de erro:
%PM_SCP-SP-2-LCP_FW_ERR_INFORM: o Módulo 4 está apresentando o seguinte erro: erro de Pb TX transitório de #36 de porta
Essa mensagem de erro indica um erro transitório no módulo número 4 no caminho de dados da porta 36. Na maioria dos casos, esse é um problema ocasional/transitório.
Feche e desligue a porta Gi4/36 e monitore a recorrência do problema.
Se o erro ocorrer novamente, defina o diagnóstico como concluído com o comando diagnostic bootup level complete. Em seguida, recoloque fisicamente a placa de linha.
Se a mensagem de erro persistir após a recolocação do módulo, crie uma solicitação de serviço ao Suporte Técnico da Cisco para Troubleshooting adicional com estas saídas de comando:
O switch informa esta mensagem de erro:
%PM_SCP-SP-4-UNK_OPCODE: mensagem não solicitada desconhecida recebida do módulo [dec], opcode [hex]
Estes exemplos mostram as saídas do console que são exibidas quando este problema ocorre:
Dez 10 12:44:18.117: %PM_SCP-SP-4-UNK_OPCODE: Mensagem não solicitada desconhecida recebida do módulo 2, opcode 0x330
or
Dez 10 12:44:25.210: %PM_SCP-SP-4-UNK_OPCODE: Mensagem não solicitada desconhecida recebida do módulo 2, opcode 0x114
Esta mensagem de erro indica simplesmente que o Supervisor Engine não compreende a mensagem do controle da placa de linha devido a recursos sem suporte pela Cisco IOS Software Release do switch.
As placas de linha enviam mensagens de controle para o Supervisor Engine ativo que indicam os recursos aos quais o software oferece suporte. Entretanto, se o software não oferecer suporte a qualquer um dos recursos da placa de linha, essas mensagens de controle não serão reconhecidas e a mensagem de erro será exibida. Esta mensagem é uma ocorrência inofensiva e não afeta funções no Supervisor Engine ou nas placas de linha.
Atualize o software do Supervisor Engine para a versão mais recente que possui o maior suporte a recursos . Como essa mensagem de erro não afeta a produção ou o tráfego, você pode ignorá-la.
O switch informa esta mensagem de erro:
%PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM: falha na verificação de integridade do transceptor na porta 5/2 da LAN: chave incorreta
A razão para essa mensagem de erro é o uso de GBIC SFP não Cisco, que não é suportado.
Os Cisco SFP GBICs têm um código criptografado exclusivo (ID de qualidade) que permite que o Cisco IOS/CAT OS identifique as peças conectáveis da Cisco. Os GBICs normais não têm isso e, portanto, podem funcionar. Consulte %PM_SCP-SP-3-TRANSCEIVER_BAD_EEPROM para obter mais informações.
O switch informa esta mensagem de erro:
%PM_SCP-SP-3-LCP_FW_ABLC: mensagem de colisão atrasada do módulo 3, porta:035
Late Collisions - uma colisão tardia ocorre quando dois dispositivos transmitem ao mesmo tempo e nenhum dos lados da conexão detecta uma colisão. A razão para essa ocorrência é que o tempo de propagação do sinal de uma extremidade de rede para a outra ser mais longo que o tempo para colocar o pacote inteiro na rede. Os dois dispositivos que causam a colisão atrasada nunca vêem que o outro está enviando até que ele coloque todo o pacote na rede. As colisões posteriores não são detectadas pelo transmissor antes do tempo de slot de 64 bytes. Isso ocorre porque elas são detectadas somente nas transmissões de pacotes maiores que 64 bytes.
Possíveis causas - colisões tardias são resultado de incompatibilidade duplex, cabeamento incorreto ou um número não compatível de hubs na rede. As placas de rede com falha também podem causar colisões posteriores.
O switch informa esta mensagem de erro:
%PM-3-INVALID_BRIDGE_PORT: Bridge Port number is out of range
Esse problema parece superficial e ocorre devido a uma pesquisa SNMP do mib dot1dTpFdbEntry.
Você pode bloquear o OID para que ele não seja interrogado neste dispositivo. Esse defeito foi corrigido no Cisco IOS versão 12.2(33)SRD04 e posterior.
O switch informa esta mensagem de erro:
%QM-4-TCAM_ENTRY: capacidade de entrada TCAM de hardware excedida
A TCAM é uma peça especializada de memória projetada para consultas rápidas a tabelas pela ACL e pelos mecanismos de QoS. Esta mensagem indica a exaustão dos recursos de TCAM e do switching de software dos pacotes. Isso significa que cada interface possui sua própria ID na TCAM e assim usa mais recursos de TCAM. Provavelmente, esse problema é causado pela presença do comando mls qos marking statistics ou quando a TCAM do hardware não tem a capacidade de processar todas as ACLs configuradas.
Desabilite o comando mls qos marking statistics, pois ele está habilitado por padrão.
Tente compartilhar as mesmas ACLs através de várias interfaces para reduzir a contenção de recursos da TCAM.
O switch informa esta mensagem de erro:
%slot_earl_icc_shim_addr: Slot [num] não é nem SuperCard nem Supervisor - Slot inválido
Esta mensagem ocorre quando um Gerenciador SNMP sonda dados de TCAM de uma placa de linha que não possui nenhuma informação de TCAM. Isso ocorrerá somente para uma placa de linha em um Catalyst 6500 Switch com o Cisco IOS Software. Se a placa de linha possuir informações de TCAM durante o polling SNMP, os dados serão fornecidos ao sistema de gerenciamento de rede (NMS) para processamento adicional. Consulte o bug da Cisco ID CSCec39383 ( somente clientes registrados) para obter mais detalhes. Este problema é corrigido no Cisco IOS Software Release 12.2(18).
Como uma solução alternativa, você pode bloquear a consulta dos dados da TCAM pelos NMS. O objeto MIB que fornece dados de uso da TCAM é cseTcamUsageTable. Execute estes passos no roteador para evitar o retornos de rastreamento:
Execute o comando snmp-server view tcamBlock cseTcamUsageTable excluded.
Execute o comando snmp-server view tcamBlock iso included.
Execute o comando snmp-server community public view tcamBlock ro.
Execute o comando snmp-server community private view tcamBlock rw.
O switch informa esta mensagem de erro:
%SYSTEM_CONTROLLER-SP-3-ERROR: Condição de erro detectada: TM_NPP_PARITY_ERROR
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
Feb 23 21:55:00: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 22:51:32: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR Feb 23 23:59:01: %SYSTEM_CONTROLLER-SP-3-ERROR: Error condition detected: TM_NPP_PARITY_ERROR
A maioria dos erros comuns do Mistral ASIC na MSFC são TM_DATA_PARITY_ERROR, SYSDRAM_PARITY_ERROR, SYSAD_PARITY_ERROR e TM_NPP_PARITY_ERROR. As causas possíveis desses erros de paridade são descarga estática aleatória ou outros fatores externos. Esta mensagem de erro indica que havia um erro de paridade. Os PMPEs (Processor Memory Parity Errors, Erros de Paridade de Memória do Processador) são divididos em dois tipos: SEU (single event transe, conjunto único de eventos) e erros repetidos.
Esses erros de bit único ocorrem quando um bit em uma palavra de dados é alterado de forma inesperada devido a eventos externos (que fazem, por exemplo, um zero mudar espontaneamente para um). Os SEUs são um fenômeno universal independentemente do fornecedor ou da tecnologia. Os SEUs ocorrem muito raramente, mas todos os computadores e sistemas de rede, mesmo um PC, estão sujeitos a eles. Os SEUs também são chamados de erros de software, que são causados por ruídos e geram um erro inconsistente e transitório nos dados não relacionado a uma falha de componente - mais frequentemente resultante de radiação cósmica.
Os erros repetidos (referidos frequentemente como erros físicos) são causados por componentes com defeitos. Um erro físico é causado por um componente com defeito ou por um problema no nível de placa, como uma placa de circuito impresso fabricada incorretamente, gerando ocorrências repetidas do mesmo erro.
Se a mensagem de erro for exibida somente uma vez ou raramente, monitore o syslog do switch para confirmar se a mensagem de erro é um incidente isolado. Se essas mensagens de erro ocorrerem novamente, reinstale o blade do Supervisor Engine. Se o erro cessar, ele era um erro de paridade física. Se esses mensagens de erro continuarem a ocorrer, abra um caso no Centro de Assistência Técnica.
O switch informa esta mensagem de erro:
%SYSTEM_CONTROLLER-SW2_SPSTBY-3-ERROR: Condição de erro detectada: TM_NPP_PARITY_ERROR
Essa mensagem de erro indica que houve um erro de paridade e as possíveis causas são uma descarga estática aleatória ou outros fatores externos, que causam o erro de paridade de memória, como uma conectividade transitória no painel traseiro, ou podem ocorrer devido a problemas de energia e, às vezes, a placa de linha não consegue acessar o conteúdo da PROM serial (SPROM) no módulo para determinar a identificação da placa de linha.
Todos os sistemas de computadores e de rede são susceptíveis à rara ocorrência de Single Event Upsets (SEU), às vezes descritos como erros de paridade. Esses erros de bit único ocorrem quando um bit em uma palavra de dados muda inesperadamente devido a eventos externos e, portanto, faz com que, por exemplo, um zero se altere espontaneamente para um um. Os SEUs são um fenômeno universal, independentemente do fornecedor e da tecnologia. Os SEUs ocorrem muito raramente, mas todos os computadores e sistemas de rede, mesmo um PC, estão sujeitos a eles. Os SEUs também são chamados de erros de software, que são causados por ruído e resultam em um erro transitório e inconsistente nos dados, e não estão relacionados a uma falha de componente.
Erros repetidos, frequentemente chamados de erros de hardware, são causados por componentes com falha. Um erro de hardware é causado por um componente com defeito ou por um problema na placa, como uma placa de circuito impresso fabricada incorretamente, que resulta em ocorrências repetidas do mesmo erro.
Se essas mensagens de erro ocorrerem novamente, recoloque o módulo do supervisor durante a janela de manutenção.
O switch informa esta mensagem de erro:
SP: O endpoint da placa de linha do Canal 14 perdeu Sincronização para Malha inferior e está tentando se recuperar agora!
Geralmente, a mensagem de erro indica uma placa de linha mal encaixada. Na maioria dos casos, você pode reencaixar a placa de linha fisicamente para solucionar esse problema Em alguns casos, o módulo está defeituoso.
Execute o comando show fabric fpoe map para identificar o módulo que causa essa mensagem de erro.
Switch#configure terminal Switch(config)#service internal Switch(config)#end Switch#show fabric fpoe map Switch#configure terminal Switch(config)#no service internal Switch(config)#end
Este exemplo é o resultado do comando show fabric fpoe map. Na saída, você pode identificar que o módulo no slot 12 causa a mensagem de erro.
switch#show fabric fpoe map slot channel fpoe 12 0 14 << There are also related errors in "show fabric channel-counters" : slot channel rxErrors txErrors txDrops lbusDrops 1 0 1 0 0 0 2 0 16 0 0 0 3 0 16 0 0 0
Reencaixe o módulo que causa a mensagem de erro.
Quando um Cisco Catalyst 6000/6500 é inicializado, ele pode emitir uma mensagem de erro semelhante:
%SYSTEM-1-INITFAIL: Network boot is not supported. Invalid device specified Booting from default device Initializing ATA monitor library... monlib.open(): Open Error = -13 loadprog: error - on file open boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
Esse erro mais ocorre quando as variáveis de inicialização não estão configurados corretamente para inicializar o switch de um dispositivo flash válido.
Na ilustração, observe a última linha da mensagem:
boot: cannot load "bootdisk:s72033-ipservicesk9-mz.122-18.SXF7.bin"
O nome do dispositivo flash mencionado é bootdisk, e a primeira parte do nome de arquivo do IOS, s72033 observa que o IOS destina-se ao módulo Supervisor 720. O módulo Supervisor 720 não possui nem oferece suporte a um dispositivo flash chamado bootdisk. Como o módulo Supervisor 720 não possui uma flash local com esse nome, o switch pensa que você deseja inicializar da rede. Dessa forma, ele exibe a mensagem de erro.
Configure a variável de inicialização com o nome do dispositivo flash correto e um nome de arquivo de software válido.
Estes dispositivos flash possuem suporte em módulos Supervisor:
Supervisor Engine 1 e Supervisor Engine 2
Nome do Dispositivo Flash | Descrição |
---|---|
flash de inicialização: | Memória flash onboard |
slot0: | Placa Linear Flash PC (slot PCMCIA) |
disk0: | Placa ATA Flash PC (slot PCMCIA) |
Supervisor Engine 720
Nome do Dispositivo Flash | Descrição |
---|---|
flash de inicialização: | Memória flash onboard |
disk0: | Placa CompactFlash Type II somente (slot do disco 0) |
disk1: | Placa CompactFlash Type II (slot do disco 1) |
Supervisor Engine 32
Nome do Dispositivo Flash | Descrição |
---|---|
disco de inicialização: | Memória flash onboard |
disk0: | Placa CompactFlash Type II somente (slot do disco 0) |
Se isso não solucionar o problema, consulte Recuperando um Catalyst 6500/6000 com Cisco IOS System Software de uma Imagem de Carregador de Inicialização Ausente ou Corrompida ou Modo ROMmon.
O switch informa estas mensagens de erro:
CPU_MONITOR-3-TIMED_OUT: CPU monitor messages have failed, resetting system CPU_MONITOR-6-NOT_HEARD: CPU monitor messages have not been heard for [dec] seconds
Estas mensagens indicam que as mensagens do monitor de CPU não foram ouvidas durante um tempo significativo. O tempo limite provavelmente será esgotado, o que redefinirá o sistema. [dec] é o número de segundos.
O problema possivelmente ocorre devido a estes motivos:
Placa de linha ou módulo mal encaixado
ASIC ou backplane ruim
Bugs de software
Erro de paridade
Alto tráfego no EOBC (Ethernet out-of-band channel)
O canal EOBC é um canal half-duplex que serve muitas funções, que incluem tráfego e pacotes Simple Network Management Protocol (SNMP) que destinam-se ao switch. Se o canal EOBC estiver cheio de mensagens devido a uma tempestade de tráfego SNMP, o canal estará sujeito a colisões. Quando isso ocorrer, possivelmente o EOBC não poderá conduzir mensagens IPC. Isso faz o switch exibir a mensagem de erro.
Reencaixe a placa de linha ou o módulo. Se uma janela de manutenção puder ser agendada, redefina o switch para eliminar problemas temporários.
A mensagem de erro %Invalid IDPROM image for linecard é recebida nos Catalyst 6500 Series Switches com software de sistema Cisco IOS.
A mensagem de erro pode ser semelhante a estas:
% Invalid IDPROM image for daughterboard 1 in slot 4 (error = 4) % Invalid IDPROM image for linecard in slot 5 (error = 4) % Invalid IDPROM image for daughterboard 1 in slot 5 (error = 4)
Este erro indica que as placas de linha instaladas não foram inicializadas corretamente porque o supervisor gerou um sinal ruim no barramento de controle. Em alguns cenários, observa-se que o encaixe incorreto também pode fazer com que o supervisor ou as placas de linha não sejam reconhecidos no chassi Cat6500. Consulte o bug da Cisco ID CSCdz65855 ( somente clientes registrados) para obter mais informações.
Se a instalação do supervisor redundante estiver disponível, execute um switchover forçado e encaixe o supervisor ativo original.
Se ela for uma instalação de supervisor única, agende um tempo de inatividade e execute estes passos:
Mova o módulo do supervisor para outro slot.
Reencaixe todas as placas de linha e certifique-se de que estejam colocadas corretamente.
O switch informa estas mensagens de erro:
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0] %CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
O supervisor envia um ping SCP uma vez a cada 2 segundos para cada placa de linha. Se nenhuma resposta for recebida após 3 pings (6 segundos), ela será contada como a primeira falha. Após 25 falhas sucessivas, ou após 150 segundos sem receber uma resposta da placa de linha, o supervisor desliga e liga novamente a placa de linha. Após cada 30 segundos, esta mensagem de erro é vista no switch:
%CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 61 seconds [2/0] %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not been heard for 151 seconds [2/0]
Após 150 segundos, o módulo é desligado e ligado novamente com estes syslogs:
%CPU_MONITOR-SP-3-TIMED_OUT: CPU_MONITOR messages have failed, resetting module [2/0] %OIR-SP-3-PWRCYCLE: Card in module 1, is being power-cycled off (Module not responding to
Keep Alive polling) %OIR-SP-3-PWRCYCLE: Card in module 2, is being power-cycled off (Heartbeat Messages Not
Received From Module)
O switch informa esta mensagem de erro:
%C6KPWR-4-DISABLED: Power to module in slot [dec] set [chars]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%C6KPWR-SP-4-DISABLED: power to module in slot 10 set off (Fabric channel errors) %C6KPWR-SP-4-DISABLED: power to module in slot 2 set off (Module Failed SCP dnld) %C6KPWR-SP-4-DISABLED: power to module in slot 9 set off (Module not responding to Keep
Alive polling)
Esta mensagem indica que o módulo no slot indicado esteve desligado pelo motivo indicado. [dec] é o número do slot e [chars] indica o status de energia.
O switch tem suas vibrações normais e ao longo do tempo elas podem fazer com que um módulo se afaste ligeiramente do back plane. Quando isso ocorre, o polling keepalive dos supervisores não recebe uma resposta do módulo no tempo alocado e o supervisor reinicializa o módulo para tentar obter uma conexão melhor a ele. Se o módulo ainda não responder às sondagens, o supervisor reinicializará continuamente o módulo, eventualmente o colocará em error disable e não permitirá que nenhuma energia chegue a ele.
Um simples reencaixe do módulo corrigirá este problema em 90% das vezes. Se você reencaixar o módulo, ele realinhará o switch fabric e garantirá uma conexão firme ao backplane.
Se o módulo em questão for o Content Switching Module (CSM), considere atualizar o software do CSM para a release 4.1(7) ou posterior. Este problema está documentado no bug da Cisco ID CSCei85928 (sob software do CSM) ( somente clientes registrados) e no bug da Cisco ID CSCek28863 (sob Cisco IOS Software) ( somente clientes registrados) .
O software do CSM mais recente pode ser baixado da página de download de software do Cisco Catalyst 6000 Content Switching Module.
O switch informa a mensagem de erro:
ONLINE-SP-6-INITFAIL: Module [dec]: Failed to [chars]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%ONLINE-SP-6-INITFAIL: Module 5: Failed to synchronize Port asic
A causa da falha é que o Pinnacle ASIC não conseguiu sincronizar. Geralmente, isso é causado geralmente por um contato ruim ou uma placa mal encaixada.
O sistema se recupera sem uma intervenção do usuário. Se a mensagem de erro ocorrer novamente, reencaixe a placa de linha ou o módulo em questão.
O switch informa a mensagem de erro:
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature [chars] for protocol [chars] is unsuccessful, hardware acceleration may be disabled for the feature
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%FM_EARL7-4-FLOW_FEAT_FLOWMASK_REQ_FAIL: Flowmask request for the flow based feature Reflexive ACL for protocol IPv4 is unsuccessful, hardware acceleration may be disabled for the feature
A solicitação da máscara de fluxo para o recurso baseado em fluxo não obteve êxito. Esta condição pode ocorrer devido a uma exceção do recurso TCAM, uma exceção do recurso de registros de máscaras de fluxo, ou a um conflito de máscara de fluxo não resolvido com outros recursos baseados em Netflow. A instalação de atalho e a aceleração de hardware do NetFlow para o recurso podem ser desabilitadas sob esta condição e o recurso pode ser aplicado no software.
Se você possuir somente uma ACL reflexiva de entrada, reflexão e avaliação configuradas na direção de entrada em interfaces diferentes, o requisito flowmask da ACL reflexiva será baseado nas ACLs reflexivas de entrada. Desde que a ACL reflexiva seja configurada em uma interface diferente do policiamento de microfluxo de Qos ou não se sobreponha à ACL de políticas de policiamento de microfluxo, quando estiverem na mesma interface, elas poderão coexistir no hardware. Se elas estiverem na mesma interface e a ACL reflexiva e a política de QoS se sobrepuserem, a ACL reflexiva desabilitará a instalação do atalho de NetFlow e o tráfego correspondente à ACL reflexiva será comutado por software. Isso ocorre devido aos requisitos de flowmask em conflito.
No caso de ACL reflexiva de saída, o requisito flowmask da ACL reflexiva será global em todas as interfaces, pois haverá apenas um Netflow de entrada. Se o policiamento de microfluxo baseado em usuário de QoS for configurado nesse caso, a ACL reflexiva desabilitará a instalação do atalho do NetFlow e o tráfego correspondente à ACL reflexiva será comutado por software.
Execute o comando show fm fie flowmask para determinar o status enable/disable da instalação de atalho do NetFlow para o recurso. A instalação de atalho e a aceleração de hardware do Netflow estão desabilitadas para o recurso. Use somente listas de acesso reflexivas de entrada em conjunto com policiamento de microfluxo e certifique-se de que o policer de microfluxo não se sobreponha à lista de acesso reflexiva. Reaplique o recurso para que a solicitação de máscara de fluxo seja bem-sucedida, e reabilite a instalação de atalho do NetFlow para o recurso.
O switch informa a mensagem de erro:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, [dec]/[dec]; auto reenable in about 2 mins
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%MCAST-2-IGMP_SNOOP_DISABLE:IGMP Snooping disabled due to excessive events/packets, 0/19880; auto reenable in about 2 mins
O snooping IGMP está desabilitado, mas o sistema recebe o tráfego multicast. Essa situação força o direcionamento de pacotes multicast para o processador de rotas e possivelmente o inunda. O snooping IGMP pode ser desabilitado automaticamente devido ao tráfego multicast excessivo. O snooping IGMP basicamente observa estes pacotes de controle que são trocados entre roteadores e hosts, e com base em ingressos, saídas e consultas atualizam quais portas recebem o multicast.
Esta mensagem ocorre normalmente porque o processador de rotas recebe uma taxa muito superior à esperada de pacotes de ingresso IGMP ou pacotes multicast normais destinados aos intervalos de endereços multicast da Camada 3/Camada 2 reservados. Portanto, o switch fica sem recursos e como as mensagens de registro informa, ele atenua e desabilita o snooping IGMP por um período curto.
Você pode habilitar o recurso de limitação de taxa de multicast e definir o limite para um número maior.
A limitação de taxa é um método mais desejável de forma que a fila não se torne saturada. Isso também significa que os pacotes IGMP válidos têm menos chances de serem descartados e, assim, o processo de snooping no switch ainda pode atualizar corretamente.
Execute estes passos para fazer troubleshooting deste problema:
Desabilite o snooping IGMP com o comando no ip igmp snooping.
Configure uma sessão SPAN na interface VLAN de gerenciamento em seu Catalyst 6500 para determinar se o endereço MAC pertence à origem onde o tráfego excessivo é originado.
Consulte a tabela CAM para identificar a origem e removê-la.
Reabilite o snooping IGMP.
O switch informa estas mensagens de erro. A mensagem de erro pode ser de um destes dois tipos:
C6KERRDETECT-2-FIFOCRITLEVEL: System detected an unrecoverable resources error on the
active supervisor pinnacle
C6KERRDETECT-2-FIFOCRITLEVEL: System detected unrecoverable resources error on active
supervisor port-asic
A causa de origem desse erro possivelmente é um módulo defeituoso ou um módulo mal encaixado. também pode ser um problema de chassi neste slot específico. Isso pode ser transitório se for devido a um módulo mal encaixado.
Essas mensagens indicam que o sistema detectou recursos irrecuperáveis devido ao problema de First In, First Out [FIFO], no Pinnacle ASIC indicado ou ASIC da porta especificada.
Execute o comando remote command switch show platform hardware asicreg pinnacle slot 1 port 1 err para resolver esse erro e configure o switch para executar testes de hardware aprimorados com estas etapas:
Observação: digite o comando inteiro e pressione a tecla Enter. Você não pode escrever o comando com a tecla Tab.
Execute o comando diagnostic bootup level complete para definir o nível de diagnóstico a ser concluído e salve a configuração.
Reposicione o supervisor e insira-o firmemente
Quando o supervisor estiver online, execute o comando show diagnostic para monitorar o switch e verificar se a mensagem de erro ainda persiste.
O switch informa estas mensagens de erro:
%C6KERRDETECT-SP-4-SWBUSSTALL: o barramento de comutação fica parado por 3 segundos
%C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED: a parada do barramento de switching é recuperada e a switching do tráfego de dados continua
A mensagem %C6KERRDETECT-SP-4-SWBUSSTALL indica que o barramento de switching está parado e que o tráfego de dados foi perdido.
A mensagem %C6KERRDETECT-SP-4-SWBUSSTALL_RECOVERED indica que o barramento de switching não está mais paralisado e que o tráfego de dados pode continuar.
Basicamente, se algum módulo no barramento do sistema travar, o supervisor detectará um tempo limite e tentará se recuperar sozinho. Se um módulo estava em processo de instalação, essa é uma causa muito possível dessas mensagens, pois isso pode causar uma parada de barramento enquanto o módulo é encaixado no backplane.
Esta mensagem de erro é recebida quando há falha em comandos ping de teste da banda de entrada devido à alta utilização da CPU:
SP-RP Ping Test[7]: Test skipped due to high traffic/CPU utilization
O ping de banda de entrada SP-RP é um teste de diagnóstico online e a mensagem de falha de teste de ping SP-RP é puramente informativa. Ele é indicativa de alta utilização da CPU e pode ser o resultado de muito tráfego transmitido ao processador de rotas ou do fluxo de tráfego de switching para o processador do switch. Isso também pode ocorrer durante atualizações de rota. É normal que a CPU do processador de rotas seja utilizada até 100% algumas vezes.
A mensagem de erro é puramente informativa e não possui nenhum impacto no desempenho do dispositivo.
O switch informa esta mensagem de erro:
%SW_VLAN-4-MAX_SUB_INT : The number of sub-interfaces allocated for interface [chars] has exceeded recommended limits of [dec]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%SW_VLAN-4-MAX_SUB_INT: The number of sub-interfaces allocated for interface Gi1/1 has exceeded recommended limits of 1000
The number of Layer 3 sub-interfaces is limited by the internal VLANs in the switch. O Catalyst 6500 Series possui 4094 VLANs que são utilizadas para várias finalidades. Execute o comando show platform hardware capacity vlan para saber a disponibilidade da VLAN do status atual.
Switch#show platform hardware capacity vlan VLAN Resources VLANs: 4094 total, 9 VTP, 0 extended, 17 internal, 4068 free
O limite recomendado de subinterfaces é 1000 para cada interface e 2000 para cada módulo. Reduza o número de subinterfaces alocadas para a interface, pois o limite recomendado foi excedido.
Observação: o console pode ser bloqueado devido à inundação dessas mensagens exibidas na recarga do switch. Esse problema está documento no bug da Cisco ID CSCek73741 ( somente clientes registrados) e ele está resolvido nos Cisco IOS Software Releases 12.2(18)SXF10 e Cisco IOS Software Releases 12.2(33)SXH ou posterior.
O switch informa esta mensagem de erro:
MCAST-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: ([enet],[dec])->[hex] Protocol :[dec] Error:[dec]
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%MCAST-SP-6-L2_HASH_BUCKET_COLLISION: Failure installing (G,C)->index: (0100.5e31.d522,802)->0xDA4 Protocol :0 Error:3
Esta mensagem de erro é normalmente vista junto com esta mensagem:
%MCAST-SP-6-GC_LIMIT_EXCEEDED: IGMP snooping was trying to allocate more Layer 2 entries than what allowed (15488)
Esta mensagem indica que uma entrada da Camada 2 não foi instalada no hardware porque não há espaço suficiente no recipiente de hash. Os pacotes multicast são inundados na VLAN de entrada porque a instalação da entrada da Camada 2 falhou. Quando o limite é excedido, a inundação ocorre para os MACs de grupo adicionais.
Se você não utilizar multicast, o snooping IGMP poderá ser desabilitado. Caso contrário, você pode aumentar o limite de entradas de hash com o uso do comando ip igmp snooping l2-entry-limit.
O switch informa esta mensagem de erro:
%QM-4-AGG_POL_EXCEEDED: QoS Hardware Resources Exceeded : Out of Aggregate policers
Somente um número limitado de policers agregados é aceito. Em switches baseados em EARL7, esse limite é 1023.
Em vez de QoS baseado em porta, você pode configurar QoS baseado em VLAN. Conclua estes passos:
Aplique a política de serviço para cada VLAN configurada na porta de switch da Camada 2.
Remova a política de serviço de cada porta que pertença à VLAN específica.
Configure cada porta de switch da Camada 2 para QoS baseado em VLAN com o comando mls qos vlan-based.
O switch informa esta mensagem de erro:
%EC-SP-5-CANNOT_BUNDLE2: não é compatível com Gi2/1 e será suspenso (MTU de Gi2/2 é 1500, Gi2/1 é 9216)
Essa mensagem de erro indica que o MTU do membro do canal de porta não é o mesmo, portanto, causa falha na adição do canal de porta. Por padrão, todas as interfaces usavam o tamanho de MTU como 1500. Devido à incompatibilidade do valor de MTU, a porta não pode ser adicionada ao canal de porta.
Configure a mesma MTU nessas portas membro.
O switch informa esta mensagem de erro:
%EC-SP-5-CANNOT_BUNDLE2: Gi1/4 não é compatível com Gi6/1 e será suspenso (envio de controle de fluxo de Gi1/4 está desativado, Gi6/1 está ativado)
Essa mensagem de erro indica velocidade ou uma incompatibilidade de controle de fluxo, portanto, a causa é uma falha na adição de canal de porta.
Verifique se a configuração da interface participa do port channel.
O switch informa esta mensagem de erro:
%CFIB-7-CFIB_EXCEPTION: FIB TCAM exception, Some entries will be software switched
A mensagem de erro indica que o número de entradas de rota instaladas está prestes a atingir a capacidade FIB de hardware ou o limite máximo de rotas definido para o protocolo especificado. Se o limite for atingido, alguns prefixos serão descartados.
Recarregue o roteador para sair do modo de exceção. Insira o comando mls cef maximum-routes no modo de configuração global para aumentar o número máximo de rotas para o protocolo. Por padrão, uma PFC3 no SUP tem uma capacidade de 192K entradas, mas se você usar o comando mls cef maximum-routes 239, isso dará uma opção para utilizar o máximo de entradas de TCAM disponíveis. Use o comando show mls cef maximum-routes para verificar as rotas máximas. Use o comando show mls cef summary, que mostra o resumo das informações da tabela CEF, para verificar o uso atual.
Módulo 5 (supervisor) falha no teste de diagnóstico TestMatchCapture como indicado nesta saída de show diagnostic result module module_# :
TestMatchCapture ----------------> F Error code ------------------> 59 (DIAG_L2_INDEX_MISMATCH_ERROR) Total run count -------------> 1 Last test execution time ----> Jun 25 2011 04:49:10 First test failure time -----> Jun 25 2011 04:49:10 Last test failure time ------> Jun 25 2011 04:49:10 Last test pass time ---------> n/a Total failure count ---------> 1 Consecutive failure count ---> 1
O teste TestMatchCapture é uma combinação dos testes TestProtocolMatchChannel e TestCapture como descrito aqui:
TestProtocolMatchChannel - O teste TestProtocolMatchChannel verifica a capacidade de corresponder protocolos específicos da Camada 2 no mecanismo de encaminhamento da Camada 2. Quando você executa o teste no mecanismo de supervisão, o pacote de diagnóstico é enviado da porta inband do mecanismo de supervisão e executa uma pesquisa de pacote com o mecanismo de encaminhamento de Camada 2. Para módulos habilitados para DFC, o pacote de diagnóstico é enviado da porta inband do mecanismo supervisor através da matriz de comutação e é submetido a loopback a partir de uma das portas DFC. O recurso Match é verificado durante a pesquisa de pacotes de diagnóstico pelo mecanismo de encaminhamento de Camada 2.
TestCapture - O teste de TestCapture verifica se o recurso de captura do mecanismo de encaminhamento de Camada 2 está funcionando corretamente. A funcionalidade de captura é usada para replicação multicast. Quando você executa o teste no mecanismo de supervisão, o pacote de diagnóstico é enviado da porta inband do mecanismo de supervisão e executa uma pesquisa de pacote com o mecanismo de encaminhamento de Camada 2. Para módulos habilitados para DFC, o pacote de diagnóstico é enviado da porta inband do mecanismo supervisor através da matriz de comutação e é submetido a loopback a partir de uma das portas DFC. O recurso Capturar é verificado durante a pesquisa de pacotes de diagnóstico pelo mecanismo de encaminhamento de Camada 2.
Recoloque o módulo sempre que tiver uma oportunidade. Como esses são erros menores, eles podem ser ignorados se você não vir nenhum impacto no desempenho.
O switch informa esta mensagem de erro:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port [dec] on module [dec] failed [dec] consecutive times. Disabling the port.
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%CONST_DIAG-SP-3-HM_PORT_ERR: Port 5 on module 2 failed 10 consecutive times. Disabling the port.
A mensagem de erro indica que o caminho de dados que corresponde à porta falhou. A porta é colocada no estado errdisable.
Reinicialize a placa de linha para ver se o problema se resolve sozinho.
O switch informa esta mensagem de erro:
%CONST_DIAG-SP-4-ERROR_COUNTER_WARNING: Module 7 Error counter exceeds threshold, system operation continue. %CONST_DIAG-SP-4-ERROR_COUNTER_DATA: ID:42 IN:0 PO:255 RE:200 RM:255 DV:2 EG:2 CF:10 TF:117
Verifique os resultados do diagnóstico:
TestErrorCounterMonitor ---------> . Error code ------------------> 0 (DIAG_SUCCESS) Total run count -------------> 33658 Last test execution time ----> Apr 15 2012 11:17:46 First test failure time -----> Apr 03 2012 20:11:36 Last test failure time ------> Apr 08 2012 19:24:47 Last test pass time ---------> Apr 15 2012 11:17:46 Total failure count ---------> 5 Consecutive failure count ---> 0 Error Records ---------------> n/a
O TestErrorCounterMonitor monitora os erros/interrupções em cada módulo no sistema sondando periodicamente os contadores de erros mantidos na placa de linha.
Essa mensagem de erro aparece quando um ASIC na placa de linha recebe pacotes com CRC inválido. O problema pode ser local para este módulo ou pode ser acionado por algum outro módulo defeituoso no chassi. Isso também pode ocorrer devido a quadros com CRC inválido recebidos pelo asic de pináculo do DBUS. Ou seja, as mensagens de erro implicam que pacotes ruins estão sendo recebidos pelo barramento no módulo 7.
Uma das razões para as mensagens de erro ocorrerem é a incapacidade do módulo de se comunicar corretamente com o backplane do chassi devido ao encaixe incorreto do módulo. O problema está na placa de linha (módulo mal encaixado), supervisor ou barramento de dados. No entanto, não é possível dizer qual componente está corrompendo os dados e causando um CRC inválido.
Primeiro, recoloque o módulo 7 e verifique se os parafusos estão bem apertados. Além disso, antes de recolocar, defina o diagnóstico como concluído com o comando diagnostic bootup level complete.
Quando a recolocação for concluída, o diagnóstico completo será executado no módulo. Em seguida, você pode confirmar que não há problemas de hardware no módulo 7.
O switch informa esta mensagem de erro:
%SYS-3-PORT_RX_BADCODE:Port [dec]/[chars] detected [dec] bad code errors in last 30 minutes
Este exemplo mostra as saídas do console que são exibidas quando esse problema ocorre:
%SYS-3-PORT_RX_BADCODE: Port 3/43 detected 7602 bad code error(s) in last 30 minutes
Essa mensagem de erro indica que uma porta foi afetada com um erro de protocolo desconhecido. Por exemplo, um switch Catalyst 6500 Series recebe quadros com protocolo que não conhece nem reconhece. O primeiro [dec] é o número do módulo, [chars] é o número da porta e o segundo [dec] é o número de pacotes de entrada com protocolos desconhecidos encontrados nos últimos 30 minutos.
Estas são as possíveis causas da mensagem de erro:
Devido à incompatibilidade de configurações de velocidade e duplex.
O CDP está ativado em uma extremidade e não na outra.
Devido ao DTP, ele é habilitado por padrão nas interfaces do switch. Como os roteadores não entendem o DTP, isso pode causar alguns problemas.
Verifique o contador runts na interface. Se ele aumentar, pode haver uma incompatibilidade duplex nas interfaces.