Switches : Switches Cisco Catalyst 6500 Series

Troubleshooting de Problemas nas Tabelas ARP ou CAM nos Catalyst 6500/6000 Switches

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (29 Julho 2013) | Inglês (27 Outubro 2009) | Feedback

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Informações de Apoio
Troubleshooting de Problemas Relacionados ao ARP ou à CAM
      Perda de Endereços MAC Dinâmicos com o Switching Distribuído
      O CEF Descarta Pacotes em Intervalos Regulares
      O Switch Filtra Endereços MAC Nulos na Tabela CAM
      Inundação de Unicast na Rede a Cada 5 Minutos
      Problemas de ARP no CatOS Híbrido
      Erro EARL-2-EARL4LOOKUPRAMERROR Durante a Pesquisa na Tabela CAM
      Entradas Estáticas da CAM Perdidas Após Switchover de Supervisor
      %ACL-5-TCAMFULL: acl engine TCAM table is full
      Problemas de Ping Ocorrem quando a MSFC Não Responde à Solicitação de ARP nos Catalyst 6500 Series Switches
Discussões relacionadas da comunidade de suporte da Cisco

Introdução

Este documento fornece informações para o troubleshooting de problemas relacionados às tabelas de Address Resolution Protocol (ARP) ou Content Addressable Memory (CAM) nos Catalyst 6500/6000 Switches.

Pré-requisitos

Requisitos

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

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Informações de Apoio

Os switches Catalyst mantêm diversos tipos de tabelas criadas para o switching da Camada 2 ou switching de várias camadas (MLS), e elas são mantidas em memórias muito rápidas para que vários campos em um frame ou pacote possam ser comparados em paralelo.

  • ARP — Mapeia um endereço IP em um endereço MAC para fornecer comunicação de IP em um domínio de broadcast da Camada 2. Por exemplo, o host B deseja enviar informações ao host A, mas não possui o endereço MAC do host A em seu cache de ARP. O host B gera uma mensagem de broadcast para todos os hosts dentro do domínio de broadcast para obter o endereço MAC associado ao endereço IP do host A. Todos os hosts dentro do domínio de broadcast recebem a solicitação de ARP, mas somente o host A a responde com seu endereço MAC.

  • CAM — Todos os modelos de Catalyst Switch usam uma tabela CAM para o switching da Camada 2. À medida que os frames chegam nas portas do switch, os endereços MAC de origem são aprendidos e gravados na tabela CAM. A porta de chegada e a VLAN são gravadas na tabela, juntamente com um registro de data e hora. Se um endereço MAC aprendido em uma porta do switch migrou para uma porta diferente, o endereço MAC e o registro de data e hora são gravados para a porta de chegada mais recente. Em seguida, a entrada anterior é excluída. Se um endereço MAC for identificado como já presente na tabela com a porta de chegada correta, somente seu registro de data e hora será atualizado.

  • Ternary Content Addressable Memory (TCAM) — Nos switches de várias camadas, todos os processos que as listas de controle de acesso (ACL) fornecem no roteamento tradicional, tais como a correspondência, a filtragem ou o controle de tráfegos específicos, são implementados em hardware. A TCAM permite que um pacote seja avaliado por uma lista de acesso inteira em uma única pesquisa de tabela. A maioria dos switches possui várias TCAMs, de modo que tanto a segurança de entrada quanto a de saída, bem como as ACLs de QoS, possam ser avaliadas simultaneamente ou inteiramente em paralelo com uma decisão de encaminhamento da Camada 2 ou Camada 3.

Troubleshooting de Problemas Relacionados ao ARP ou à CAM

Perda de Endereços MAC Dinâmicos com o Switching Distribuído

No switching distribuído, cada Distributed Feature Card (DFC) é responsável por manter sua própria tabela CAM. Isso significa que cada DFC aprende o endereço MAC e os expira, o que depende da correspondência entre expiração e tráfego da tabela CAM para essa entrada em particular. Com o switching distribuído, é normal que o supervisor engine não veja nenhum tráfego para um endereço MAC em particular por um tempo, de modo que a entrada poderia expirar. No momento, há dois mecanismos disponíveis para manter as tabelas CAM consistentes entre os diferentes supervisor engines, tais como a DFC (presente em módulos de linha) e a Policy Feature Card (presente em módulos de supervisor).

  • Flood to Fabric (FF)

  • Notificação de MAC (MN)

Quando uma entrada de endereço MAC expira na PFC, o comando show mac-address address <MAC_Address> all exibe a DFC ou PFC que mantém esse endereço MAC.

Para prevenir a expiração de uma entrada em uma DFC ou PFC, mesmo que não haja tráfego para esse endereço MAC, habilite a sincronização de endereços MAC. Execute o comando de configuração global mac-address-table synchronize para habilitar a sincronização.

cuidado Cuidado: O comando mac-address-table synchronize limpa as entradas de MAC roteadas. Para evitar que isso aconteça, desative a limpeza de MACs roteados com o comando de configuração global mac-address-table aging-time 0 routed-mac. As entradas de MAC roteadas são endereços MAC que o switch aprende em uma interface física roteada.

O CEF Descarta Pacotes em Intervalos Regulares

O Cisco Express Forwarding (CEF) é uma tecnologia de switching IP da Camada 3 que fornece desempenho superior em comparação a outras tecnologias de switching, especialmente em redes com padrões dinâmicos de tráfego. O CEF mantém estruturas de dados chamadas Forwarding Information Base (FIB) e tabelas de adjacência. A tabela FIB espelha as informações da tabela de roteamento e é utilizada na tomada de decisões de encaminhamento. A tabela de adjacência contém o cabeçalho de camada de enlace pré-calculado para os dispositivos do próximo salto. Com base na interface do próximo salto, as entradas na tabela FIB são mapeadas em entradas na tabela de adjacência. Um dispositivo não será capaz de fazer o switching CEF de pacotes se a tabela de adjacência não estiver preenchida com as informações necessárias.

Se o CEF descartar pacotes em intervalos regulares, intercalados por períodos de operação normal, isso se deve provavelmente à limpeza periódica da tabela de adjacência. Isso é causado pela expiração da entrada de ARP. Os pacotes não sofrem switching CEF no período em que a tabela de adjacência é preenchida novamente com as informações necessárias do próximo salto. As entradas de ARP são atualizadas por padrão a cada quatro horas, e a configuração de um valor muito pequeno de timeout de ARP é prejudicial à operação do CEF.

Execute o comando arp timeout no modo de configuração de interface para alterar o tempo durante o qual uma entrada permanece no cache de ARP.

Consulte o bug da Cisco ID CSCeb53542 (somente usuários registrados) para obter mais informações sobre essa vulnerabilidade. Consulte Troubleshooting de Adjacências Incompletas com o CEF para obter mais informações sobre adjacências de CEF.

O Switch Filtra Endereços MAC Nulos na Tabela CAM

O switch filtra frames com endereço MAC de origem 00-00-00-00-00-00, que é um MAC de origem inválido, da tabela CAM. Este é um exemplo da saída de erro do syslog quando isso ocorre:

%SYS-4-P2_WARN: 1/Filtering MAC address 00-00-00-00-00-00 on port 2/48 from host table

Essas mensagens são meramente informativas e o avisam que um frame que possui um endereço MAC de origem 00-00-00-00-00-00 é recebido, e o switch jamais adicionará esse endereço à tabela CAM. Entretanto, o switch reencaminhará o tráfego originado de endereços MAC nulos.

A solução alternativa é tentar identificar a estação terminal que está gerando frames com um endereço MAC de origem nulo. Em geral, um destes dispositivos transmite tais frames:

  • Um gerador de tráfego, como o Spirent SmartBits

  • Certos tipos de servidores, tais como os servidores de balanceamento de carga IBM WebSphere

  • Um roteador ou estação terminal mal configurados, tais como um dispositivo que transmite broadcasts só com zeros

  • Uma NIC defeituosa

Inundação de Unicast na Rede a Cada 5 Minutos

Os switches de LAN usam tabelas de encaminhamento, tais como as tabelas da Camada 2 e CAM, para direcionar o tráfego para portas específicas com base no número da VLAN e no endereço MAC de destino do frame. Quando não há nenhuma entrada correspondente ao endereço MAC de destino do frame na VLAN de entrada, o frame (de unicast) é enviado para todas as portas de encaminhamento dentro da respectiva VLAN. Isso causa uma inundação. A causa real da inundação é que o endereço MAC de destino do pacote não consta na tabela de encaminhamento da Camada 2 do switch. Nesse caso, o pacote é enviado em inundação a todas as portas de encaminhamento da sua VLAN, com exceção da porta por onde ele foi recebido.

O tempo de expiração padrão da tabela ARP é de 4 horas, enquanto que a CAM mantém as entradas por apenas 5 minutos. O switch envia um frame a todas as portas de encaminhamento da VLAN respectiva quando o endereço MAC de destino expira na tabela CAM. Você precisa de um tempo de expiração de CAM maior ou igual ao timeout do ARP para evitar a inundação de unicast. Como solução alternativa, você pode executar um estes comandos para aumentar o tempo de expiração da CAM para a VLAN que está causando o problema para corresponder ao tempo de expiração do ARP.

Nota: Em qualquer ambiente de Catalyst que execute o Hot Standby Router Protocol (HSRP), é recomendável que você se certifique de que os temporizadores de CAM e ARP estejam sincronizados.

Consulte Inundação de Unicast em Redes Comutadas de Campus para obter informações sobre possíveis causas e implicações da inundação de pacotes de unicast em redes comutadas.

Problemas de ARP no CatOS Híbrido

No modo híbrido, o supervisor engine executa o CatOS e a Multilayer Switch Feature Card (MSFC) executa o Cisco IOS. O CatOS opera na Camada 2 e constrói a tabela de endereços CAM para manter as informações VLAN, o endereço MAC e o número da porta. O Cisco IOS na MSFC opera na Camada 3 e constrói a tabela ARP para manter a resolução de endereço IP para endereço MAC. Ao alterar o endereço IP de qualquer dispositivo, tal como uma impressora ou um servidor, talvez você não seja capaz de fazer um ping para o novo endereço IP. Entretanto, você é capaz de fazer um ping para o novo endereço IP a partir da mesma VLAN. Isso pode ser um problema de ARP na MSFC.

Esta solução pode ajudá-lo a isolar e a resolver o problema:

  1. Limpe a tabela ARP na MSFC.

    MSFC2#clear arp int vlan 40
    
  2. Verifique o valor do timeout de ARP. O valor padrão é de 4 horas. Se o timeout do ARP na VLAN for alto, você poderá definir o valor do timeout de volta para o valor padrão ou ótimo.

    MSFC2#show int vlan 40
    Vlan40 is up, line protocol is up
      Hardware is Cat6k RP Virtual Ethernet, address is 00d0.0050.33fc (bia 00d0.005
    0.33fc)
      Internet address is 40.40.40.3/24
      MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
         reliability 255/255, txload 1/255, rxload 1/255
      Encapsulation ARPA, loopback not set
      Keepalive not supported
      ARP type: ARPA, ARP Timeout 04:00:00
      Last input 00:00:00, output 00:01:44, output hang never
      Last clearing of "show interface" counters never
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
    MSFC2#conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    MSFC2(config)#int vlan 40
    MSFC2(config-if)#arp timeout ?
      <0-2147483>  Seconds
    
    MSFC2(config-if)#arp timeout 240
    
  3. Reinicie a MSFC.

    MSFC2#write memory
    Building configuration...
    [OK]
    MSFC2#reload
    Proceed with reload? [confirm]
    Supervisor> (enable)

Erro EARL-2-EARL4LOOKUPRAMERROR Durante a Pesquisa na Tabela CAM

Este é um exemplo da saída de erro do syslog quando este problema ocorre:

%EARL-2-EARL4LOOKUPRAMERROR:Address eac6, data 0-0-8000-0, count 8

Isto é exibido quando você executa uma pesquisa na tabela CAM. Isso ocorre devido a um erro de paridade quando você acessa a memória. Esse erro é gerado normalmente quando você executa o comando show cam para acessar a tabela CAM. Em alguns casos o switch também é reinicializado quando o comando show cam é executado.

%EARL-2-EARLLOOKUPRAMERROR: Address [hex], data [hex]-[hex]-[hex]-[hex], count [dec]

Essa mensagem de erro indica que um erro de paridade de RAM de pesquisa foi detectado. O campo de endereço [hex] é o endereço na tabela de encaminhamento onde o erro foi detectado. O campo de dados [hex]-[hex]-[hex]-[hex] é a word0, word1, word2 e word3 dos dados da RAM que geraram o erro de paridade. O campo de contador [dec] é o número total de erros de paridade.

Essa mensagem não é catastrófica e não deve resultar em situações de interrupção se houver somente ocorrências isoladas. Se você receber essa mensagem continuamente, isso indica que o switch está tentando escrever em um setor ruim da DRAM ao adicionar uma nova entrada à tabela CAM. Você precisará substituir a DRAM ou o próprio supervisor.

Entradas Estáticas da CAM Perdidas Após Switchover de Supervisor

As entradas estáticas de CAM configuradas no supervisor engine ativo são perdidas após um switchover rápido. Como solução para esse problema, você deve reconfigurar as entradas da CAM após o switchover rápido.

Consulte os bugs da Cisco IDs CSCed87627 (somente usuários registrados) e CSCee27955 (somente usuários registrados) para obter mais informações sobre essa vulnerabilidade.

%ACL-5-TCAMFULL: acl engine TCAM table is full

Se a TCAM estiver cheia e você tentar adicionar novas ACLs ou entradas de controle de acesso (ACEs) às ACLs existentes, o processo de consolidação ou de mapeamento falha. Todas as configurações anteriores continuam efetivas. No caso das listas de controle de acesso de roteador (RACLs), a ACL é aplicada no software da MSFC com a penalidade de desempenho correspondente.

Em um switch que executa software híbrido, se você configurar uma lista de controle de acesso de VLAN (VACL) ou ACEs de ACL de QoS que excedam a capacidade de máscara ou padrão da TCAM, uma mensagem do syslog similar a esta será exibida no console:

%ACL-5-TCAMFULL: acl engine TCAM table is full

Em sistemas com Supervisor IOS, ou na MSFC em um sistema híbrido, se você configurar ACEs de RACL que excedam a capacidade da TCAM, uma mensagem do syslog similar a esta será exibida no console:

%FM-4-TCAM_ENTRY: Hardware TCAM entry capacity exceeded

Em sistemas com Supervisor IOS, ou na MSFC em um sistema híbrido, execute o comando show fm summary para ver quais interfaces utilizam ACLs em hardware (ACTIVE) e quais interfaces utilizam ACLs em software (INACTIVE).

A solução para esse problema é remover as ACLs ou o QoS não utilizado da configuração do switch. Consulte Entendendo as ACLs nos Catalyst 6500 Series Switches para obter mais informações.

Problemas de Ping Ocorrem quando a MSFC Não Responde à Solicitação de ARP nos Catalyst 6500 Series Switches

Quando você executa um ping em uma interface de VLAN, uma solicitação de ARP com um IP de origem dessa VLAN é enviada ao roteador padrão (MSFC), mas o roteador não responde à solicitação de ARP e a depuração do ARP mostra esta mensagem de erro:

IP ARP req filtered src [ip-address] [mac-address] dst [ip-address]
[mac-address] wrong cable, interface-id

Para cada datagrama de ARP, uma resposta de ARP será descartada se o endereço IP de destino não corresponder ao endereço do host local. Uma solicitação de ARP será descartada se o endereço IP de origem não for da mesma sub-rede. É desejável que esse teste seja anulado por um parâmetro de configuração para o suporte dos casos pouco frequentes em que mais de uma sub-rede pode coexistir no mesmo cabo.

Uma resposta de ARP será gerada somente se o endereço IP de destino for acessível a partir do host local, conforme determinado pelo algoritmo de roteamento, e o próximo salto não for por intermédio da mesma interface. Se o host local funcionar como gateway, isso poderá resultar em respostas de ARP para destinos que não estejam na mesma sub-rede. Isso mostra que é justificável descartar a solicitação de ARP.

O problema pode ser resolvido fazendo-se com que o Catalyst 6500 não responda a todas as solicitações de ARP quando o endereço IP de origem da solicitação de ARP estiver em uma sub-rede diferente da do endereço IP de destino. Assim, a MSFC/roteador conclui que o ARP não se mantém no mesmo domínio da Camada 2 e mostra o tipo de cabo incorreto. Em outras palavras, a mensagem de depuração de cabo incorreto é gerada quando a origem e o destino do ARP não pertencem ao mesmo domínio da Camada 2. Para fazer o ARP funcionar nesse cenário, o IP de destino deve ser acessível com o uso da rota estática como solução alternativa.


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.


Document ID: 71079