Dépanner un réseau : méthode et commandes show

Dépanner un réseau commuté et routé, c'est localiser une panne en vérifiant les couches dans l'ordre (le lien physique, puis le VLAN et le trunk, puis l'adressage et le routage, puis le filtrage) et en suivant le chemin du paquet d'un équipement à l'autre, avec les commandes show de chaque équipement. Ce chapitre donne la méthode, les commandes à connaître couche par couche, le catalogue des pannes classiques avec leur signature, et une étude de cas complète.

La méthode avant les commandes

Taper des commandes au hasard fait perdre du temps et en fait perdre aux autres. Une démarche en cinq temps :

1. Préciser le symptôme. Qui est touché (un poste, un VLAN, un site, tout le monde) ? Depuis quand ? Qu'est-ce qui a changé (une intervention, une mise à jour, un nouveau câble) ? Qu'est-ce qui fonctionne encore ? Une panne qui touche un seul poste et une panne qui touche tout un site ne se cherchent pas au même endroit.
2. Tracer le chemin. Sur le schéma, dessine le trajet du paquet de la source à la destination : chaque switch, chaque trunk, chaque passerelle, chaque routeur. Et le chemin du retour, qui n'est pas forcément le même.
3. Vérifier couche par couche, en partant du bas. Le lien est-il actif ? Le port est-il dans le bon VLAN, le VLAN passe-t-il sur les trunks ? Les adresses et les masques sont-ils justes ? Chaque routeur a-t-il une route, à l'aller et au retour ? Un filtre bloque-t-il ? Inutile de chercher une route manquante sur un câble débranché.
4. Couper le problème en deux. Un ping vers un point situé au milieu du chemin dit de quel côté se trouve la panne. On recommence sur la moitié fautive.
5. Corriger une chose à la fois, et vérifier. Après chaque modification, refais le test qui échouait. Note ce que tu changes : en cas d'erreur, tu sais revenir en arrière. Termine par le ticket : la cause, la correction, et ce qui évitera que ça recommence.

Côté postes (Windows et Linux : ipconfig, ping, tracert, Test-NetConnection), la méthode et les commandes sont dans le chapitre Diagnostic réseau du cours Réseaux. Ici, on se place sur les switchs et les routeurs.

Les commandes, couche par couche

Deux commandes de test complètent la liste :

• ping avec une source choisie : ping 10.40.0.10 source Vlan10 teste comme le ferait un poste du VLAN 10, donc aussi la route de retour vers ce VLAN ;
• traceroute : le dernier routeur qui répond est celui après lequel ça casse (ou celui qui ne sait pas où envoyer la suite).

Sur une session SSH, les messages du journal ne s'affichent pas par défaut : tape terminal monitor pour les voir arriver en direct.

Le catalogue des pannes classiques

Étude de cas : l'entrepôt qui ne joint plus l'application

Le ticket. Lundi 9 h 10 : « Depuis ce matin, les terminaux de scan de Saint-Priest affichent “serveur injoignable”. Au siège, l'application de gestion fonctionne. » Vendredi soir, un collègue a travaillé sur les ACL du siège.

1. Le symptôme. Tout l'entrepôt est touché, pas un seul terminal ; le siège fonctionne. La panne est donc entre Saint-Priest et srv-gestion (192.168.10.179), sur un équipement que le trafic du siège ne traverse pas de la même façon. Le changement de vendredi est un suspect.

2. Le chemin. Terminal (10.40.0.x) → R-STPRIEST (10.40.0.254) → lien vers Lyon → R-LYON → SW-COEUR → VLAN 20 → srv-gestion. Retour : srv-gestion → sa passerelle 192.168.10.190 (SW-COEUR) → R-LYON → R-STPRIEST.

3. Du bas vers le haut, en coupant en deux. Depuis un terminal, la passerelle 10.40.0.254 répond : le réseau local de l'entrepôt fonctionne. Sur R-STPRIEST, un test qui simule un terminal :

R-STPRIEST# ping 192.168.10.179 source GigabitEthernet0/0/2
.....
Success rate is 0 percent (0/5)
R-STPRIEST# ping 192.168.10.126 source GigabitEthernet0/0/2
!!!!!
Success rate is 100 percent (5/5)

La passerelle du VLAN 10 du siège répond, srv-gestion non : le routage entre les sites fonctionne dans les deux sens (OSPF n'est pas en cause), le problème est au siège, près du VLAN 20. Sur SW-COEUR :

SW-COEUR# show ip interface Vlan20 | include access list
  Outgoing access list is SERVEURS-OUT
  Inbound  access list is not set
SW-COEUR# show access-lists SERVEURS-OUT
Extended IP access list SERVEURS-OUT
    10 permit ip 192.168.10.0 0.0.0.255 192.168.10.176 0.0.0.15 (48211 matches)
    20 permit ip 10.30.0.0 0.0.1.255 192.168.10.176 0.0.0.15 (3120 matches)
    30 deny ip any any log (1874 matches)

Une ACL en sortie vers le VLAN 20, posée vendredi, n'autorise que le siège et Marseille. L'entrepôt (10.40.0.0/24) tombe sur la ligne 30, dont le compteur monte. Le journal confirme :

%SEC-6-IPACCESSLOGP: list SERVEURS-OUT denied tcp 10.40.0.31(50114) -> 192.168.10.179(443), 1 packet

4. La correction. On ajoute la ligne manquante, limitée à ce dont l'entrepôt a besoin :

SW-COEUR(config)# ip access-list extended SERVEURS-OUT
SW-COEUR(config-ext-nacl)# 25 permit tcp 10.40.0.0 0.0.0.255 host 192.168.10.179 eq 443

Le test depuis R-STPRIEST réussit, les terminaux retrouvent l'application.

5. Le ticket. Cause : ACL SERVEURS-OUT créée vendredi sans le réseau de l'entrepôt. Correction : ligne 25. Prévention : toute nouvelle ACL est construite à partir de la matrice des flux à jour, et testée depuis chaque site avant la fin de l'intervention.

Exercices

SW-ETAGE1# show interfaces status
Port      Name               Status       Vlan       Duplex  Speed Type
Gi1/0/16  Postes du 1er eta  connected    10         a-full a-1000 10/100/1000BaseTX
Gi1/0/17                     connected    1          a-full a-1000 10/100/1000BaseTX
Gi1/0/18  Postes du 1er eta  connected    10         a-full a-1000 10/100/1000BaseTX

interface GigabitEthernet1/0/17
 description Postes du 1er etage
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 50
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable

SW-ETAGE1# show interfaces GigabitEthernet1/0/9
GigabitEthernet1/0/9 is up, line protocol is up (connected)
  Half-duplex, 100Mb/s, media type is 10/100/1000BaseTX
  ...
     1528 input errors, 1490 CRC, 0 frame, 0 overrun, 0 ignored
     0 output errors, 312 collisions, 0 interface resets
     287 late collision, 0 deferred

SW-L3# show ip route
Default gateway is not set

Host               Gateway           Last Use    Total Uses  Interface
ICMP redirect cache is empty

SW-COEUR# show ip protocols
Routing Protocol is "ospf 1"
  Router ID 1.1.1.1
  ...
  Routing for Networks:
    192.168.10.0 0.0.0.255 area 0
  Passive Interface(s):
    GigabitEthernet1/0/47
    GigabitEthernet1/0/48
    Vlan10
    ...