Le diagnostic de panne est une compétence attendue dans différentes certifications. L’article de ce jour va traiter un cas classique en environnement de routage OSPF: le non-établissement de l’adjacence totale OSPF (Full Adjacency).
L’adjacence OSPF totale caractérise la relation entre deux routeurs voisins après synchronisation complète de leurs bases de données topologiques. Par la suite, la diffusion des mises à jour topologiques doit se faire entre routeurs adjacents. Si ce dernier paragraphe vous laisse perplexe, référez vous à l’article: Introduction au protocole de routage OSPF.
Adjacence totale OSPF: un objectif pour tous les routeurs voisins ?
En un mot: non.
Reprenons depuis le début. Deux routeurs sont dits voisins, s’ils sont directement connectés l’un avec l’autre et qu’ils peuvent s’échanger directement des messages OSPF. Mais le protocole OSPF prévoit que seules quelques relations de voisinage doivent évoluer vers une relation de totale adjacente. Il s’agit des cas suivant:
- Routeurs voisins connectés par des infrastructures point-à-point, point-à-multipoints ou encore par un lien virtuel (virtual link: ce dernier permet de garantir que toutes les aires disposent d’un accès à l’aire backbone).
- Dans le cas des infrastructures broadcast ou NBMA (Non-Broadcast Multi-Access), tous les routeurs doivent établir une relation d’adjacence totale avec les routeurs désignés DR (Designated Router) et BDR (Backup DR).
Pour illustrer ceci, prenons le cas d’un réseau Ethernet. Par défaut, un routeur Cisco considère qu’il s’agit d’un réseau de type broadcast. Ainsi, il va y avoir l’élection d’un routeur DR et d’un routeur BDR et tous les routeurs doivent avoir une relation d’adjacence totale avec ces deux routeurs. Considérons que R1 soit élu DR et R2 BDR. Cela veut dire que tous les routeurs (par exemple R3 et R4) doivent avoir une relation d’adjacence totale avec R1 et R2 mais pas entre R3 et R4.
Ainsi, lorsque deux routeurs ne sont pas adjacents, on doit d’abord vérifier si cette relation doit être atteinte par ces deux routeurs.
Relation OSPF « Full Adjacency »: la compatibilité
Pour pouvoir devenir adjacents, deux routeurs doivent avoir un paramétrage cohérent concernant les informations listées ci-dessous.
L’identifiant de noeud dans le graphe OSPF
Ce que l’on identifie par le routeur-ID (lire notre article intitulé: « OSPF et Router-ID« ). Cet identifiant doit absolument être unique !
Sous-réseau / Masque de sous-réseau
Il faut que le réseau soit strictement identique à la longueur du masque de sous réseau prés.
Prenons un exemple:
R1: interface F0/0 ip address 192.168.10.1 255.255.255.0 no shut
R2: interface F0/0 ip address 192.168.10.2 255.255.255.128 no shut
Ces deux routeurs ne peuvent pas devenir adjacents: un masque est sur 24 bits (R1) et l’autre sur 25 bits (R2)
Aire
Les interfaces des routeurs doivent être dans la même aire OSPF !
Temporations
Les temporisations concernant :
- l’intervalle entre deux message OSPF Hello (Hello-Interval);
- la valeur choisie pour identifier un problème sur les échanges Hello (le Dead-Interval).
doivent être strictement identiques (leur valeur est indiquée dans le contenu du message Hello).
Flags OSPF (Stub, NSSA)
Lorsqu’une aire OSPF est de type « stub » ou « NSSA », cette information est communiquée dans les messages Hello: il faut s’assurer que la même information soit utilisée par des routeurs voisins faute de quoi l’adjacence sera impossible…
MTU
La taille maximale des paquets IP doit être identique entre les deux routeurs candidats à une adjacence totale.
Authentification
Evidemment, il faut s’assurer de la cohérence du type d’authentification éventuellement configuré et du mot de passe partagé entre les routeurs !
Méthodologie de diagnostic
Étape 1: caractériser le problème d’adjacence
Lorsqu’un problème de routage apparaît sur le réseau, la première étape consiste à identifier que ce problème est lié à un problème d’adjacence entre routeurs OSPF. Pour cela, nous utiliserons la commande:
show ip ospf neighbor
Si R1 et R2 doivent être adjacents, alors cette commande – tapée sur l’un des deux routeurs – doit faire apparaitre l’autre routeur !
Étape 2: Vérifier la connectivité directe entre les deux routeurs
Il ne s’agit pas seulement de vérifier que la connectivité IP existe entre les deux routeurs mais bien de vérifier que cette connectivité se fait bien directement par l’infrastructure commune. Voilà pourquoi, on peut utiliser les commandes:
show cdp neighbors
ou, mieux, notamment lorsqu’il y a (comme c’est souvent le cas) des commutateurs entre les routeurs:
traceroute <@IP>
Il faudra vérifier que la route est directe (un seul saut pour atteindre l’adresse IP affectée à l’interface du routeur sensé être adjacent).
En cas de problème à cette étape du diagnostic, une cause du problème d’adjacence est liée à la communication de niveau 2 (Ethernet, Frame-Relay, PPP, etc.). La communication doit être rétablie sur l’infrastructure avant de pouvoir aller plus loin…
Étape 3: S’assurer qu’OSPF est bien activé sur les interfaces concernées
Pour cette étape, il faut vérifier que l’interface locale a bien OSPF activée:
show ip ospf int brief
Mais, il faut également s’assurer que l’interface distante est bien activée. On peut, pour cela, utiliser la même commande sur le routeur distant ou bien vérifier en envoyant un ping sur l’adresse IP multicast réservée à OSPF:
ping 224.0.0.5 source F0/0
Étape 4 – Vérifier les attributs spécifiques à l’aire
Bien sûr, il faut s’assurer que les interfaces qui partagent la même infrastructure soient bien dans la même aire OSPF mais il faut également s’assure que les attributs spécifiques soient bien identique, notamment le flag Stub.
Pour cela, on peut utiliser la commande suivante sur les deux routeurs:
show ip ospf | begin Area
Note: dans le retour de la commande, on peut voir les attributs de type sub ou encore l’authentification configurée pour l’aire.
Étape 5 – Vérifier les attributs spécifiques à l’interface
Il faut pour cela vérifier les éléments précédemment listés en début d’article.
Le type de réseau OSPF
show ip ospf int | inc Network Type
Le type de réseau n’a pas obligation a être identique. Il suffit que ce type soit cohérent: faut-il des routeurs désignés (DR/BDR) sur ce type de réseau ou non ? Mais attention, le logiciel Cisco associe – par défaut – des temporisations OSPF différentes en fonction du type de réseau.
Donc, si le type est différent mais reste cohérent, il faudra éventuellement mettre à jour manuellement les valeurs de temporisation OSPF pour permettre l’établissement de l’adjacence complète !
Le réseau et masque de sous-réseaux:
show ip ospf int brief
Le MTU:
sh int F0/0 | inc MTU
Les temporisations OSPF:
show ip ospf int F0/0 | inc intervals
Rappel: Hello et Dead doivent être identiques sur les deux interfaces des deux routeurs.
L’authentification:
Toutes ces vérifications permettent d’identifier la cause du dysfonctionnement et donc donnent toutes les informations requises pour que l’administrateur corrige le défaut jusqu’à l’établissement de l’adjacence totale.
Cette adjacente totale conduit à apprendre des routes par l’intermédiaire du routeur adjacent et donc un remplissage de la table de routage OSPF avec pour next-hop le routeur OSPF adjacent:
show ip route ospf
Comme le montre cet article, il y a de nombreuses causes qui peuvent conduire au non-établissement de l’adjacence OSPF totale ! Soyez attentifs, vigilant et surtout… méthodique !
Laisser un commentaire