Dépannage du routage et adjacences OSPF

Définition

Le dépannage du routage est une méthode séquentielle : on vérifie d'abord que le routeur connaît la destination (show ip route), puis que le next-hop est joignable (ping), puis que chaque tronçon du chemin répond (traceroute). Chaque test élimine une moitié du problème. On ne touche la configuration qu'après avoir localisé le maillon fautif, sinon on casse ce qui marchait.

La méthode en 4 étapes

1. La table. show ip route <destination> répond à tout : la route existe-t-elle, par quel next-hop, avec quelle AD et quelle métrique ? Pas de route = problème de configuration ou de protocole, pas de trafic à chercher.
2. Le next-hop. ping <next-hop> depuis le routeur local. Si le next-hop ne répond pas, la liaison directe est morte (physique, adresse, masque, ARP) et la route est un leurre.
3. Le chemin. traceroute <destination> montre où les paquets meurent. Un saut qui affiche * * * alors que le suivant répond = contrôle d'admission ou paquets ICMP filtrés, pas une coupure.
4. Le retour. Un ping aller-retour échoue aussi si la route de retour manque. Dépanner dans les deux sens, depuis les deux extrémités.

Outils de base

R1# show ip route 172.16.20.0
R1# show ip interface brief
R1# show ip protocols
R1# ping 10.0.0.2
R1# traceroute 172.16.20.10
R1# debug ip routing        (précaution: impact CPU, no debug all ensuite)

Causes fréquentes et premiers réflexes

Symptôme	Cause typique	Vérification
Route absente de la table	Oubli de ip route, interface down	show run | include ip route, show ip interface brief
Route présente, next-hop injoignable	Next-hop éteint, erreur d'IP, ARP vide	ping next-hop, show arp
Traffic part mais ne revient pas	Route de retour manquante chez le voisin	show ip route <reseau-source> sur le routeur distant
Perte de paquets sur un saut	Masque erroné, MTU, lien saturé	show interfaces (CRC, drops), ping avec taille variable
Route qui apparaît/disparaît	Flapping d'interface ou d'adjacence	show logging, compteurs last clearing

Next-hop injoignable

Cas classique : S 172.16.20.0/24 [1/0] via 10.0.0.2 est dans la table mais le ping vers 172.16.20.10 échoue. Le next-hop 10.0.0.2 ne répond pas ? On vérifie l'ARP (show arp) : entrée absente = L2 cassé, VLAN, trunk ou interface éteinte. Entrée présente mais ping impossible = problème côté hôte (firewall qui bloque ICMP, mauvaise passerelle). Sur Ethernet, une route statique vers un next-hop sans interface dépend du lookup récursif : si l'interface du next-hop tombe, la route peut rester affichée alors qu'elle ne transporte plus rien.

Flapping

Une interface qui monte et redescend fait osciller les routes : le ping passe par intermittence, show logging défile avec %LINK-3-UPDOWN. Les causes sont physiques (câble, connecteur, duplex négocié en half contre full, erreurs CRC visibles dans show interfaces) ou protocolaires (adjacence OSPF qui se réélit sans cesse, hello timers incompatibles). Contre-mesure : errdisable recovery, remplacement du câble, timers harmonisés.

Masque erroné et route par défaut absente

Deux voisins en 10.0.0.0/30 et 10.0.0.0/29 : ils croient être sur deux réseaux différents, l'adjacence ne se forme pas et la connectivité est intermittente selon les adresses. show ip interface et la comparaison des masques des deux côtés tranchent en dix secondes. Deuxième grand classique : le routeur de stub n'a pas de route par défaut et ne connaît que ses réseaux connectés. Le ping vers Internet échoue sans message parlant. show ip route \| include 0.0.0.0 vérifie la présence de la route par défaut.

Dépanner une adjacence OSPF

OSPF publie l'état de chaque voisin, ce qui guide le diagnostic :

État	Signification	Piste
Down	Aucun hello reçu	Lien, multicast filtré, IP du voisin
Init	Hello reçu, pas le mien en retour	Unidirectionnel, ACL
2-Way	Adjacence de voisinage sur Ethernet, pas plus	DR/BDR en cours, normal pour DROTHER
ExStart/Exchange bloqués	Désaccord de MTU ou de DD	ip mtu, incohérence de trames
Loading qui stagne	LSDB en cours, LSA rejetés	Redistrib, aire mismatch
Full attendu jamais atteint	Timers, aire, authentification, réseau	show ip ospf interface

R1# show ip ospf neighbor
R1# show ip ospf interface GigabitEthernet0/0
R1# debug ip ospf adj      (attention en production)

Les tueurs silencieux d'adjacence : area ID différent, hello/dead mismatch, masque réseau incompatible sur Ethernet, stub flag désaccordé, authentification présente d'un seul côté.

Exemple concret chiffré

PC 172.16.10.50/24 (passerelle 172.16.10.1, R1) ne joint pas le serveur 172.16.20.10. Suite de tests depuis R1 : show ip route 172.16.20.0 affiche O 172.16.20.0/24 [110/782] via 10.0.0.2 ; ping 10.0.0.2 répond en 2 ms ; traceroute 172.16.20.10 passe le premier saut puis expire vers la destination. Test inverse depuis R2 : la route OSPF vers 172.16.10.0 est absente (show ip route 172.16.10.0 vide) parce que le préfixe est redistribué en statique seulement sur R1, jamais dans l'autre sens. Correction : publier le réseau côté R2. Le temps total du diagnostic : 3 commandes.

Pièges de la démarche

1. Changer la configuration avant d'avoir localisé : on crée un deuxième problème.
2. Conclure « réseau coupé » sur * * * dans traceroute : ICMP peut être filtré alors que le TCP passe.
3. Tester depuis un PC seulement : le routeur élimine la variable hôte.
4. debug actif après l'intervention : no debug all (ou undebug all) systématique.