STP et déconnexions intermittentes - Réseaux - Systèmes & Réseaux Pro
Marsh Posté le 21-10-2012 à 08:57:16
Je dirais même plus, prends toi le temps de comprendre comment ton réseau fonctionne au niveau physique, mets toi devant tes switchs et regarde comment le tout est relié.
Marsh Posté le 26-10-2012 à 10:48:24
Merci à vous.
En effet, rien de cela n'existe : juste une liste d'adresses IP/Mac à peine mises à jour. Aucun plan filaire ou schéma, des rajouts, du 10baseT au 100 puis GbE, pas de logiciel d'administration. J'en passe et des meilleures. Des liens doublons inutiles entre switchs ont bien été supprimés.
J'avais conscience de demander beaucoup avec peu d'informations. J'espère néanmoins que vous n'avez pas eu l'impression que je vous demandais de faire mon boulot à ma place.
Je voulais d'abord m'assurer que seule une immense boucle pouvait provoquer cela.
J'avais déjà commencé à analyser l'activité port par port. C'est la raison de cette réponse tardive. De plus, l'analyse n'est pas toujours facile puisqu'elle devrait se faire plusieurs fois pour s'abstraire du long passé sans reboot et des 'tours de cadrans' des compteurs (taux de drops à 229 %...).
Il en ressort de multiples problèmes, dont je vous épargnerais la liste exhaustive, quelques exemples principaux :
- des ports avec un nombre de paquets 'droppés' très important, pour certaines machines connectées en 10 Mbps 2 paires (eh oui...) et malgré l'auto-négo => forçage en 10HDx.
- des machines éteintes mais ports bloqués temporairement par STP. Des machines éteintes continuent d'envoyer des paquets. J'en ai débranchée une : plus d'émission.
- vu aussi des ports connectés à une machine arrêtée: rien en réception, mais émettant des paquets, pas d'@Mac sur les ports ?
- nombre élevé de paquets trop grands sur une bonne partie des ports d'un cluster (alors que le Jumbo n'est pas paramétré).
A terme, je vais installer un logiciel du genre Icinga/Nagios qui me permettra d'y voir un peu plus clair.
En vous remerciant par avance.
Marsh Posté le 26-10-2012 à 11:08:56
Tu peux pas te faire preter, louer ou acheter un Fluke (genre optiview) pour te dépatouiller ?
Marsh Posté le 26-10-2012 à 11:40:23
'connaissais pas.
Cela a l'air vraiment top en effet. Je vais voir la possibilité de m'en fournir un. Sinon ou en attendant, Nagios + Wireshark, p.ex., ne peuvent-ils pas faire de même ?
Marsh Posté le 26-10-2012 à 13:01:42
Arghl... ça m'a fait comme si j'avais avalé un sushi dans le sens de la largeur.
Marsh Posté le 26-10-2012 à 13:48:07
Et oui, à partir de 20k€
J'en ai un et je peux te dire que c'est génial comme matos.
Marsh Posté le 26-10-2012 à 23:54:22
J'ai quand même l'impression que tu te disperses en essayant de tout résoudre en même temps.
La priorité c'est de faire la cartographie du réseau car sans schéma à jour tu ne peux rien faire.
en second lieu, pour moi, c'est une belle boulette d'activer le STP sur un réseau que tu ne maitrises pas (déjà que quand on connait le réseau le STP c'est une belle merde à dépanner).
De plus il suffit qu'un seul switch ne gère pas le STP pour foutre un réseau en l'air.
Pour résoudre une boucle sur un réseau non maitrisé, tu parts du switch de tête et tu débranches tout les liens d’interconnexions. Ensuite tu remets les liens un à un en notant où ça va et si le comportement du réseau se dégrade ou pas à chaque fois que tu rebranches un lien.
Un fois ta carto établie et le fait que tu n'as pas de boucle, tu peux t'attaquer au déverminage des stations.
Marsh Posté le 27-10-2012 à 16:47:48
OUi, gros +1 !
Marsh Posté le 08-11-2012 à 17:52:00
Désolé, pour cette réponse tardive. Tu as tout à fait raison. Merci pour cette remise à l'endroit du/des problèmes.
Le STP activé (sur tous les switchs manageables) est un pis-aller provisoire. Car quand je vois le nombre de blocages incessants, le résseau sans cela, s'écroulerait, en un rien de temps, non ? Si je prends le problème par le mauvais bout, c'est parce que ma marge de manoeuvre est faible (l'explication n'aurait aucun intérêt ici).
Ma cartographie/inventaire sont en cours, je pars de loin. Je n'administre pas tout une partie du parc de machines, pour des histoires d'ego, et j'ai découvert encore récemment des équipements ! Juste pour vous décrire, le passsif et, accessoirement aussi, mon niveau...
J'aurais une question avant de vous faire part de mes avancées.
J'ai donc dans les logs des switchs des évènements du type :
Citation : W 11/08/12 17:30:52 00331 FFI: port 11-High collision or drop rate. See help. |
Pourtant quand je regarde le tableau des ports avec leur statut, je n'ai que des liens en Forwarding ou disabled, pas de liens bloqués.
Je cite au passage une animation Flash de Cisco très instructive.
En vous remerciant.
Marsh Posté le 08-11-2012 à 22:38:58
Si tu as des collisions c'est que tu as des ports en half-duplex ce qui n'est pas habituel sur des switchs.
Les erreurs de CRC sont soit un câblage défectueux soit un problème de duplex, tout comme pour ce dernier problème, les collisions tardives (late collision).
Un problème de duplex c'est un port forcé en 100 full avec le port d'en face en auto-négociation. Comme ce dernier n'arrive pas négocier il passe en half duplex et là c'est la cata en terme de débits.
Marsh Posté le 09-11-2012 à 08:46:33
Isolation d'une partie du réseau au niveau physique puis remise a plat et tu fait tourner ?
Réseau qui tourne bien surchargé > réseau qui tourne sur 3 pattes. (en principe)
Mettons si tu as du spare en tête de réseau, tu utilise ce spare comme future tête, du le vérifie, le teste, le documente, et tu remonte tout sur ta nouvelle tête jusqu'a avoir un réseau propre de bout en bout ? Partir dans le vide comme ça, ça me parait un peu suicidaire. (pour ton avenir professionnel comme pour ton système)
Marsh Posté le 09-11-2012 à 18:21:28
Zostere a écrit : Si tu as des collisions c'est que tu as des ports en half-duplex ce qui n'est pas habituel sur des switchs. |
Il perd des BPDUs à cause des collisions donc STP instable.
Marsh Posté le 09-11-2012 à 18:29:16
Pour la perte des bpdus, faut voir si les collisions sont sur des ports isl, mais ça se pourrait bien.
Marsh Posté le 12-11-2012 à 10:11:32
En effet, merci pour ces mises au point. Il y a sans doute un cercle vicieux boucle -> collisions -> STP instable -> collisions, etc. Comme souligné par MystérieuseX et d'autres avant, un blocage des ports puis une remise en service progressive me permettra d'y voir plus clair.
Par contre, pas de ports ISL, il s'agit de switchs ProCurve.
Je ne manquerais pas de vous tenir au courant des suites de mes aventures.
En vous remerciant de suivre ce fil.
Marsh Posté le 11-10-2012 à 12:33:21
Le réseau de ma société est capricieux. J'ai l'impression qu'un problème en cache une multitude d'autres. En plus de mon manque d'expérience (voir mes précédents fils...), j'ai débarqué sans que je sois mis au courant des configs et problèmes.
Un des problèmes : entre un cluster de stockage utilisant l'algo de Nagle et les machines Mac OS avec le delayed TCP_ACK.
J'avais de nombreuses alarmes de divers types sur les switchs principaux. J'ai aussi mis en place le STP sur tous les switchs gérables (il ne l'était que sur 2/3 switchs...). Mais si j'ai moins d'alarmes, elles sont désormais consécutives au blocage aléatoire d'un port après l'autre.
De plus, en bougeant légèrement un câble sur un des switchs, une machine fût déconnectée par de multiples blocages STP.
Ce comportement suggère, vu la grande partie de réseau affectée, qu'il s'agirait alors d'une immense boucle ?
Merci par avance pour la compréhension et les conseils.