Méthode : diviser le domaine de panne
Structurer un diagnostic réseau en isolant méthodiquement la couche fautive avant d'agir.
À retenir
- Diviser le domaine de panne par dichotomie évite les tests au hasard.
- Le modèle OSI structure le diagnostic couche par couche, sans en sauter aucune.
- traceroute isole les frontières de responsabilité mais ne prouve pas seul la cause.
- Documenter chaque test en temps réel accélère l'escalade et évite les répétitions.
Pourquoi diviser avant de dépanner
Face à une panne réseau, le réflexe naturel est de tester « au hasard » l'équipement le plus suspect. Cette approche fait perdre du temps et multiplie les changements non maîtrisés. La méthode professionnelle consiste à diviser le domaine de panne en deux, encore et encore, jusqu'à isoler le segment ou la couche responsable — une dichotomie proche de celle utilisée en dépannage logiciel.
Le modèle en couches comme guide
Le modèle OSI reste l'outil mental le plus efficace pour cadrer un incident :
- Couche 1 (physique) : câble débranché, port administrativement down, SFP défectueux, LED d'état.
- Couche 2 (liaison) : VLAN mal assigné, boucle, tempête de broadcast, erreurs CRC.
- Couche 3 (réseau) : routage absent, table de routage incohérente, ACL bloquante, MTU.
- Couche 4-7 : port applicatif fermé, certificat expiré, latence applicative.
Point clé
ne jamais sauter une couche. Un symptôme applicatif (timeout HTTP) peut avoir sa cause réelle en couche 1 (erreurs CRC qui dégradent silencieusement le débit utile).
Arbre de décision minimal
Le service est-il inaccessible pour TOUS les utilisateurs ?
├─ Oui → tester depuis le switch/routeur du service (couche 3 locale)
│ ├─ ping local OK → panne en amont (WAN, pare-feu, DNS)
│ └─ ping local KO → panne locale (câble, VLAN, port)
└─ Non (certains OK) → comparer les chemins réseau des deux groupes
→ chercher une asymétrie de routage ou un ECMP déséquilibré
Diviser le chemin réseau
L'outil de base pour diviser un chemin de bout en bout est traceroute (ou tracert sous Windows) :
traceroute -n 10.20.0.50
Chaque saut affiché correspond à une frontière de responsabilité potentielle. Un saut qui ne répond pas n'est pas forcément en panne (ICMP souvent filtré) : il faut confirmer avec un test de bout en bout au-delà de ce saut avant de conclure.
Attention
un traceroute qui « s'arrête » à un routeur ne prouve pas que ce routeur est en cause — beaucoup d'équipements dépriorisent ou bloquent le TTL-exceeded ICMP par politique de sécurité.
Documenter au fur et à mesure
Chaque test doit être noté avec l'heure, la commande exacte et le résultat brut. Cette discipline paraît lourde en pleine crise, mais elle évite de repasser deux fois par la même hypothèse et facilite l'escalade vers un niveau 3 ou un support constructeur.
Sur le terrain
en astreinte de nuit, la première question à se poser est « depuis quand ? » et « qu'est-ce qui a changé ? ». Un changement de configuration récent (déploiement, bascule d'alimentation, mise à jour) est la cause la plus fréquente d'incident, bien avant la panne matérielle spontanée.
Astuce
gardez toujours une topologie logique à jour (VLANs, IP, chemins redondants) imprimée ou accessible hors bande — en cas de panne réseau totale, l'outil de documentation en ligne peut lui-même devenir inaccessible.