Problème de corruption du cache ARP Cisco WS-C6509-E ?

• Vous rencontrez ce problème avec des PINGs depuis l'interface CLI du commutateur, ou depuis un PC connecté au commutateur?

• Est-ce que ce commutateur fournit des fonctions de couche 3 (routage)?

• Est-ce que les PINGs que vous montrez ont des problèmes entre deux appareils sur le même sous-réseau, ou à travers des sous-réseaux?

• Est-ce que le journal sur le commutateur ("show log hist", je crois) montre quelque chose d'anormal?

• Est-ce que le problème affecte la remise de paquets à seulement quelques appareils, ou est-ce que vous le voyez affecter plusieurs appareils?

J'ai eu un problème similaire à celui-ci sur un site client il y a quelques années. J'ai capturé la sortie d'un "show mac-" avant que le problème ne survienne, puis pendant que le problème se produisait, et j'ai comparé en cherchant des appareils qui semblaient être sur des ports différents avant que la panne ne commence et après.

J'ai découvert qu'il y avait un appareil intégré sur le LAN (une horloge, dans ce cas) qui envoyait périodiquement un lot de trames avec une adresse source "falsifiée", confondant la table de commutation du commutateur et le forçant à envoyer des trames par le mauvais port pendant un certain temps. J'ai pu le voir dans la sortie du "show mac-" en remarquant que des appareils qui ne devraient pas changer de ports semblaient le faire.

Cela semble amusant à dépanner! J'aurais aimé être là... >sourire<

Modifier:

Merci pour les commentaires.

Le "show log hist" montre un journal persistant. Tant que vous ne videz pas le journal, tous les messages qui y sont signalés seront toujours là après avoir effacé le cache arp sur le commutateur.

Y a-t-il un autre routeur entre votre 6509 et le centre de données de l'entreprise où se trouvent les appareils problématiques?

Utilisez-vous des protocoles de routage dynamique?

Voici ce que mon instinct me dit:

Je vais fortement vous recommander de sauvegarder une copie de "show mac-" et "show arp" avant qu'une panne ne se produise et de nouveau lorsqu'une panne se produit (cela devrait prendre seulement un moment pour les capturer avec quelque chose comme PuTTY, afin que vous puissiez continuer à effacer rapidement le cache arp).

Je comprends que vous ne pouvez pas facilement poster ces captures ici, mais je vous recommande de les mettre dans un tableur ou une base de données et de faire correspondre les adresses MAC avec les ports dans un rapport, et les adresses MAC avec les adresses IP dans un autre. Si vous comparez le "avant" et le "pendant", je prédis que vous allez voir des différences.

En supposant qu'il y ait un routeur entre votre 6509 et le centre de données de l'entreprise, je prédis que vous allez trouver que l'adresse MAC de ce routeur "change" entre les ports, ou son adresse IP change entre les adresses MAC.

S'il n'y a pas de routeur et que les machines du centre de données de l'entreprise communiquent avec ce 6509 au niveau 2, je prédis que les appareils eux-mêmes pourraient montrer des "mouvements" entre les ports, ou des adresses IP se déplaçant entre les adresses MAC.

Si vous exécutez un sniffer sur le client qui est pingé, voyez-vous tous les pings ou seulement la moitié d'entre eux ?

Que se passe-t-il si vous émettez les pings à partir de différentes interfaces sur le 6500 ? Cela se produit-il pour les hôtes pour lesquels le 6500 est la passerelle par défaut ?

À quoi ressemble la table d'adresses MAC ? Et un traceroute ? Et un 'ping -r9 ' ?

Ne pas exclure un bogue IOS, mais cela pourrait aussi être beaucoup d'autres choses...

Il peut s'agir d'un cas d'usurpation ARP. Si quelqu'un essaye d'usurper l'adresse de tous les appareils sur le réseau, y compris la passerelle, la machine usurpatrice recevra trop de trafic et pourrait donc ne pas être en mesure de transférer toutes les données aux bonnes adresses après les avoir lues. Ou la machine usurpatrice pourrait intentionnellement abandonner des paquets supplémentaires.

Exécutez Wireshark. Ensuite, utilisez "arp -d" pour supprimer les entrées arp de toutes les adresses IP sur votre sous-réseau. Ensuite, essayez de pinguer quelques IP sur votre sous-réseau. Ensuite, arrêtez de capturer des paquets avec Wireshark et analysez simplement le trafic ARP. Si vous voyez plusieurs réponses ARP pour chaque IP que vous avez pingée comme l'IP 172.16.1.1 est à xx : xx : xx : xx : xx : xx0 suivi de l'adresse IP 172.16.1,1 est à yy : yy : yy : yy : yy : yy. Alors il s'agit certainement d'un cas d'usurpation ARP et il n'y a rien de mal avec le commutateur.

Si cela ne fonctionne pas, essayez de mettre à jour le système d'exploitation du commutateur vers la dernière version.

Je dois être d'accord avec Peter et Evan. Cela ressemble plus à un itinéraire/port de rebondissement qu'à une attaque de cache. Surtout sur un 65xx. Pour amplifier le commentaire d'Evan, assurez-vous d'obtenir la table ARP (fonctionnelle), mais la seule entrée dont vous aurez vraiment besoin est le routeur suivant. Avez-vous exclu les problèmes de chemins multiples? J'ai vu quelqu'un demander si vous utilisiez un protocole de routage dynamique (ou des passerelles multiples avec des routes statiques flottantes) mais je n'ai pas vu votre réponse. Bonne chance!