Quelque chose remplit ma table ARP force10

J'ai 2 commutateurs force10 s25 qui sont utilisés pour une liaison fibre noire entre deux bâtiments scolaires. Un de mes commutateurs remplit sa table ARP à ras bord puis échoue. Cela peut arriver aussi souvent que toutes les 1,5 heures. J'ai remarqué que l'une des adresses dans le cache est une adresse de notre filtre Web précédent qui n'était pas en ligne depuis 6 mois. Nous ne pouvons penser à rien qui contiendrait un cache ARP, mais quelque chose semble alimenter notre force10 avec des adresses, mais en exécutant le résumé de show arp, parfois jusqu'à 50 nouvelles adresses par seconde sont ajoutées. Que dois-je rechercher pour comprendre d'où cela vient?

Voici ma route show ip connectée

MiddleSchool#show ip route connected
   Destination        Gateway                      Dist/Metric Last Change
   -----------        -------                      ----------- -----------
  C    10.4.0.0/16        Direct, Vl 400                       0/0    03:39:18
  C    192.168.1.0/30     Direct, Te 0/28                      0/0    03:39:20

La seule route statique est la route par défaut (0.0.0.0 / 0 sur le port tengig 0/28) sur la liaison fibre, car tout le trafic doit quitter ce commutateur et se rendre dans l'autre bâtiment pour accéder à Internet.

switch routing router ethernet arp MooseBalm
la source

sur la base des informations très limitées dont nous disposons actuellement, ma meilleure supposition est que vous avez une ou des machines usurpant les arps pour déborder la table d'adresses mac. Une autre possibilité est une machine avec un mappeur de virus / ver / réseau qui transite les interfaces configurées pour utiliser le proxy arp pour la résolution du prochain bond. Veuillez éditer dans "show ip route connected" (ou tout ce que vous utilisez sur Force10 comme équivalent de cette cmd Cisco IOS), ainsi que toutes les routes statiques qui pointent vers une interface connectée au lieu d'une adresse IP de saut suivant. Regardez votre table d'adresses mac pour la source de nombreuses adresses mac qui devraient être un seul PC.

Mike Pennington

Y a-t-il des modèles ou des répétitions dans la table ARP ou la majorité des entrées d'adresses MAC sont-elles aléatoires? Existe-t-il des entrées de délai d'expiration du cache ARP configurées manuellement au-delà des valeurs par défaut (qui sont généralement de quatre heures)? Y a-t-il des commutateurs en aval qui pourraient potentiellement être bouclés? Il peut être utile de remonter jusqu'au bord s'il y a des commutateurs en aval.

one.time

Les commutateurs semblent recevoir une tempête de diffusion, mais nous ne pouvons pas l'identifier. Nous avons débranché chaque connexion pour voir si quelque chose pouvait provoquer l'arrêt ou le ralentissement de l'activité intense, mais nous avons échoué. Si je regarde la table ARP, la partie inhabituelle est qu'elle stocke des adresses Internet pour les adresses IP et elles sont toutes liées à l'adresse MAC du commutateur. Notre réseau est 10.4.0.0 / 16 dans ce bâtiment, et nous verrons même des adresses qui ressemblent à 10.4.85. *, Donc très proches de notre sous-réseau. Il existe également 192.168 adresses en dehors de notre itinéraire de liaison.

MooseBalm

Réponses:

J'ai regardé les configs dans votre question de débordement de pile .

En guise de revue, voici votre topologie ...

      Ten0/28  Ten0/28
Bldg_L----------------Bldg_S
F10 S25               F10 S25
  |                     |
  Vlan200               Vlan400
  10.2.0.101            10.4.0.101/16

Le problème est que la construction du proxy proxy-ARP de L pour résoudre 10.4.0.0/16et la construction du commutateur proxy-ARP de S pour 10.2.0.0/16... l'interface TenGig0 / 28 (votre lien de transit entre les bâtiments) répond aux demandes de proxy-ARP. Supprimez ces statiques 10-net et utilisez ...

Bâtiment L: ip route 10.4.0.0 255.255.0.0 192.168.1.2
Immeubles: ip route 10.2.0.0 255.255.0.0 192.168.1.1

La raison pour laquelle une route comme ip route 10.4.0.0 255.255.0.0 TenGigabit0/28proxy-ARPs est parce que vous dites essentiellement au commutateur que le sous-réseau entier / 16 est directement connecté à TenGigabit0 / 28 lorsque vous routez de manière statique une interface comme celle-ci. L'utilisation d'un prochain bond IP nécessite uniquement une entrée ARP pour ce prochain bond spécifique.

Vous devez probablement déplacer la passerelle par défaut vers une nouvelle interface sur le commutateur Building L, de sorte que l'ensemble du sous-réseau puisse passer par défaut via 10.2.0.101 et atteindre 10.4.0.0/16 ou Internet.

Désolé de le dire, mais vous vous laissez largement ouvert aux problèmes d'épuisement des ressources ARP lorsque vous attribuez un / 16 comme sous-réseau connecté ... ARP est un protocole non authentifié, et n'importe qui sur le LAN peut inonder le commutateur d'ARP et il a pas d'autre choix que de les mettre en cache / d'y répondre ... même pour les adresses fantômes.

De manière proactive, vous pouvez envisager l'espionnage DHCP et l'inspection ARP dynamique, si votre version de FTOS le prend en charge. Ces fonctionnalités nécessitent normalement une réflexion et des tests avant le déploiement; Cependant, ils valent la peine d'être utilisés si vous avez des centaines d'enfants sans rien de plus excitant que de montrer leurs compétences en "piratage". J'ai fait une recherche rapide pour voir si Force10 prend en charge ce que Cisco appelle la sécurité des ports, mais je ne l'ai pas trouvé; la sécurité des ports peut être utilisée pour limiter le nombre de macs appris sur un port de commutateur.

Mike Pennington
la source

Je voulais dire que c'était proche de notre portée. Je sais que ce n'est pas dans le sous-réseau, c'est ma faute. Notre portée DHCP dans ce bâtiment est 10.4.50.1-10.4.51.254, donc le 10.4.85. * N'est pas une adresse DHCP que nous émettrions. J'ai changé les itinéraires afin qu'ils utilisent les adresses IP au lieu de la passerelle. Je ne peux pas tout déconnecter avant ce soir, mais actuellement la table d'adresses MAC est à 246 adresses dynamiques et 0 adresses statiques ou collantes.

MooseBalm

Après avoir changé les itinéraires, cela semble l'avoir corrigé. Si quelque chose change, je mettrai à jour le message, mais pour l'instant ma table ARP se situe à 230 enregistrements et n'a pas sauté depuis 10 minutes. Merci beaucoup. Votre aide a été très appréciée.

MooseBalm