Le petit collège où je travaille a des problèmes de réseau très étranges. Je recherche des conseils ou des idées ici. Nous étions bien pendant l'été, mais les ennuis ont commencé quelques jours après le retour des étudiants sur le campus en vigueur pour le trimestre d'automne.
Symptômes
Le principal symptôme est que l'accès à Internet fonctionnera, mais c'est très lent ... souvent au point d'expiration. Par exemple, un résultat typique de Speedtest.net renverra un téléchargement de 0,4 Mbps, mais autorisera une vitesse de téléchargement de 3 à 8 Mbps. Les symptômes mineurs peuvent inclure des performances très limitées lors du transfert de données vers et depuis notre serveur de fichiers, ou même dans certains cas, l'impossibilité de se connecter à l'ordinateur (ne peut pas atteindre le contrôleur de domaine). Le problème traverse plusieurs vlans et a affecté des appareils sur presque tous les vlan que nous exploitons.
Le problème n'a pas d'impact sur toutes les machines du réseau. Une machine non affectée verra généralement au moins 11 Mbit / s de téléchargement à partir de speedtest.net, et peut-être beaucoup plus selon les modèles de trafic sur le campus à l'époque.
Il existe une variation sur la question plus large. Nous avons un vlan où les utilisateurs n'ont pas pu se connecter à presque toutes les machines. Le personnel informatique se connectait à l'aide d'un compte d'administrateur local (ou dans certains cas, des informations d'identification mises en cache), et à partir de là, une version / renouvellement ou un ping de la passerelle permettait à la machine de fonctionner ... pendant un certain temps. Pour compliquer ce problème, ce vlan couvre nos laboratoires informatiques, qui utilisent un logiciel appelé Deep Freeze pour réinitialiser complètement les disques durs après un redémarrage. Il pourrait simplement y avoir le même problème se manifestant différemment en raison de données périmées sur des machines qui n'ont pas modifié de manière permanente les informations de bas niveau depuis des semaines. Nous avons cependant pu résoudre ce problème en créant un nouveau vlan et en déplaçant les laboratoires vers le nouveau vlan en gros.
Instigations
Finalement, nous avons remarqué que les machines concernées avaient toutes des baux dhcp récents. Nous pouvons prédire quand une machine deviendra "lente" en regardant quand un bail DHCP arrive à renouvellement. Nous avons joué avec un temps de location très court pour un vlan de test, mais tout ce qui a été fait a été de supprimer notre capacité à prédire quand la machine deviendrait lente. Les machines avec des adresses IP statiques ont pratiquement toujours fonctionné normalement. La libération / le renouvellement manuel d'une adresse ne ralentira jamais une machine. En fait, dans certains cas, ce processus a corrigéune machine dans cet état. Mais la plupart du temps, cela n'aide pas. Nous avons également remarqué que les machines mobiles comme les ordinateurs portables deviendront probablement lentes lorsqu'elles passeront à de nouveaux vlans. La connexion sans fil sur le campus est divisée en "zones", où chaque zone correspond à un petit ensemble de bâtiments. Déménager dans un nouveau bâtiment peut vous placer dans une zone, vous obligeant ainsi à obtenir une nouvelle adresse. Une machine sortant du mode veille est également très susceptible d'être lente.
Atténuation
Parfois, mais pas toujours, l'effacement du cache arp sur une machine affectée lui permettra de fonctionner à nouveau normalement. Comme déjà mentionné, la publication / le renouvellement de l'adresse IP d'une machine locale peut réparer cette machine, mais ce n'est pas garanti. Le ping de la passerelle par défaut peut également parfois aider avec une machine lente.
Ce qui semble aider le plus à atténuer le problème est de vider le cache arp sur notre commutateur de couche 3 de base. Ce commutateur est utilisé pour notre système DHCP comme la passerelle par défaut sur tous les réseaux locaux virtuels, et il gère le routage inter-Vlan. Le modèle est un 3Com 4900SX. Pour essayer d'atténuer le problème, nous avons défini le délai d'expiration du cache sur le commutateur jusqu'au temps le plus bas possible, mais cela n'a pas aidé. J'ai également mis en place un script qui s'exécute toutes les quelques minutes pour se connecter automatiquement au commutateur et réinitialiser le cache. Malheureusement, cela ne fonctionne pas toujours et peut même entraîner le ralentissement de certaines machines pendant une courte période (bien que celles-ci semblent se corriger après quelques minutes). Nous avons actuellement un travail planifié qui s'exécute toutes les 10 minutes pour forcer le commutateur principal à vider son cache ARP, mais cela est loin d'être parfait ou souhaitable.
la reproduction
Nous avons maintenant une machine d'essai que nous pouvons forcer à volonté à l'état lent. Il est connecté à un commutateur avec des ports configurés pour chacun de nos vlans. Nous rendons la machine lente en nous connectant à différents réseaux locaux virtuels, et après une nouvelle connexion ou deux, elle sera lente.
Il convient également de noter dans cette section que cela s'est déjà produit au début des mandats précédents, mais dans le passé, le problème a disparu de lui-même après quelques jours. Il s'est résolu avant que nous ayons eu l'occasion de faire beaucoup de travail de diagnostic ... d'où la raison pour laquelle nous l'avons laissé traîner si longtemps dans le terme cette fois; on s'attendait à ce que cette situation soit de courte durée.
Autres facteurs
Il convient de mentionner que nous avons eu environ une demi-douzaine de commutateurs qui ont tout simplement échoué au cours de la dernière année. Ce sont principalement des 3Coms de l'ère 2003/2004 (principalement des 4200) qui ont toutes été installées à peu près au même moment. Ils doivent toujours être couverts par la garantie, l'achat de HP a rendu le service quelque peu difficile. Surtout dans les alimentations qui ont échoué, mais dans quelques cas, nous avons utilisé une alimentation provenant d'un commutateur avec une carte mère défectueuse pour ramener un commutateur avec une alimentation défectueuse à la vie. Nous avons actuellement des onduleurs sur tous les commutateurs, sauf trois, mais ce n'était pas le cas lorsque j'ai commencé il y a deux ans et demi. Des contraintes budgétaires sévères (nous étions sur la liste des institutions financièrement défavorisées du Département d'Ed il y a quelques années) m'ont obligé à me tourner vers Netgear et TrendNet pour des remplacements,
Il convient également de mentionner que le grand changement sur notre réseau cet été a été la migration d'un SSID sans fil inter-campus unique vers l'approche zonée mentionnée précédemment. Je ne pense pas que ce soit la source du problème, comme je l'ai dit: nous l'avons déjà vu. Cependant, il est possible que cela exacerbe le problème et peut être en grande partie la raison pour laquelle il a été si difficile à isoler.
Diagnostic
Au début, il nous a semblé clair, étant donné le calendrier et la nature persistante du problème, que la source du problème était une machine étudiante infectée (ou malveillante) faisant un empoisonnement du cache ARP. Cependant, les tentatives répétées d'isoler la source ont échoué. Ces tentatives incluent de nombreuses traces de paquets Wharkshark et même la mise hors ligne de bâtiments entiers pendant de courtes périodes. Nous n'avons même pas pu trouver une mauvaise entrée ARP de pistolet fumant. Ma meilleure estimation actuelle est un commutateur de base surchargé ou défaillant, mais je ne sais pas comment le tester, et le coût de le remplacer aveuglément est élevé.
Encore une fois, toutes les idées ont été appréciées.
Mise à jour: le
commutateur principal est remplacé. Après 4 jours, tout se passe bien ... mais j'attendrai les deux semaines avant d'appeler le problème résolu.
mtrpeut être utile ici.