Bonjour à tous,
Ce mercredi 1 février au soir de 20h à 1h30 du matin le réseau de Rennes a subit de fortes perturbations. Celles-ci étaient dues à un très fort trafic de broadcast allant jusqu'à 60Mbps par moments. De plus la résolution du problème a été entravée par la fait que nous effectuions une mise à jour des services DNS pour les réseaux d'administration. L'incident a été finalement endigué en coupant les ports fautifs, cependant à l'heure actuelle nous n'avons toujours pas trouvé la cause première du problème.
Voici une description des événements détectés et des actions menées :
18h détection initiale du problème
À cette heure-ci, l'administrateur sur Rennes détecte des taux de pertes de paquets très élevés vers internet (environ 40%), ceci étant confirmé par la réception sur le support (support-rennes@resel.fr) de mails confirmant un dysfonctionnement important.
Ayant précédemment des problèmes avec l'interconnexion vers notre opérateur nous avons initialement pensé à un problème de ce type (comme l'incident du 12 janvier).
20h30 : connexion de secours
Nous basculons sur la connexion de secours (passant par la DISI de l'école) en espérant que cela résolve temporairement le problème
20h40 : Origine du problème dans le réseau utilisateur
Le problème n'est pas résolu, nous commençons donc à enquêter sur le réseau local. La seconde thèse était un problème dans l'hyperviseur principal qui avait des problèmes de disques sévères la veille. Cependant, après de maigres recherches cette thèse a été vite écartée. Toutes les métriques semblent indiquer un problème dans le réseau utilisateurs.
22h40 : Confirmation d'un problème de boucle réseau
Après avoir lancé des outils d'analyses nous avons pu observer que le problème venait d'un très fort trafic (allant jusqu'à 60Mbps) sur l'ensemble des ports sortant des switchs d'accès ceci dans le bâtiment des chambres et le bâtiment des studios. Nous avons donc priorisé la thèse d'un broadcast très important. Nous nous lançons donc dans la recherche de l'origine de ce broadcast.
23h10 : Thèse d'une défaillance des switchs
Après une étude plus détaillée des paquets en circulation sur le réseau nous constatons que les trames envoyées ne sont pas uniquement du broadcast, mais l'ensemble des paquets utilisateurs. De plus nous détectons 2 ports sur les switchs qui semblent suspects (envoyant beaucoup de données)
00h30 : redémarrage des services
Suspectant un bug dans les switchs à 00h30 nous décidons de redémarrer l'ensemble des switchs. Après quelques minutes d'attente, nous avons constaté aucun changement.
01h30 : bloquage des ports suspects
Nous décidons après avoir analysé le reste des données que nous avions en notre possession de couper les ports considérés comme suspects sur les switchs. Cela a totalement résolu le problème. Et le trafic interne est redescendu à des niveaux normaux.
À l'heure actuelle la situation est stable.