Troisième article dédié au Troubleshooting de niveau 3.
Nous continuons ici avec d’autres erreurs de configuration.
Hormis pour la partie L3 sur DSW1 et DSSW2, les switchs seront ignorés.
1) Topologie et scénario
La topologie reste inchangée par rapport aux autres articles.
Le scénario est le même que dans l’article précédent.
Le client 1 n’arrive plus à joindre le serveur WEB.
2) Troubleshooting – Partie 1
A nouveau, première étape, la constatation du problème.
La passerelle indique qu’elle n’est pas capable de joindre le réseau de destination.
Voyons sa table de routage.
DSW1 ne possède pas de route vers 172.17.0.0 /24.
En y regardant de plus près, nous pouvons voir qu’il ne possède aucune route vers les réseaux après R2.
Suivons le chemin jusqu’à R2.
Le constat est le même que sur DSW1.
Au passage, il peut être bon d’exécuter quelques commandes de vérification rapide.
Nous voyons ici que le routeur utilise EIGRP et OSPF.
A partir de là nous pouvons vérifier les relations de voisinage pour les protocoles utilisés.
Ici tout semble OK.
Continuons.
R3 semble ne pas connaitre les réseaux après R2.
Ajoutons les vérifications basiques.
R3 n’a pas de relation de voisinage avec R2.
Ce qui explique qu’aucun routeur ne connaisse de route vers les réseaux après R2.
Commençons par un test simple pour vérifier la connectivité R3 – R2.
R2 est joignable.
Comparons les configurations OSPF.
Les configurations semblent bonnes.
Vérifions la configuration des interfaces.
Voici la cause du problème.
Le Timer Hello OSPF a été modifié sur R3 (10s par défaut).
Or, pour qu’une relation de voisinage puisse s’établir entre deux routeurs, il faut (entre autre) que les Timer soient les mêmes.
La liste des attributs qui doivent correspondre est visible dans cet article (part 1.4).
http://www.networklab.fr/introduction-a-ospf/
Corrigeons l’erreur.
R3(config)#interface serial 0/0.2 R3(config-subif)#no ip ospf hello-interval 1
Retournons voir DSW1.
Il possède à présent une route par défaut.
Voyons si le problème est résolu.
Non.
En revanche, le message d’erreur est intéressent.
Jusqu’à la destination, aucun routeur n’a indiqué qu’il n’était pas capable de router le message.
Cela indique peut être que le message arrive à destination (172.17.0.100), mais qu’il ne peut pas revenir.
Plaçons-nous sur R2.
Il n’a pas de route pour 172.17.0.0 /24, mais il a une route par défaut.
Il possède aussi une route pour le retour (vers 10.2.1.0 /24).
Ajoutons quelques vérifications.
Tout semble OK.
Allons sur R1.
La table de routage semble bonne.
Vérifions les relations de voisinage.
La relation BGP avec R5 n’est pas bonne.
L’état Active n’est pas l’état normal.
Vous pouvez vérifier cela en allant sur R5.
Cela explique le problème de communication.
Les messages venant de Client 1 sont routés jusqu’à R5, mais ce dernier ne possède pas la route pour le retour.
Comparons les configurations BGP.
Le problème est visible ici.
R5 n’est pas configuré pour former une relation de voisinage avec R1.
En effet, en BGP la commande Network ne sert pas à créer les relations de voisinage.
Corrigeons cela.
R5(config)#router bgp 65002 R5(config-router)#neighbor 172.16.0.1 remote-as 65002
Quelques temps après, la relation remonte.
Re-testons depuis Client 1.
Cette fois-ci la communication passe.
Laisser un commentaire