En espérant que quelqu'un ici pourrait avoir un aperçu du problème auquel nous sommes confrontés. Actuellement, Cisco TAC examine le cas, mais il a du mal à trouver la cause première.
Bien que le titre mentionne la diffusion ARP et l'utilisation élevée du processeur, nous ne savons pas s'ils sont liés ou non à ce stade.
Le numéro d'origine a été publié sur la communauté en ligne INE
Nous avons réduit le réseau à une seule liaison sans configuration de redondance, considérez-le comme une topologie en étoile.
Les faits:
- Nous utilisons des commutateurs 3750x, 4 dans une pile. Version 15.0 (1) SE3. Cisco TAC ne confirme aucun problème connu pour les bogues CPU ou ARP élevés pour cette version particulière.
- Aucun concentrateur / commutateur non géré connecté
- Pile Core rechargée
- Nous n'avons pas de route par défaut "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Utilisation d'OSPF pour le routage.
- Nous voyons de gros paquets de diffusion de VLAN 1, VLAN 1 utilisés pour les appareils de bureau. Nous utilisons 192.168.0.0/20
- Cisco TAC a déclaré qu'ils ne voyaient rien de mal à utiliser / 20, à part cela, nous aurions un grand domaine de diffusion, mais nous devrions toujours fonctionner.
- Le Wifi, la gestion, les imprimantes, etc. sont tous sur des VLAN différents
- L'arbre couvrant a été vérifié par des personnes qualifiées Cisco TAC et CCNP / CCIE. Nous fermons tous les liens redondants.
- La configuration sur le noyau a été vérifiée Cisco TAC.
- Nous avons le délai d'expiration ARP par défaut sur la plupart des commutateurs.
- Nous n'implémentons pas Q & Q.
- Aucun nouveau commutateur n'a été ajouté (du moins aucun à notre connaissance)
- Impossible d'utiliser l'inspection d'arp dynamique sur les commutateurs de périphérie car ce sont 2950
- Nous avons utilisé des interfaces d'exposition | inc line | broadcast pour déterminer d'où provient le grand nombre de diffusions, mais Cisco TAC et 2 autres ingénieurs (CCNP et CCIE) ont confirmé qu'il s'agit d'un comportement normal en raison de ce qui se passe sur le réseau (comme dans un grand nombre de volets Mac) provoquant la diffusion plus importante). Nous avons vérifié que le STP fonctionnait correctement sur les commutateurs de périphérie.
Symptômes sur le réseau et les commutateurs:
- Grand nombre de volets MAC
- Utilisation élevée du processeur pour le processus d'entrée ARP
- Grand nombre de paquets ARP, en augmentation rapide et visibles
- Wiresharks montre que des centaines d'ordinateurs inondent le réseau avec ARP Broadcast
- À des fins de test, nous avons mis environ 80 ordinateurs de bureau différents sur vlan, mais nous avons testé cela et n'avons fait aucune différence visible pour une entrée élevée de processeur ou d'arp
- Avoir exécuté différents AV / malware / spyware, mais aucun virus visible sur le réseau.
- sh mac address-table count, nous montre environ 750 adresses mac différentes comme prévu sur vlan 1.
#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
12 111438973 18587995 5995 44.47% 43.88% 43.96% 0 ARP Input
174 59541847 5198737 11453 22.39% 23.47% 23.62% 0 Hulc LED Process
221 7253246 6147816 1179 4.95% 4.25% 4.10% 0 IP Input
86 5459437 1100349 4961 1.59% 1.47% 1.54% 0 RedEarth Tx Mana
85 3448684 1453278 2373 1.27% 1.04% 1.07% 0 RedEarth I2C dri
- Afficher la table d'adresses mac sur différents commutateurs et le noyau lui-même (sur le noyau, par exemple, branché directement par le bureau, mon bureau), et nous pouvons voir plusieurs adresses matérielles MAC différentes enregistrées sur l'interface, même si cette interface a un seul ordinateur connecté à ceci:
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 001c.c06c.d620 DYNAMIC Gi1/1/3
1 001c.c06c.d694 DYNAMIC Gi1/1/3
1 001c.c06c.d6ac DYNAMIC Gi1/1/3
1 001c.c06c.d6e3 DYNAMIC Gi1/1/3
1 001c.c06c.d78c DYNAMIC Gi1/1/3
1 001c.c06c.d7fc DYNAMIC Gi1/1/3
- utilisation de show platform tcam
CAM Utilization for ASIC# 0 Max Used
Masks/Values Masks/values
Unicast mac addresses: 6364/6364 1165/1165
IPv4 IGMP groups + multicast routes: 1120/1120 1/1
IPv4 unicast directly-connected routes: 6144/6144 524/524
IPv4 unicast indirectly-connected routes: 2048/2048 77/77
IPv4 policy based routing aces: 452/452 12/12
IPv4 qos aces: 512/512 21/21
IPv4 security aces: 964/964 45/45
Nous sommes maintenant à un stade où nous aurons besoin de temps d'arrêt énormes pour isoler chaque zone à la fois, à moins que quelqu'un d'autre n'ait des idées pour identifier la source ou la cause profonde de ce problème étrange et bizarre.
Mise à jour
Merci @MikePennington et @RickyBeam pour la réponse détaillée. Je vais essayer de répondre à ce que je peux.
- Comme mentionné, 192.168.0.0/20 est un désordre hérité. Cependant, nous avons l'intention de diviser cela à l'avenir, mais malheureusement, ce problème s'est produit avant que nous ne puissions le faire. Personnellement, je suis également d'accord avec la majorité, selon laquelle le domaine de diffusion est beaucoup trop grand.
- L'utilisation d'Arpwatch est certainement quelque chose que nous pouvons essayer, mais je soupçonne que plusieurs ports d'accès enregistrent l'adresse mac même si elle n'appartient pas à ce port, la conclusion d'arpwatch peut ne pas être utile.
- Je suis entièrement d'accord avec le fait de ne pas être sûr à 100% de trouver toutes les liaisons redondantes et les commutateurs inconnus sur le réseau, mais le meilleur de notre constatation, c'est le cas jusqu'à ce que nous trouvions d'autres preuves.
- La sécurité portuaire a été examinée, malheureusement la direction a décidé de ne pas l'utiliser pour diverses raisons. La raison courante est que nous déplaçons constamment des ordinateurs (environnement universitaire).
- Nous avons utilisé spf-tree portfast avec en conjonction avec spanning-tree bpduguard par défaut sur tous les ports d'accès (machines de bureau).
- Nous n'utilisons pas switchport nonnegotiate pour le moment sur le port d'accès, mais nous n'obtenons aucune attaque de saut de Vlan qui rebondit sur plusieurs Vlan.
- Donnera une notification à mac-address-table, et verra si nous pouvons trouver des modèles.
"Étant donné que vous obtenez un grand nombre de volets MAC entre les ports de commutation, il est difficile de trouver où se trouvent les contrevenants (supposons que vous trouviez deux ou trois adresses mac qui envoient de nombreux arps, mais les adresses mac source continuent à osciller entre les ports)."
- Nous avons commencé sur ce point, choisi des volets MAC et poursuivi notre chemin à travers tout le commutateur principal vers la distribution pour accéder au commutateur, mais ce que nous avons constaté était encore une fois, l'interface du port d'accès monopolisait plusieurs adresses mac, donc des volets mac; revenons donc à la case départ.
- Le contrôle des tempêtes est quelque chose que nous avons envisagé, mais nous craignons que certains paquets légitimes ne soient supprimés, ce qui entraînera d'autres problèmes.
- Vérifie la configuration de VMHost.
- @ytti les adresses MAC inexplicables sont derrière de nombreux ports d'accès plutôt qu'un individu. Je n'ai trouvé aucune boucle sur ces interfaces. Les adresses MAC existent également sur d'autres interfaces, ce qui expliquerait un grand nombre de volets MAC
- @RickyBeam, je suis d'accord avec les raisons pour lesquelles les hôtes envoient tant de demandes ARP; c'est l'une des questions déroutantes. Le pont sans fil de Rouge est un pont intéressant auquel je n'ai pas pensé, à notre connaissance, le sans fil est sur un VLAN différent; mais escroc signifie évidemment qu'il pourrait bien être sur VLAN1.
- @RickyBeam, je ne souhaite pas vraiment tout débrancher car cela entraînera une énorme quantité de temps d'arrêt. Cependant, c'est là que cela peut se diriger. Nous avons des serveurs Linux mais pas plus de 3.
- @RickyBeam, pouvez-vous expliquer le sondage "en cours d'utilisation" du serveur DHCP?
Nous (Cisco TAC, CCIE, CCNP) convenons globalement que ce n'est pas une configuration de commutateur mais un hôte / périphérique est à l'origine du problème.
switchport port-security aging time 5
et switchport port-security aging type inactivity
signifie que vous pouvez déplacer des stations entre les ports après 5 minutes d'inactivité, ou si vous effacez manuellement l'entrée de sécurité des ports. Cependant, cette configuration empêche les volets mac entre les ports d'accès du commutateur car les ports ne peuvent pas arbitrairement source la même adresse mac à partir d'un port différent.