Dépannage OSPFv2

La configuration du protocole OSPFv2 sur un routeur Cisco se fait en deux étapes :

• Tout d’abord, en mode de configuration global, il faut activer le protocole avec la commande « router OSPFv2 » suivie du numéro de processus.

Ici, sur notre topologie, on prend le numéro 1.

Alors ce processus est entièrement local au routeur.

• Ensuite, il reste plus qu’à indiquer les réseaux des interfaces du routeur.

Il ne faut surtout pas oublier que le protocole utilise des masques inversés.

Le dépannage de l’OSPFv2 demande une bonne compréhension du protocole et de son fonctionnement.

Comme pour tout type de dépannage, il faut procéder étape par étape.

Il faut toujours commencer par vérifier que le routeur a bien établi une adjacence avec son voisin en utilisant la commande « show IP ospf neighbors » .

S’il n’y a aucune adjacence entre deux routeurs, alors ils ne pourront pas s’échanger de routes.

Dans ce cas, il faut vérifier que les interfaces sont opérationnelles et activées pour OSPF.

Et si elles le sont, et bien il faudrait voir si elles sont configurées dans la même zone OSPF et qu’elles ne sont pas configurées non plus, comme des interfaces passives.

Le deuxième composant de dépannage est « la Table de routage ».

Si l’adjacence entre deux routeurs est bonne, mais qu’en faisant un « show IP route », on ne voit aucune route OSPF dans la table de routage, alors il faudrait vérifier qu’il n’existe pas un autre protocole de routage avec une distance administrative plus basse et donc prioritaire, qui tournerait sur le réseau.

Car si c’est le cas, les routes OSPFv2, n’étant pas prioritaires, ne seront pas placées dans la table de routage.

S’il n’y a que ospf qui tourne, alors il faudrait checker l’ensemble des réseaux qu’il doit annoncer.

S’il s’agit d’une topologie à zone multiple, il faudrait voir, si les zones sont bien connectées à la zone de backbone, la zone 0.

Car si ce n’est pas le cas, alors, les routeurs dans cette zone ne pourront pas envoyer et recevoir de mises à jour vers d’autres zones.

Et la dernière étape d’un dépannage OSPF, est de vérifier les itinéraires qu’il emprunte.

Si la table de routage comprend bien l’ensemble des réseaux, mais qu’il y a toujours un problème, alors il faudrait vérifier le coût OSPF sur les interfaces du chemin qui pose problème.

Il ne faut pas oublier, que si, il y a des interfaces supérieures à 100 Mégas, et bien dans ce cas, toutes les interfaces au-dessus de cette bande passante auront le même coût OSPF par défaut.

La commande « show IP ospf interface » permet d’afficher le coût de chaque interface du routeur.

On va maintenant voir en détail, la 1re étape de dépannage.

Sur cette topologie, nous avons un problème de voisinage entre les routeurs 1 et 2.

La commande « show IP interface brief » permet de vérifier que le statut et le protocole sont bien « up » pour l’interface Série 0/0/0. Celle qui est connectée au routeur2.

Ici, on voit bien que le lien est donc, opérationnel sur la couche 2.

On va maintenant vérifier la connectivité de la couche 3 entre les routeurs 1 et 2, en faisant un ping.

Dans l’exemple, on voit bien que la connectivité IP entre les 2 périphériques est bonne.

Si le ping n’avait pas fonctionné, alors il aurait fallu aller voir du côté du câblage physique des interfaces. Et vérifier aussi qu’il se trouve bien sûr le même sous réseau IP, avec le bon masque.

Si jusque-là tous est corrects, on peut aller vérifier les paramètres IP et l’état des interfaces avec la commande « show IP ospf interface » , à faire sur les deux routeurs.

Avec cette commande on peut voir que le router id de R1 est 4 fois 1 |et celui du routeur 2 est 4 fois 2.

Pour continuer notre dépannage sur la bonne relation du voisinage OSPF, on va vérifier quelles sont les interfaces qui participent à ses échéances avec la commande « show IP protocols », qu’on fait sur les 2 routeurs.

Cette commande permet de nous montrer les adresses IP ou les réseaux qui ont été activés à l’aide de la commande « network » .

Sur la topologie, on voit que le protocole OSPF est bien activé sur les interfaces série des deux routeurs.

Si les paramètres ne sont pas identiques aux 2 bouts, alors l’adjacence ne pourra se faire.

Cette commande nous affiche aussi, la liste des interfaces passives.

Ici on voit que le routeur 1 a son interface série 0/0/0, celle qui pointe vers le routeur 2, de défini comme passif.

Ce qui explique pourquoi les routeurs ne peuvent pas former leurs relations de voisinage, car une interface passive bloque les mises à jour de routage.

C’est-à-dire la réception des paquets « HELLO ».

C’est pour ça que les routeurs ne peuvent pas être voisins.

Normalement, il faut plutôt configurer une interface en tant que passif, si elles pointent vers internet, ou bien si elle est du côté des utilisateurs directs.

Dans ces 2 cas, il n’est pas utile d’envoyer ce type de paquets.

De plus, cela peut représenter un risque pour la sécurité !

Maintenant que nous avons ciblé le problème, il reste plus qu’à faire un « no passive-interface » sur l’interface série 0/0/0 du routeur 1, pour que le voisinage puisse se faire correctement, et que les 2 routeurs puissent s’échanger des messages LSA.

VÉrifier la table de routage OSPF

La prochaine étape de dépannage consiste à vérifier les tables de routage.

Dans l’exemple, le routeur 1 ne peut pas atteindre les réseaux que le routeur 2 publie.

Leur relation de voisinage est correcte, mais un ping vers le réseau 192.168.1.0 à partir du routeur 1 ne fonctionne pas.

Ce qui laisserait penser qu’il lui manque, peut-être, un itinéraire dans sa table de routage.

Si plusieurs protocoles de routage sont configurés sur les routeurs, alors c’est la distance administrative qui décidera de quel protocole, le routeur utilisera.

La distance administrative influence les routes qui seront installées dans la table de routage.

Si on fait un « show IP protocols », on s’aperçoit qu’il y a deux protocoles de routage de configurer sur le routeur 1. Eigrp et OSPF.

Et si on lance un « show IP route » du réseau qui se trouve derrière le routeur 2,

On voit que cette route a été apprise, via le protocole EIGRP, car il à une distance administrative de 90, alors que OSPF, sa distance est de 110.

Ce qui explique, pour quoi le routeur 1 installera plutôt la route EIGRP dans sa table de routage.

Pour rappel, plus la distance administrative est faible, et plus l’itinéraire est de confiance.

Et pour corriger ce problème, il faudrait supprimer sur le routeur 1, l’utilisation du protocole EIGRP pour le réseau qui se trouve derrière le routeur 2.

Dépannage de la sélection du chemin OSPF

Maintenant, on va voir la dernière étape du dépannage OSPF.

C’est-à-dire la sélection du chemin.

Un mauvais chemin n’entraîne pas forcément une perte de connectivité.

Mais dans certains cas, on souhaiterait que les données utilisent un chemin bien défini.

Par exemple un lien WAN de secours, celui qui est représenté avec les interfaces série, peut être facturé par la quantité de données qui y est transférée.

Et cela peut être un peu coûteux, si les données passent régulièrement sur ce lien.

Lorsque l’on a des chemins redondants dans un réseau, il faut vérifier que le trafic prend le chemin que l’on souhaite à travers le réseau.

Par exemple, sur cette topologie, il y a 2 liens entre les deux routeurs.

Un à grande vitesse pour la prod et un à faible vitesse pour secourir le 1er en cas de problème.

Il faudrait donc s’assurer que la liaison de secours est empruntée qu’en cas de crash du lien principal.

Cela va se jouer, sur les coûts ospf du routeur.

Si on fait un « show IP route ospf » on s’aperçoit que le trafic traverse les deux liens, car les interfaces ont le même coût ospf.

Ce coût on le voit juste après la valeur administrative.

Ici il est de 2 pour les deux liens. Et la valeur administrative est à 110 pour OSPF.

Le réseau derrière le routeur 2, est donc accessible depuis le routeur 1, via l’interface GigabitEthernet0 / 1 et l’interface Série0/0/0.

Parce que les deux interfaces ont le même coût OSPF, l’équilibrage de charge sera donc utilisé sur les deux liens.

Comme les liens ne sont pas de la même vitesse, la raison qui expliquerait un coût OSPF identique sur les deux interfaces serait soi :

• Qui l’a été modifié par un admin réseau
• Ou alors que la bande passante de référence est incorrecte.

Pour rappel, le coût OSPF se calcule en divisant la bande passante de référence, qui est de 100 mégas, par celle de l’interface.

Par exemple, avec les deux interfaces qu’on a, une de 1000 Mégabits et une de 100 Mégabits, les deux auront le même coût OSPF à 1 si la valeur de référence est réglée à 100.

La commande « show IP ospf interface » permet vérifié le coût OSPF sur les interfaces :

Ici le coût est à 1 sur les deux interfaces.

On remarque que sur la commande précédente le coût était à 2.

Et bien c’est parce qu’il compte le coût jusqu’au réseau derrière le routeur.

Tant dit que là, il s’agit seulement du coût du lien.

Si on souhaite emprunter un chemin plutôt qu’un autre, il faudra modifier ce coût, avec la commande « IP ospf cost », à faire en mode de configuration directement sur les interfaces des deux extrémités.

Si maintenant on refait un « show IP route ospf », on se rend compte que seul le lien en gigabit ethernet est inscrit dans la table de routage, car le lien série à un coût plus élevé. Son coût est de 10+1, ce qui donne 11.

DÉpannage des problÈmes OSPF en IPv6

Pour terminer le cours, on va parler de l’OSPF en IPv6.

OSPFv2 est pour l’IPv4 et OSPFv3 est le nom que porte l’OSPF en IPv6.

Sa configuration est très similaire à l’IPv4.

La principale différence c’est que l’OSPFv3 est activé directement sur l’interface IPv6 avec la commande « ipv6 ospf » .

Ce qui rend, son dépannage, très similaire à l’OSPFv2.

La commande « show ipv6 protocols » permet de vérifier les protocoles de routage IPv6 sur le routeur.

La commande « show ipv6 ospf neighbors » affiche les voisins que l’OSPF en version 3 découvre.

La commande « show ipv6 ospf interfaces » permet d’afficher les interfaces actives, ainsi que leurs coûts.

Et la commande « show ipv6 route » affiche le contenu de la table de routage IPv6, qui comprend les itinéraires spécifiques à l’OSPF.

Voici un tableau, qui représente les petites différences, entre les 2 versions de l’OSPF.

Les 2 peuvent coexister sur le même routeur, mais ils seront juste indépendants.

C’est-à-dire, qu’ils tourneront dans des processus différents.

L’OSPFv2 annonce les routes IPv4, tandis que l’OSPFv3 annonce les routes pour IPv6.

Les messages OSPFv2 proviennent de l’adresse IPv4 de l’interface de sortie.

Dans la V3, ces messages viennent de l’adresse link-local de l’interface de sortie.

Pour les adresses multicast, la V2 utilise l’IP 224.0.0.5 ; et la V3 utilise FF02::5.

Sur les routeurs qui sont élus en DR ou BDR, l’adresse multicast en V2 est 224.0.0.6 ; et la V3 utilise FF02::6.

L’OSPFv2 annonce les réseaux après avoir utilisé la commande « network », tandis qu’en OSPFv3 la commande est « ipv6 ospf ».

En ipv6, il faut activer le routage obligatoirement avec la commande « ipv6 unicast-routing » à faire en mode de configuration globale.

Et pour finir, la V2 utilise l’authentification en clair ou celle en MD5. Alors que la V3 utilise sa propre authentification.

Retrouvez tous nos cours pour réussir votre CCNA sur la chaîne YouTube de Formip.