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.
Le dépannage en réseau est fondamentalement un exercice dans la méthode scientifique:
Cet article fournit un cadre structuré pour le dépannage réseau qui empêche les pièges communs comme:
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 ?
Un seul utilisateur ? Un bâtiment ? Tout le monde ? Demande spécifique seulement?
Ça arrive tout le temps ? Seulement pendant certaines heures ? Des événements aléatoires ?
Pouvez-vous déclencher le problème sur demande ?
Vérifiez les deux extrémités de la connexion
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.
Quand utiliser: Perte complète de connectivité, aucun lien de lumière, ou symptômes de couche physique
show interfaces, ethtool eth0show mac address-table, show spanning-treeping, traceroute, show ip routetelnet host port, netstat -an, capture de paquetsnslookup, dig, curl -vQuand 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.
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
Lorsque vous avez une hypothèse sur la cause racine, utilisez ces techniques d'isolement pour confirmer ou rejeter :
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
É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
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")
La documentation adéquate empêche le débogage circulaire où vous essayez la même chose plusieurs fois sans la réaliser.
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
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.
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.
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
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.
La connexion du serveur tomberait au hasard, surtout sous charge. Parfois, ça fonctionnait bien, parfois complètement insensible.
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.
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
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.
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.
ping -M do -s 1472 réussit, ping -M do -s 1473 échoueLe 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.
! 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
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.
Les appels vocaux avaient un son hidpy, des abandons intermittents. Seulement pendant les heures d'ouverture (9h-17h).
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.
! 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
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.
| 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 |
Savoir quand passer au TAC du fournisseur ou aux ingénieurs supérieurs. Accélérer lorsque:
Chaque séance de dépannage est une occasion d'apprentissage. Bâtir une base de connaissances personnelles :
# 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
Organisez les commandes fréquemment utilisées par scénario pour une référence rapide lors du dépannage.
Changer les configurations sans comprendre le problème aggrave souvent les choses ou masque le problème réel.
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.
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é.
Les problèmes intermittents sont souvent des signes précurseurs d'échec imminent. Enquêtez-les avant qu'ils ne deviennent critiques.
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.
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.