Bonjour à tous,
 
 
Hier nous avons eux une panne générale réseau, plus aucun accès à nos serveurs, téléphonie sur IP etc...  
Des pings qui fonctionnaient pendant 2s puis coupés 30s puis revenaient etc... bref le truc bien galère à diagnostiqué.
Un d'un coup tout est revenu sans rien faire.
 
 
J'ai aujourd'hui en schéma réseau (j'ai fait un schéma simple vite fait), les switchs sont dans la même salle, j'ai repris l'infra donc rien de modifié historiquement dessus :
 
 

 
 
Donc mes serveurs arrivent sur les switchs de droite qui sont stackés, et ça repart sur le premier switch clients, et sont cascadé.  
Le soucis, si mon premier switch me lâche, je perds tout. J'avais pensé faire comme ça, mais j'essai d'imaginé si l'idée est bonne et l'impacte que ça pourrait avoir :
 
 

 
 
 
Il y a aucun intérêt pour que les pcs communiquent entre eux, donc le trafic avec le switch serveur, ne devrait être qu'en mode client/serveur.
 
 
Qu'en pensez-vous ?
Avez-vous une petite idée sinon, de ce qui peux causé des coupures complètes et aléatoire sur des switchs ?
 
 
En vous remerciant par avance

pour la panne, à tout hasard : un utilisateur qui aurait fait une boucle sur le réseau, pas de spanning tree et une grosse tempête qui sature les équipements ?
 
comme axe d'amélioration, s'il y a des ports réseau libres sur les ESX tu peux faire une aggregation de lien. Ca nécessiterait de placer les serveurs sur la stack et les pc sur les switchs solo "de distribution", mais en cas de panne seuls quelques utilisateurs seraient impactés.

J'ai pensé effectivement à une merde d'un pc, ce qui est bizarre, c'est quand j'ai éteint mes switchs c'est reparti niquel 5min et retombé juste après. Le bordel a durée 1h30 au total, et ce matin aucun soucis par exemple.
 
Pour la partie amélioration, je l'ai pas indiqué sur le schéma, mais les 4 ports giga de mes ESX sont aggrégés. J'ai juste fait un réseau simple. Mais c'est surtout, l'impacte du schéma N2 par rapport au 1 qui me fait douter.
 
Car pour moi comme ça, le réseau 2 aurait le mérite de perdre au pire un switch client, mais pas la cascade complète si le 1 lâche, et d'éviter de communiquer entre eux pour rien aussi.

Pas d'idée sur une évolution du schéma 1 vers le 2 ?

Oubli le schéma 2, tu as un magnifique SPOF dessus

Attention sur le schéma 2, tu as l'impression qu'il y a qu'un switch principal qui distribue tout, mais les deux switchs de gauche sont stackés, donc réellement tu as une redondance dessus. Un 3eme switch serveur est en commande actuellement en supplément d'ailleurs.

il faudrait que les schémas correspondent le + possible à la réalité : y'a qu'avec ca qu'on comprend ton infra !  
 
si tu as 4 switchs stackés et une aggregation de lien sur 4 ports pour les ESX, j'y vois une jolie coincidence !

" si tu as 4 switchs stackés et une aggregation de lien sur 4 ports pour les ESX, j'y vois une jolie coincidence ! "
 
Aujourd'hui uniquement les deux switchs de gauche sont stackés, et les 4 ports des ESXs ont une agrégation, mais ça depuis 2 ans déjà.

Ca change rien au spof ... Tu avais un SPOF dans le schema 1 sur tes switchs de droite, sur le schema 2 tu as un spof pour X de tes switch suivant lequel tombe dans ton stack.
 
Le stack ca n'est pas une sécurité, plus une commodité de gestion. Mais si tu perds le switch du stack sur lequel est branché un truc, l'autre switch va pas prendre le relais comme par magie

aller pour faire simple, en partant de ton Schema 1, tu déplace un câble et du créé un LAG. Le mieux serait aussi de boucler à droite ... Mais celà à peu d'intérêt par rapport au temps que tu vas mettre

Faire un lag par exemple de mes ESX avec :
 
2 câbles RJ sur le premier switch de gauche, et les 2 autre sur celui du dessous. Est ce que je perd niveau perf plutôt que les 4 en LAG sur le de switch ?

Non. Mais tu gagnes en résilience.
 
C'est pas compliqué le réseau local et le double attachement. Mais ca peut vite devenir le bordel si on ne couche pas les infos sur le papier.
 
Du coup je te propose d'écrire quel est ton objectif précis (haute dispo de bout en bout, supprimer spof sur un switch etc) et faire un plan de ce que tu penses faire puis de nous le soumettre.

Cette solution (LAG) n'est possible que si les 4 switchs de droite sont un stack (donc pas des switchs unitaires isolés).
Sinon, il faut faire du spanning-tree.

ah oui juste !

Donc le mieux serait un peu ce format la ? :
 

 
 
 
Par ailleurs j'ai un doute sur le stacking, la communication des ESX par exemple qui sont partagés sur les switchs de gauche, passent bien par le lien de stack ?

Va vraiment falloir faire gaffe au spanning tree.
 
perso je garderais mon schema juste en supprimant le lag, et en interconnectant les 2 "piles" gauche et droite.
 
Concernant ta question sur le stack, oui, car la correspondance ARP sur le stack fait le job.

" Concernant ta question sur le stack, oui, car la correspondance ARP sur le stack fait le job."
 
J'avais un doute, sinon je me demandais pourquoi faire du stacking si ça faisait pas au moins ça (mise à part la gestion).
 
Pour spanning tree, j'ai 3 switchs côté clients qui ne doivent pas le supporter par contre. Sinon j'ai refait ton schéma au final

Le stack apporte d'autres trucs, comme par éxemple la possibilité de faire des lag entre plusieurs équipements permettant de contrecarré un SPOF ... Mais le Stack en lui même ... C'est juste de la perf et de la gestion