Estamos tendo um problema com o nosso Catalyst 6500, onde suspeitamos que o cache do ARP está sendo corrompido. Isso se apresenta com os seguintes sintomas:
Quando você tenta fazer ping em um sistema que não foi resolvido antes, a primeira resposta de ping expira e cada um deles é bem-sucedido: Pingando foo.network.com [xxx.xx.xx.xx] com 32 bytes de dados: Solicitação expirou. Resposta de xxx.xx.xx.xx: bytes = 32 tempo = 5ms TTL = 55 Resposta de xxx.xx.xx.xx: bytes = 32 tempo = 3ms TTL = 55 Resposta de xxx.xx.xx.xx: bytes = 32 tempo = 3ms TTL = 55
Quando ocorrem os problemas de corrupção, todos os outros tempos de ping são excedidos: Pingando foo.network.com [xxx.xx.xx.xx] com 32 bytes de dados: Resposta de xxx.xx.xx.xx: bytes = 32 tempo = 5ms TTL = 55 Solicitação expirou. Resposta de xxx.xx.xx.xx: bytes = 32 tempo = 5ms TTL = 55 Solicitação expirada.
Limpar o cache ARP resolve o problema temporariamente. Para limpar o cache do ARP, usamos os comandos: cache de arp claro cache ip limpo Isso corrige isso, mas certamente acontecerá novamente.
Detalhes sobre o interruptor:
Software IOS (tm) s72033_rp (s72033_rp-PK9SV-M), Versão 12.2 (17d) SXB8, SOFTWARE DE RELEASE (fc2)
Processador Cisco WS-C6509-E (R7000) (revisão 1.1)
Qualquer ajuda apreciada, Obrigado
ESCLARECIMENTO: Temos a rede que gerenciamos e depois estamos conectados à rede corporativa. Todas as solicitações para máquinas dentro da rede que gerenciamos funcionam bem. Estamos apenas tendo problemas com máquinas na outra rede.
Eu sugiro que você abra um caso para a Cisco.
Eles poderão verificar se há erros em sua versão do IOS e solicitarão detalhes de configuração que talvez você não queira publicar aqui. (mas se você quiser, pode colocar o resultado de um sh tech em algum lugar que possa nos ajudar)
Além disso, ele adiciona após uma reinicialização ou começou a ficar corrompido após um longo período de atividade?
Você está vendo esse problema com os PINGs da CLI do switch ou de um PC conectado ao switch?
Esse switch fornece funções da camada 3 (roteamento)?
Esses PINGs são exibidos com problemas entre dois dispositivos na mesma sub-rede ou em sub-redes?
O log no switch ("show log hist", eu acredito) mostra alguma coisa errada?
O problema está afetando a entrega de pacotes apenas para alguns dispositivos, ou você está vendo isso afetando vários dispositivos?
Eu tive um problema parecido com isso em um site do cliente há alguns anos atrás. Capturei a saída de um "show mac-" antes da ocorrência do problema e, em seguida, durante a ocorrência do problema, e comparei a procura por dispositivos que pareciam estar em portas diferentes antes do início e da interrupção da interrupção.
Descobri que havia um dispositivo embutido na LAN (um relógio, neste caso) que periodicamente transmitia um lote de quadros com um endereço de origem "falsificado", confundindo a tabela de ponte do comutador e fazendo com que o comutador enviasse quadros a porta errada por algum tempo. Eu era capaz de vê-lo na saída "show mac-", notando que os dispositivos que não deveriam estar mudando de porta pareciam estar fazendo isso.
Parece divertido solucionar problemas. Queria estar lá ... > sorrir <
Editar:
Obrigado pelos comentários.
"show log hist" mostra um log persistente. Contanto que você não esteja limpando o log, qualquer mensagem relatada lá ainda estará lá depois que você limpar o cache do arp no switch.
Existe algum outro roteador entre o seu 6509 e o datacenter corporativo onde os dispositivos com problemas residem?
Você está usando algum protocolo de roteamento dinâmico?
Veja o que meu instinto diz:
Recomendamos enfaticamente que você salve uma cópia de "show mac-" e "show arp" antes que ocorra uma falha e novamente quando ocorrer uma falha (deve levar apenas um momento para capturá-los com algo como PuTTY, para que você possa limpar o arp cache rapidamente).
Sei que você não pode postar facilmente essas capturas aqui, mas recomendo que você as jogue em uma planilha ou banco de dados e combine o endereço MAC com as portas em um relatório e os endereços MAC com o endereço IP em outro. Se você comparar "antes" e "durante", eu prevejo que você verá algumas diferenças.
Supondo que haja um roteador entre o seu 6509 e o data center corporativo, prevejo que você vai achar o endereço MAC do roteador "em movimento" entre as portas ou o endereço IP que está se movendo entre os endereços MAC.
Se não houver um roteador e as máquinas do datacenter corporativo estiverem conversando com esse 6509 na camada 2, eu prevejo que os próprios dispositivos podem mostrar alguma "movimentação" entre portas ou mover endereços IP entre endereços MAC.
Se você executar um sniffer no cliente que está sendo pingado, verá todos os pings ou apenas metade deles?
O que acontece se você fornecer os pings de diferentes interfaces no 6500? Isso acontece para hosts que o 6500 é o gateway padrão para?
Como é a tabela de endereços mac? Que tal um traceroute? E um 'ping-r9'?
Não descarte um bug do IOS, mas também pode haver muitas outras coisas ...
Pode ser um caso de spoofing ARP. Se alguém está tentando falsificar todo o endereço na rede, incluindo o gateway, a máquina de spoofing terá muito tráfego e, portanto, pode não ser capaz de transferir todos os dados para corrigir os endereços depois de lê-los. Ou a máquina de falsificação pode soltar intencionalmente pacotes adicionais.
Execute o wireshark. Em seguida, use "arp -d" para excluir as entradas arp de todos os endereços IP da sua sub-rede. Em seguida, tente pingar poucos IPs na sua sub-rede. Então pare de capturar pacotes do wireshark e apenas analise o tráfego ARP. Se você vir várias respostas ARP para cada IP enviado por você como o IP 172.16.1.1, estará em xx: xx: xx: xx: xx: xx0 seguido pelo endereço IP 172.16.1.1 em yy: yy: yy: yy: yy: yy Então, é definitivamente um caso de spoofing ARP e não há nada errado com o switch.
Caso isso não funcione. Tente atualizar o switch IOS para a versão mais recente.
Eu tenho que concordar com Peter e Evan. Isso soa mais como uma rota / porta saltante do que um ataque de cache. Especialmente em um 65xx. Para amplificar o comentário de Evan, certifique-se de obter a tabela arp (de trabalho), mas a única entrada que você realmente precisará é o roteador do próximo salto. Você descartou problemas com múltiplos caminhos? Eu vi alguém perguntar se você estava executando um protocolo de roteamento dinâmico (ou vários gateways com rotas estáticas flutuantes), mas não vi sua resposta. Boa sorte!