Network Troubleshooting Methodology - The Systematic Approach
Méthode de dépannage du réseau: l'approche systématique
Pourquoi la méthodologie compte
Le problème: Une application de base de données est "slow". L'équipe réseau accuse l'équipe serveur. L'équipe serveur accuse le réseau. Pendant ce temps, les utilisateurs sont frustrés, et les heures sont gaspillées dans le débogage circulaire.
La solution : Une approche systématique et scientifique du dépannage qui utilise des preuves et non des hypothèses pour identifier les causes profondes.
Le coût du dépannage hasardeux : Temps perdu, corrections incorrectes qui masquent les problèmes réels, doigtage entre les équipes, et l'expérience utilisateur dégradée.
Introduction : La méthode scientifique appliquée au réseautage
Le dépannage en réseau est fondamentalement un exercice dans la méthode scientifique:
- Observer les symptômes et collecte des données
- Formuler une hypothèse à propos de la cause racine
- Tester l'hypothèse avec outils de diagnostic
- Analyser les résultats et confirmer ou rejeter l'hypothèse
- Mettre en œuvre une correction basé sur la cause racinaire confirmée
- Vérifier le problème est résolu
Cet article fournit un cadre structuré pour le dépannage réseau qui empêche les pièges communs comme:
- Préjugé de confirmation (à la recherche de preuves qui étayent votre hypothèse initiale)
- Changements aléatoires sans diagnostic (approche "spray et prier")
- Correction des symptômes au lieu des causes profondes
- Débogue circulaire sans documenter ce qui a été essayé
Les cinq questions clés
Avant de plonger dans les diagnostics techniques, répondez à ces cinq questions critiques pour limiter votre champ d'investigation:
Changements de configuration ? Nouveau matériel ? Des mises à jour logicielles ? Des modifications topologiques ?
- Vérifier les registres de gestion du changement
- Examiner les engagements récents dans les systèmes de gestion de configuration
- Demandez : "Ça a fonctionné hier ?"
Un seul utilisateur ? Un bâtiment ? Tout le monde ? Demande spécifique seulement?
- Un dispositif: Probablement un problème local (NIC, câble, configuration)
- Un sous-net : Problème de passerelle, de DHCP ou de commutateur
- Tout le monde : Infrastructure de base, FSI ou problème généralisé
- Application spécifique: Serveur d'application, règle de pare-feu ou DNS
Ça arrive tout le temps ? Seulement pendant certaines heures ? Des événements aléatoires ?
- Constante : Défaillance dure (coupe de câble, erreur de configuration, service en panne)
- Délai : Congestion pendant les heures d'ouverture, processus programmés
- Intermittent/Random: Désaccord duplex, matériel défaillant, liaison intermittente
Pouvez-vous déclencher le problème sur demande ?
- Oui : Bien plus facile à diagnostiquer (peut tester des hypothèses)
- Numéro: Mettre en place une surveillance/un enregistrement et attendre la récurrence
Vérifiez les deux extrémités de la connexion
- Perspective client vs perspective serveur
- Capture des paquets à la source par rapport à la destination
- Un routage asymétrique ? Différents chemins pour envoyer vs recevoir?
L'approche diagnostique fondée sur le modèle de l'OSI
Le modèle OSI fournit un cadre structuré pour le dépannage. Travaillez à partir de la couche 1 (physique) vers le haut, ou de la couche 7 (Application) vers le bas, selon les symptômes.
Approche ascendante (layer 1 → calque 7)
Quand utiliser: Perte complète de connectivité, aucun lien de lumière, ou symptômes de couche physique
- Check: Câble connecté? Des lumières de liaison allumées ? Fibre propre ?
- Commandes :
show interfaces,ethtool eth0 - Rechercher: erreurs CRC, collisions, collisions tardives, runts, géants
- VLAN correct ? Port activé ? Le blocage du STP ?
- Commandes :
show mac address-table,show spanning-tree - Rechercher: MAC flapping, changements de topologie STP, erreurs VLAN
- Check: Ping par défaut passerelle? La table d'acheminement est correcte ?
- Commandes :
ping,traceroute,show ip route - Rechercher: Routes manquantes, next-hop incorrecte, boucles de routage
- Vérifier : peut établir la connexion TCP ? Pare-feu ?
- Commandes :
telnet host port,netstat -an, capture de paquets - Rechercher : retransmissions TCP, zéro fenêtre, paquets RST
- Vérification : résolution DNS ? Réponse à la demande? L'authentification fonctionne ?
- Commandes :
nslookup,dig,curl -v - Rechercher: pannes DNS, erreurs d'application, problèmes de timeout
Approche descendante (Layer 7 → Calque 1)
Quand utiliser: Problèmes spécifiques à l'application lorsque la connectivité de base existe
Commencer au calque 7 (Le service SharePoint fonctionne-t-il? DNS résolution pour corriger IP?) et ne travailler que si nécessaire.
L'arbre de décision: est-ce la couche 1, 2 ou 3?
Utilisez cet arbre de diagnostic rapide pour identifier quelle couche est défaillante:
La pile TCP/IP ne fonctionne pas. Vérifiez les services OS, réinstallez les pilotes réseau.
CNI désactivé, mauvais conducteur, câble débranché. Vérification : ip link show ou Gestionnaire de périphériques
Vérification : Câble physique, état du port de commutation, affectation VLAN, table ARP
Vérification : table de routage, règles de pare-feu, ACL. Utilisation traceroute pour trouver où les paquets s'arrêtent
Vérifier: paramètres du serveur DNS, disponibilité du serveur DNS, port de blocage du pare-feu 53
Check: Règles de pare-feu, groupes de sécurité, service d'écoute sur le port
Le problème est avec l'application elle-même, l'authentification, ou la configuration de l'application
Techniques d'isolement
Lorsque vous avez une hypothèse sur la cause racine, utilisez ces techniques d'isolement pour confirmer ou rejeter :
1. Remplacer les composants de façon systématique
- Câble de patch d'échange avec un câble bien connu
- Essai sur un port de commutation différent
- Essayez différents NIC (ou adaptateur réseau USB)
- Test à partir de différents appareils client
- Déplacer vers différents VLAN/sous-net
2. Captures de paquets à plusieurs points
Capturer le trafic à la source, aux points intermédiaires et à la destination pour identifier où les paquets sont déposés ou modifiés:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
3. Essai de retour de boucle
Éliminer les variables externes en testant la connectivité au sein d'un seul appareil :
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
4. Comparaisons de référence connues et bonnes
Comparer la configuration et le comportement avec un système de travail:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
Documentation pendant le dépannage
La documentation adéquate empêche le débogage circulaire où vous essayez la même chose plusieurs fois sans la réaliser.
Modèle de dépannage
Issue ID: TICKET-12345
Date/Time: 2026-02-02 14:30 UTC
Reported By: Jane Smith (jane.smith@company.com)
Affected Users: ~50 users in Building A, 3rd floor
Symptom: Cannot access file server \\fileserver01
Initial Observations:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Tests Performed:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Root Cause:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Resolution:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Verification:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Time to Resolution: 25 minutes
Études de cas sur le monde réel
Étude de cas 1: "Le réseau est lent" (En fait: Épuisement de la fenêtre TCP)
Symptôme
Temps de réponse de l'application de base de données dégradé de <100ms à 5+ secondes. L'équipe d'application a blâmé la latence du réseau.
Hypothèses initiales
- Engorgement des réseaux
- Lien WAN saturé
- Goulets d'étranglement des pare-feu
Processus diagnostique
- Essai de ping: RTT = 2ms (excellent, écarte la latence de la couche 3)
- Essai de largeur de bande (iperf): 950 Mbps sur 1 Gbps (pas de congestion)
- Capture des paquets: Revealed TCP Zero Window paquets à partir du serveur de base de données
- Contrôle du serveur : Serveur de base de données recevoir des tampons = 64Ko (tiny!)
Cause
Les tampons OS du serveur de base de données étaient trop petits pour un produit à haut débit × retard. La fenêtre TCP se remplirait, forçant l'expéditeur à attendre.
Résolution
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Leçon apprise
Ne supposez pas : "Slow" ne signifie pas toujours "latence réseau". Recueillir toujours des preuves (pour la latence, capture de paquets pour le comportement) avant de sauter aux conclusions.
Étude de cas 2: Connectivité intermittente (En fait: Duplex Mismatch)
Symptom
La connexion du serveur tomberait au hasard, surtout sous charge. Parfois, ça fonctionnait bien, parfois complètement insensible.
Initial Assumptions (Wrong)
- À défaut de CNI
- Mauvais câble
- Problème matériel de commutation
Diagnostic Process
- Contrôle de l'interface: Serveur NIC = 1000/Full, Switch port = 1000/Half (mismatch!)
- Compteurs d'erreurs : Nombre de collisions massives sur le port de l'interrupteur
- collisions tardives: Indicateur d'inadéquation des duplex
Root Cause
La négociation automatique a échoué. Serveur négocié plein duplex, le commutateur est retombé à moitié duplex. Les collisions n'ont eu lieu que lorsque les deux côtés ont essayé de transmettre simultanément.
Resolution
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Lesson Learned
Vérifiez les deux extrémités : L'état de l'interface montre les paramètres négociés. Une inadéquation signifie que l'autonégociation a échoué. Toujours code dur vitesse/duplex pour les serveurs.
Étude de cas 3: « Ne peut pas atteindre certains sites Web » (En fait: MTU/PMTUD Trou noir)
Symptom
Les utilisateurs pouvaient naviguer sur certains sites Web (Google, Yahoo) mais pas sur d'autres (site bancaire, portail d'entreprise). Les petites requêtes HTTP ont fonctionné, de grandes pages ont été chronométrées.
Initial Assumptions (Wrong)
- Numéro DNS
- Pare-feu bloquant des sites spécifiques
- Problème de routage des FAI
Diagnostic Process
- Résolution DNS: Fonctionne bien pour tous les sites
- Essai de ping: Peut ping les sites « inaccessibles »
- Petite requête HTTP (courl): Œuvres pour petites pages
- Grand téléchargement : Stalls après la poignée de main TCP
-
Essai MTU:
ping -M do -s 1472réussit,ping -M do -s 1473échoue - Surveillance de l ' ICMP: Aucun message "Fragmentation nécessaire" (code de type 3 4) reçu
Root Cause
Le tunnel VPN a réduit le MTU à 1400, mais le pare-feu bloquant les messages ICMP "Fragmentation Needed". Path MTU Discovery (PMTUD) ne pouvait pas fonctionner, créant un trou noir MTU. Les petits paquets s'ajustent, les grands paquets avec le jeu de bits DF ont été laissés tomber silencieusement.
Resolution
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Lesson Learned
Taille: Si les petites demandes de travail mais les grands transferts échouent, soupçonnez les problèmes de MTU/fragmentation. Utilisez ping avec DF bit pour tester le chemin MTU.
Étude de cas 4 : Questions relatives à la qualité des services VoIP (en fait : erreur de configuration QoS)
Symptom
Les appels vocaux avaient un son hidpy, des abandons intermittents. Seulement pendant les heures d'ouverture (9h-17h).
Initial Assumptions (Wrong)
- Bande passante insuffisante
- Serveur VoIP surchargé
- Qualité de la connexion ISP
Diagnostic Process
- Essai de la largeur de bande: Lien seulement 40% utilisé pendant l'heure chargée
- Contrôle QoS: Trafic vocal marqué avec DSCP EF (46) correctement
- Contrôle des files d'attente: La file d'attente vocale n'avait que 5% de bande passante (devrait être 33%).
- Capture des paquets: Les paquets de voix sont abandonnés pendant la congestion
Root Cause
La politique de QoS existait, mais l'attribution de la bande passante était inversée : le meilleur effort a obtenu 60%, la voix a obtenu 5%. Pendant les heures d'ouverture où le trafic de données a augmenté, les paquets vocaux ont été supprimés en raison du débordement de file d'attente.
Resolution
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Lesson Learned
Questions liées au temps = capacité : Si les problèmes se produisent seulement pendant les heures chargées, ce n'est pas un échec dur, mais un problème de capacité/QoS. Vérifiez les statistiques de file d'attente, pas seulement la bande passante totale.
Référence de commande par Symptom
| Symptôme | Calque | Commandes à exécuter | Que chercher |
|---|---|---|---|
| Pas de lumière de lien | Couche 1 | show interfaces |
Statut: vers le bas, aucun support, câble débranché |
| Perte de paquets | Couche 1/2 | show interfaces |
Erreurs CRC, runs, géants, collisions, collisions tardives |
| Impossible de pinger la passerelle | Calque 2 | arp -a |
Pas d'entrée ARP, MAC non appris, blocage STP |
| Impossible d'atteindre le sous-réseau distant | Couche 3 | traceroute |
Route manquante, pas du tout, boucle de routage |
| Connexion refusée | Couche 4 | telnet host port |
Service non-écoute, pare-feu, TCP RST |
| Performance lente | Couche 4+ | ping (RTT) |
Haute latence, limite de bande passante, retransmissions TCP, zéro fenêtre |
| Impossible de résoudre le nom d'hôte | Couche 7 | nslookup |
Serveur DNS inaccessible, mauvaise configuration DNS, NXDOMAIN |
| Gouttes intermittentes | Layer 1/2 | ping -f (flood) |
Désaccord duplex, câble défaillant, reconvergence STP |
| Fonctionne parfois, pas d'autres | Nombreux | Extended ping |
Problème d'équilibrage de charge, asymétrie ECMP, débordement de table d'état |
Quand escalader
Savoir quand passer au TAC du fournisseur ou aux ingénieurs supérieurs. Accélérer lorsque:
- Vous avez épuisé toutes les étapes du dépannage dans votre base de connaissances
- Question nécessite accès / permissions que vous n'avez pas
- Problème impliquant un bug logiciel fournisseur ou défaut matériel
- L'impact sur les entreprises est critique et tient compte du temps
- Plusieurs équipes doivent collaborer (application + réseau + serveur)
- Description complète des symptômes
- Calendrier du début de l'émission
- Commandes diagnostiques exécutées et leur sortie
- Sauvegardes de configuration
- Captures de paquets (le cas échéant)
- Ce que vous avez déjà essayé
Bâtir votre base de connaissances personnelles
Chaque séance de dépannage est une occasion d'apprentissage. Bâtir une base de connaissances personnelles :
1. Créer un journal de dépannage
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
2. Construire une feuille de chauffage de commande
Organisez les commandes fréquemment utilisées par scénario pour une référence rapide lors du dépannage.
3. Documenter votre réseau
- Diagrammes topologiques (Layer 2 et Layer 3)
- Documentation du schéma d'adresse IP
- Affectations VLAN
- Configurations standard (templates)
- Bases de référence connues (statistiques d'interface avant les problèmes)
Anti-patterns courants à éviter
Ne pas faire de changements aléatoires sans diagnostic
Changer les configurations sans comprendre le problème aggrave souvent les choses ou masque le problème réel.
Si le réseau est toujours en panne
Souvent, les « problèmes de réseau » sont des problèmes d'application, de serveur ou de client. Recueillir des preuves avant d'accepter la faute.
N'EST PAS : Sautez la documentation de vos étapes de dépannage
Vous perdrez du temps à répéter les tests que vous avez déjà faits, ou ne pourrez pas expliquer à vos collègues ce que vous avez essayé.
Ignorer les problèmes intermittents
Les problèmes intermittents sont souvent des signes précurseurs d'échec imminent. Enquêtez-les avant qu'ils ne deviennent critiques.
Ne pas corriger les symptômes au lieu des causes profondes
Redémarrer un appareil peut restaurer le service, mais si vous ne trouvez pas pourquoi il a besoin de redémarrer, le problème se reproduira.
Résumé: Liste de contrôle pour le dépannage systématique
✓ Avant de commencer
- Répondez aux cinq questions clés (Qu'est-ce qui a changé? Qui est affecté ? Constant ou intermittent ? Reproductible ? Que voit l'autre côté?)
- Recueillir les premiers symptômes et les rapports des utilisateurs
- Vérifier les modifications ou la maintenance récentes
✓ pendant le dépannage
- Travaillez méthodiquement à travers les couches OSI (bottom-up ou top-down)
- Modifier une variable à la fois lors du test
- Documenter chaque test et son résultat
- Utilisez des captures de paquets pour voir le comportement réel du trafic
- Comparer avec les valeurs de référence connues
✓ Après résolution
- Vérifier si la correction a effectivement résolu le problème
- Documenter la cause profonde et la résolution
- Mettre à jour votre base de connaissances
- Si la configuration a changé, mettre à jour la documentation
- Considérons ceci : La surveillance aurait-elle pu l'être plus tôt?
Conclusion
Le dépannage en réseau est à la fois science et art. La science suit une méthodologie systématique, utilisant des outils de diagnostic correctement et comprenant des protocoles. L'art est de savoir quels tests à exécuter d'abord en fonction des symptômes, en reconnaissant les modèles de l'expérience, et de savoir quand à escalader.
En suivant l'approche systématique décrite dans cet article – poser les bonnes questions, travailler méthodiquement à travers le modèle de l'OSI, documenter vos étapes et apprendre de chaque question – vous deviendrez plus efficace dans le dépannage et éviterez les pièges communs qui conduisent à perdre du temps et des corrections incorrectes.
Rappelez-vous : Le but n'est pas seulement de restaurer le service, mais de comprendre pourquoi il a échoué afin que vous puissiez l'empêcher de se reproduire.
Dernière mise à jour: février 2, 2026.