Réseau d'inondation de diffusion ARP et utilisation élevée du processeur

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.

Résolu.

Le problème vient de SCCM 2012 SP1, un service appelé: ConfigMrg Wake-Up Proxy . La «fonctionnalité» n'existe pas dans 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.

Ci-dessous est un texte complet 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: les paquets de réveil traditionnels et les 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:

1. 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.

2. 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.

3. Étant donné 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éactivation 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 que le commutateur réseau se comporte comme si l'ordinateur en veille avait été 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.

4. 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 sommeil écoutait avant de se mettre en veille, l'ordinateur gestionnaire envoie un paquet de réveil à l'ordinateur en veille, puis arrête de rediriger le trafic vers cet ordinateur.

5. 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.

Réf: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Merci à tous ceux qui ont posté ici et aidé au processus de dépannage, très appréciés.

Tempête ARP / Broadcast

• 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 ...
• 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:

• Mauvaise configuration d'adresse IP
• Une attaque de couche 2, comme l' usurpation d'arp

Éliminez d'abord la possibilité de mauvaises configurations 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 un 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 périphérique, 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 est d'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 de périphérie (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 rompues, 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-tablepour 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, 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é à 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 n'ait quelque chose comme VMWare dessus.

Pensées diverses

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 ...

• Mettre des utilisateurs dans Vlan1 est normalement une mauvaise idée (je comprends que vous ayez hérité d'un gâchis)
• Indépendamment de ce que TAC vous dit, 192.168.0.0/20 est trop volumineux pour être géré dans un seul domaine commuté sans risque d'attaques de couche 2. Plus votre masque de sous-réseau est grand, plus vous avez d'exposition aux attaques de couche 2 comme celle-ci, car ARP est un protocole non authentifié et un routeur doit au moins lire un ARP valide à partir de ce sous-réseau.
• Le contrôle des tempêtes sur les ports layer2 est également une bonne idée; cependant, ce qui permet de contrôler les tempêtes dans une situation comme celle-ci, il supprimera le bon trafic avec le mauvais trafic. Une fois le réseau guéri, appliquez des stratégies de contrôle des tempêtes sur vos ports périphériques et liaisons montantes.

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 faibles? Un (ou plusieurs) hôte (s ) 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).

Lors d'une mise à jour IOS de routine, passant de 15.0.2 à 15.2-1 (SE le plus récent), nous avons remarqué une augmentation du processeur assez importante, passant d'environ 30% à 60% en moyenne et plus pendant les heures creuses. J'ai passé en revue les configurations et les journaux des modifications IOS, 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 bug 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 provoquaient 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.

Un simple simple mais peut-être négligé; 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?