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 ils ont 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 problème 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.
Faits:
Symptômes sur le réseau et les commutateurs:
#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
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
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.
Merci @MikePennington et @RickyBeam pour la réponse détaillée. Je vais essayer de répondre à ce que je peux.
"É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 de battre entre les ports)."
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.
Le problème est lié à SCCM 2012 SP1, un service appelé: ConfigMrg Wake-Up Proxy . La "fonctionnalité" ne non existant SCCM 2012 RTM.
Dans les 4 heures suivant la désactivation de cette stratégie, nous avons constaté une baisse régulière de l'utilisation du processeur. Au bout de 4 heures, l'utilisation d'ARP n'était que de 1 à 2%!
En résumé, ce service fait de l'usurpation d'adresse MAC! Je ne peux pas croire à quel point cela a causé des ravages.
Vous trouverez ci-dessous un texte intégral de Microsoft Technet car je pense qu'il est important de comprendre comment cela se rapporte au problème publié.
Pour toute personne intéressée, voici les détails techniques.
Configuration Manager prend en charge deux technologies de réveil sur réseau local (LAN) pour réveiller les ordinateurs en mode veille lorsque vous souhaitez installer les logiciels requis, tels que les mises à jour logicielles et les applications: paquets de réveil traditionnels et commandes de mise sous tension AMT.
À partir de Configuration Manager SP1, vous pouvez compléter la méthode de paquet de réveil traditionnelle en utilisant les paramètres du client proxy de réveil. Le proxy de réveil utilise un protocole d'égal à égal et des ordinateurs élus pour vérifier si les autres ordinateurs du sous-réseau sont éveillés et pour les réveiller si nécessaire. Lorsque le site est configuré pour Wake On LAN et que les clients sont configurés pour le proxy de réveil, le processus fonctionne comme suit:
Les ordinateurs sur lesquels le client Configuration Manager SP1 est installé et qui ne dorment pas sur le sous-réseau vérifient si les autres ordinateurs du sous-réseau sont actifs. Pour ce faire, ils s'envoient une commande ping TCP/IP toutes les 5 secondes.
S'il n'y a pas de réponse d'autres ordinateurs, ils sont supposés endormis. Les ordinateurs réveillés deviennent des ordinateurs de gestion pour le sous-réseau.
Parce qu'il est possible qu'un ordinateur ne réponde pas pour une raison autre que son sommeil (par exemple, il est éteint, supprimé du réseau ou le paramètre du client de réveil du proxy n'est plus appliqué), les ordinateurs sont envoyé un paquet de réveil tous les jours à 14 h heure locale. Les ordinateurs qui ne répondent pas ne seront plus supposés endormis et ne seront pas réveillés par un proxy de réveil.
Pour prendre en charge le proxy de réveil, au moins trois ordinateurs doivent être activés pour chaque sous-réseau. Pour ce faire, trois ordinateurs sont choisis de manière non déterministe pour être des ordinateurs gardiens du sous-réseau. Cela signifie qu'ils restent éveillés, malgré toute politique d'alimentation configurée pour dormir ou hiberner après une période d'inactivité. Les ordinateurs Guardian honorent les commandes d'arrêt ou de redémarrage, par exemple, à la suite de tâches de maintenance. Si cela se produit, les ordinateurs gardiens restants réveillent un autre ordinateur sur le sous-réseau afin que le sous-réseau continue d'avoir trois ordinateurs gardiens.
Les ordinateurs du gestionnaire demandent au commutateur réseau de rediriger le trafic réseau pour les ordinateurs en veille vers eux-mêmes.
La redirection est réalisée par l'ordinateur gestionnaire diffusant une trame Ethernet qui utilise l'adresse MAC de l'ordinateur en veille comme adresse source. Cela fait en sorte que le commutateur réseau se comporte comme si l'ordinateur en veille s'était déplacé vers le même port que l'ordinateur gestionnaire. L'ordinateur gestionnaire envoie également des paquets ARP pour les ordinateurs en veille afin de conserver l'entrée fraîche dans le cache ARP. L'ordinateur gestionnaire répondra également aux demandes ARP au nom de l'ordinateur en veille et répondra avec l'adresse MAC de l'ordinateur en veille.
Au cours de ce processus, le mappage IP-MAC pour l'ordinateur en veille reste le même. Le proxy de réveil fonctionne en informant le commutateur réseau qu'une autre carte réseau utilise le port qui a été enregistré par une autre carte réseau. Cependant, ce comportement est connu sous le nom de volet MAC et est inhabituel pour un fonctionnement réseau standard. Certains outils de surveillance du réseau recherchent ce comportement et peuvent supposer que quelque chose ne va pas. Par conséquent, ces outils de surveillance peuvent générer des alertes ou fermer des ports lorsque vous utilisez un proxy de réveil. N'utilisez pas de proxy de réveil si vos outils et services de surveillance réseau n'autorisent pas les volets MAC.
Lorsqu'un ordinateur gestionnaire voit une nouvelle demande de connexion TCP pour un ordinateur en veille et que la demande est vers un port que l'ordinateur en veille écoutait avant de se mettre en veille, l'ordinateur gestionnaire envoie un réveil- le paquet vers l'ordinateur en veille, puis arrête de rediriger le trafic vers cet ordinateur.
L'ordinateur endormi reçoit le paquet de réveil et se réveille. L'ordinateur expéditeur réessaye automatiquement la connexion et cette fois, l'ordinateur est réveillé et peut répondre.
Merci à tous ceux qui ont posté ici et aidé au processus de dépannage, très appréciés.
- Nous voyons de gros paquets de diffusion de VLAN 1, VLAN 1 utilisé pour les appareils de bureau. Nous utilisons 192.168.0.0/20 ...
- Wiresharks montre que des centaines d'ordinateurs inondent le réseau avec ARP Broadcast ...
Votre processus d'entrée ARP est élevé, ce qui signifie que le commutateur passe beaucoup de temps à traiter les ARP. Une cause très courante d'inondation ARP est une boucle entre vos commutateurs. Si vous avez une boucle, vous pouvez également obtenir les volets Mac que vous avez mentionnés ci-dessus. D'autres causes possibles d'inondations ARP sont:
Éliminez d'abord la possibilité d'erreurs de configuration ou d'une attaque de couche 2 mentionnée ci-dessus. La façon la plus simple de le faire est d'utiliser arpwatch sur une machine Linux (même si vous devez utiliser livecd sur un ordinateur portable). Si vous avez une mauvaise configuration ou une attaque de couche 2, alors arpwatch vous donne des messages comme celui-ci dans syslog, qui répertorie les adresses mac qui se battent sur la même adresse IP ...Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)
Lorsque vous voyez des "tongs", vous devez rechercher la source des adresses mac et comprendre pourquoi elles se battent sur la même IP.
- Grand nombre de volets MAC
- L'arbre couvrant a été vérifié par des personnes qualifiées Cisco TAC et CCNP/CCIE. Nous fermons tous les liens redondants.
Parlant en tant que personne qui a vécu cela plus de fois que je ne voudrais le rappeler, ne supposez pas que vous avez trouvé tous les liens redondants ... faites simplement en sorte que vos ports de commutation se comportent à tout moment.
É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 de battre entre les ports). Si vous n'appliquez pas de limite stricte sur les adresses mac par port Edge, il est très difficile de rechercher ces problèmes sans débrancher manuellement les câbles (ce que vous voulez éviter). Les boucles de commutation provoquent un chemin inattendu dans le réseau, et vous pourriez vous retrouver avec des centaines de macs appris par intermittence à partir de ce qui devrait normalement être un port de commutation de bureau.
Le moyen le plus simple de ralentir les mouvements de mac consiste à utiliser port-security
. Sur chaque port de commutation d'accès dans Vlan 1 qui est connecté à un seul PC (sans commutateur en aval), configurez les commandes de niveau d'interface suivantes sur vos commutateurs Cisco ...
switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!! Beware of people with VMWare / hubs under their desk, because
!! "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a
!! couple of desktop ports
spanning-tree bpduguard enable
Dans la plupart des cas d'inondation mac/ARP, l'application de cette configuration à tous vos ports de commutateur Edge (en particulier ceux avec portfast) vous ramènera à un état sain, car la configuration fermera tout port qui dépasse trois adresses mac et désactivera secrètement un port en boucle portfast. Trois macs par port est un nombre qui fonctionne bien dans mon environnement de bureau, mais vous pouvez le porter à 10 et probablement bien. Après cela, toutes les boucles de la couche 2 sont cassées, les volets mac rapides cessent et le diagnostic est beaucoup plus facile.
Un autre couple de commandes globales qui sont utiles pour traquer les ports associés à une tempête de diffusion (mac-move) et une inondation (seuil) ...
mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900
Après avoir terminé, effectuez éventuellement une clear mac address-table
pour accélérer la guérison à partir d'une table CAM potentiellement pleine.
- Afficher la table d'adresses mac sur différents commutateurs et le noyau lui-même (sur le noyau, par exemple, connecté 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é à ce ...
Toute cette réponse suppose que votre 3750 n'a pas de bogue à l'origine du problème (mais vous avez dit que wirehark indiquait des PC qui sont en train d'être inondés). Ce que vous nous montrez est évidemment faux quand il n'y a qu'un seul ordinateur connecté à Gi1/1/3, à moins que ce PC ait quelque chose comme VMWare dessus.
Sur la base d'une conversation que nous avons eue, je n'ai probablement pas à mentionner l'évidence, mais je le ferai pour le bien des futurs visiteurs ...
La vraie question est pourquoi les hôtes envoient-ils autant d'ARP en premier lieu. Jusqu'à ce que cela soit répondu, le ou les commutateurs continueront à avoir du mal à gérer la tempête d'arp. Inadéquation du masque de réseau? Minuteries d'arp d'hôte faible? Un (ou plusieurs) hôtes ayant une route "interface"? Un pont sans fil rouge quelque part? "arp gratuit" devenu fou? Serveur DHCP "en cours d'utilisation"? Cela ne ressemble pas à un problème avec les commutateurs ou la couche 2; vous avez des hôtes qui font de mauvaises choses.
Mon processus de débogage consiste à tout débrancher et à surveiller de près les choses qui sont reconnectées, un port à la fois. (Je sais que c'est à des kilomètres de l'idéal, mais à un moment donné, vous devez réduire vos pertes et tenter d'isoler physiquement toute source possible) Ensuite, je chercherais à comprendre pourquoi certains ports génèrent de nombreux arp.
(Est-ce que beaucoup de ces hôtes seraient des systèmes linux? Linux a eu un système de gestion de cache ARP très stupide. Le fait qu'il "revérifiera" une entrée en quelques minutes, est cassé dans mon livre Il a tendance à être moins problématique dans les petits réseaux, mais a/20 n'est pas un petit réseau.)
Cela peut ou non être lié à votre problème, mais je me suis dit que cela pouvait être au moins quelque chose à jeter:
Nous avons actuellement un certain nombre de 3750x empilés sur certains de nos sites distants, principalement sous 15.0.2 (SE0 à 4, il y a des bogues FRU avec SE0 dont je migre lentement).
Au cours d'une mise à jour de routine de [IOS, passant de 15.0.2 à 15.2-1 (SE le plus récent), nous avons remarqué une augmentation assez importante du processeur, d'une moyenne d'environ 30% à 60% et plus pendant les heures creuses. fois. J'ai passé en revue les configurations et IOS les journaux des modifications, et j'ai travaillé avec le TAC de Cisco. Selon TAC, ils semblent être au point où ils croient qu'il s'agit d'un bogue IOS 15.2-1.
Alors que nous continuions d'enquêter sur l'augmentation du processeur, nous avons commencé à voir d'énormes quantités de trafic ARP au point où nos tables ARP se remplissaient complètement et causaient une instabilité du réseau. La béquille temporaire pour cela était de sauvegarder manuellement nos délais d'expiration ARP par défaut (14400) à 300 sur nos vlans voix et données.
Après avoir réduit nos délais d'expiration ARP, nous sommes restés stables pendant environ une semaine, date à laquelle nous sommes revenus à IOS 15.0.2-SE4 et avons supprimé nos délais d'expiration ARP non définis par défaut. Notre utilisation du processeur est revenue à environ 30% et nos problèmes de table ARP sont inexistants.
Une question assez simple mais peut-être négligée; vos clients ont-ils une passerelle par défaut valide, n'est-ce pas votre cœur qui fait beaucoup d'arcs proxy. Vous pourriez envisager de supprimer la fonction arp du proxy ip sur votre 3750?