Les voisins OSPF ne se forment pas sur un VPN ? Vérifiez ces points dans l’ordre

Le tunnel est actif, les interfaces sont dans le même sous-réseau, et OSPF n’affiche toujours rien. La plupart du temps, le tunnel est correct et une exigence OSPF n’est pas remplie. Effectuez les cinq vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue.

Chaque vérification a un symptôme distinct, c’est pourquoi l’ordre compte plus que la liste.

Vérification 1 : le modèle de liaison est-il correct

Une interface point à point et un réseau partagé à accès multiple sont des environnements OSPF différents. Copier une configuration de LAN broadcast sur un tunnel est l’erreur la plus courante ici. Définissez le type de réseau pris en charge par l’implémentation VPN, généralement point à point pour un tunnel routé. Confirmez ensuite que la plateforme est d’accord, car certaines implémentations ignorent ou écrasent le réglage.

Si le modèle de liaison est faux, rien d’autre dans la liste n’aidera.

Vérification 2 : les paquets sont-ils autorisés à passer

OSPFv2 est le protocole IP 89, et non un port TCP ou UDP, donc une règle de pare-feu écrite pour des ports le rejette silencieusement. Les hello vont aussi vers des adresses multicast, qu’une politique peut ne pas autoriser. Autorisez le protocole 89 entre les extrémités du tunnel, puis vérifiez si la plateforme a besoin de déclarations de voisin explicites.

Un tunnel qui ne laisse passer que des ping est un problème de politique, pas de routage.

Vérification 3 : les paramètres du voisin correspondent-ils

L’ID de zone, les intervalles hello et dead, l’authentification et les indicateurs stub doivent tous concorder. Une incohérence laisse généralement le voisin dans un état visible au lieu d’échouer silencieusement, ce qui est utile. Comparez la configuration en cours aux deux extrémités, pas celle prévue.

L’incohérence de MTU est la plus subtile. Elle bloque l’échange de base de données à ExStart, donc le voisin n’atteint jamais Full.

Vérification 4 : que dit l’état

L’état nomme la panne. Init signifie que des hello arrivent mais que ce routeur n’y figure pas, ce qui indique un chemin unidirectionnel ou un problème de multicast. Two-Way est normal sur un segment broadcast avec un voisin non DR et anormal sur une liaison point à point. Un ExStart ou Exchange bloqué indique un problème de MTU ou de description de base de données. Loading signifie que les demandes d’état de liaison ne reçoivent pas de réponse.

Lisez l’état avant de changer quoi que ce soit, car il élimine la majeure partie de la liste.

show ip ospf neighbor affiche l’état, l’adresse du voisin et le minuteur dead. Comparez ce minuteur à l’intervalle hello des deux côtés : un intervalle dead de quatre fois le hello est normal, tout le reste est une incohérence. La colonne d’état est la lecture la plus rapide de toute la page.

Vérification 5 : qu’est-ce qui est réellement annoncé

Une adjacence Full n’est pas une route. Vérifiez quels réseaux sont créés, lesquels sont appris et lesquels sont installés dans la table de routage. Une déclaration de réseau manquante ou une politique de redistribution qui exclut le préfixe du site produit un voisin sain et une table vide.

Testez ensuite une application au niveau de l’hôte et le chemin de retour, car un protocole de routage n’ouvre pas un pare-feu.

Pour IPv6, OSPFv3 a ses propres exigences et n’est pas un commutateur de famille d’adresses sur chaque réglage OSPFv2. Utilisez le protocole correspondant et la documentation de la plateforme. Et si la connexion est une liaison fixe, comparez les routes statiques avant d’ajouter un plan de contrôle que vous devrez exploiter.