Simulations de pannes chronométrées
S'entraîner à diagnostiquer sous pression des scénarios courants : MTU, boucles et tempêtes de broadcast.
À retenir
- Un MTU insuffisant se manifeste par un blocage sélectif des gros transferts, pas des petites connexions.
- Une même MAC vue sur plusieurs ports en alternance signale une boucle active.
- Le storm-control limite l'impact d'une tempête de broadcast sans remplacer Spanning Tree.
- Comparer le taux d'erreurs au débit reçu objective une dégradation physique progressive.
- S'entraîner chronométré sur des scénarios réalistes prépare à l'astreinte réelle.
S'entraîner comme en astreinte réelle
La compétence de dépannage se construit par répétition sous contrainte de temps. Voici trois scénarios classiques à simuler, chronomètre en main, avec la méthode couche par couche du module 1.
Scénario 1 : problème de MTU et fragmentation
Symptôme typique : les connexions SSH fonctionnent mais les gros transferts (VPN IPsec, HTTPS avec gros objets) se bloquent ou traînent. C'est la signature classique d'un problème de MTU sur un tunnel ou une liaison intermédiaire qui ne supporte pas la fragmentation (souvent parce que le bit Don't Fragment est positionné).
ping -M do -s 1472 10.20.0.50
Si ce ping échoue mais qu'un ping avec une taille de paquet plus petite (par exemple 1400) réussit, le MTU effectif du chemin est inférieur à 1500 octets quelque part sur le trajet. Diminuer progressivement la taille testée permet de trouver le MTU réel du chemin (path MTU discovery manuel).
Point clé
un tunnel VPN ou VXLAN ajoute un surcoût d'en-têtes (souvent 50 à 100 octets) ; si le MTU physique n'est pas augmenté en conséquence, les paquets encapsulés dépassent la taille maximale et sont fragmentés ou rejetés.
Scénario 2 : boucle réseau et tempête de broadcast
Symptôme : la latence explose sur tout un segment, les switches affichent une charge CPU anormale, et les tables MAC oscillent entre plusieurs ports pour une même adresse.
show spanning-tree
show mac address-table | include <mac_suspecte>
Une même adresse MAC vue alternativement sur deux ports différents en quelques secondes est un signal fort de boucle. Vérifiez ensuite que Spanning Tree (ou une alternative comme MLAG bien configuré) est actif sur tous les ports concernés — un port en mode trunk connecté par erreur à un autre switch sans STP actif est la cause la plus fréquente.
show interface counters errors
Une tempête de broadcast se traduit par une explosion du compteur de trames broadcast/multicast reçues sur plusieurs ports simultanément. Le storm-control, s'il est configuré, limite l'impact en coupant temporairement le port qui dépasse le seuil.
Attention
désactiver Spanning Tree pour « résoudre rapidement » un flapping de port est une fausse bonne idée : cela supprime la protection contre les boucles et transforme un incident local en panne générale du segment.
Scénario 3 : dégradation progressive liée aux erreurs physiques
show interface | include errors|CRC|input rate
Comparez le taux d'erreurs au débit reçu : un ratio d'erreurs supérieur à 0,1 % justifie une inspection physique (connecteur, longueur de câble, SFP hors spécification pour la distance).
Sur le terrain
simulez ces trois scénarios en environnement de test (ou en laboratoire virtuel type EVE-NG/GNS3) avec un objectif de moins de 15 minutes pour poser un diagnostic argumenté ; c'est le temps moyen toléré avant qu'un incident de production ne déclenche une escalade managériale.
Astuce
conservez une checklist personnelle des 5 commandes à lancer en premier sur tout incident — la rapidité en astreinte vient de l'automatisme, pas de l'improvisation.