Dépannage OSPF : diagnostiquer les relations de voisinage, les LSAs et les problèmes de convergence

Le dépannage OSPF est en exploitation particulièrement critique lorsque l’erreur ne se manifeste pas comme une panne complète, mais comme un « parfois ça marche, parfois non » : des relations de voisinage restent bloquées dans un état intermédiaire, des préfixes individuels disparaissent, ou la convergence (temps jusqu’à une topologie de routage stable après une modification) est nettement plus longue que prévu. OSPF (Open Shortest Path First) est un protocole de routage à états de lien : les routeurs échangent des informations d’état (LSAs, Link-State Advertisements) et calculent localement le chemin le plus court. C’est précisément ce mécanisme qui fournit d’excellents signaux de diagnostic – à condition d’adopter une démarche structurée.

Cet article est conçu comme un runbook : d’abord les garde-fous (impact, retour), puis une séquence de vérification claire pour les relations de voisinage, les LSAs/LSDB et les problèmes de convergence. Lorsque des commandes sont présentées, elles sont volontairement génériques : la syntaxe diffère selon la plateforme (Cisco IOS/IOS-XE, NX-OS, Juniper Junos, FRRouting, MikroTik, etc.), mais les états, compteurs et schémas de causes sont en OSPF largement identiques.

Dépannage OSPF : 1) Avant l’intervention : périmètre, risque et stratégie de retour (rollback)

Avant de modifier « quelque chose » dans OSPF, clarifiez trois points : que touche le changement (périmètre), quel est l’impact potentiel, et comment revenir en arrière (rollback). OSPF réagit souvent immédiatement aux changements ; un paramètre mal configuré peut réinitialiser un voisinage, refaire inonder les LSAs et ainsi solliciter la CPU/le plan de contrôle – en particulier sur des nœuds centraux.

Délimiter rapidement le périmètre

• Un seul lien / un seul voisin ? Dans ce cas, il s’agit souvent d’un problème lié à l’interface, à la MTU, à l’authentification ou aux timers.
• Plusieurs voisins dans une area ? Dans ce cas, le type d’area, les filtres, les liens virtuels, le type de réseau ou le consensus DR/BDR sont suspects.
• « Des routes manquent » sans problème de voisinage ? Alors plutôt les types de LSA, la summarization, le filtering, le Max-LSA, la logique stub/NSSA ou la redistribution.
• Convergence lente malgré des voisinages autrement corrects : SPF/LSA-throttling, LSA-flapping, erreurs d’interface, CPU, ou LSDB trop volumineuse.

Stratégie de retour (pratique)

En exploitation OSPF, il est recommandé de planifier chaque modification de manière à pouvoir l’annuler sans opérations OSPF « majeures » :

• Sauvegarde de configuration (gestion des versions, référence du changement, horodatage).
• Un paramètre par modification (ne pas modifier Hello, Auth et type de réseau en même temps).
• Fenêtre de maintenance pour les réinitialisations potentielles de voisinage (Auth/MTU/type de réseau/changement d’area).
• Plan B : route statique temporaire, ajustement temporaire des coûts (OSPF cost), ou shutdown/no shutdown contrôlé de liens individuels – mais délibérément comme intervention, pas comme méthode d’essais-erreurs.

2) Relations de voisinage OSPF : comprendre les états et tester de manière ciblée

Les états Neighbor d’OSPF sont votre premier repère. Important : selon le type de réseau, toutes les adjacences ne deviennent pas nécessairement « FULL ». Sur les réseaux Broadcast et NBMA, souvent seule l’adjacence avec le DR/BDR (Designated Router / Backup Designated Router) est FULL ; les autres restent en 2-WAY, ce qui peut être correct. Sur les liaisons Point-to-Point, un état FULL entre les deux routeurs est normal.

Les états et leur signification en exploitation

• DOWN : aucun Hello reçu. Causes fréquentes : L2/L3/ACL/Multicast/interface down.
• INIT : Hellos reçus, mais l’ID de routeur locale n’est pas renvoyée dans le Hello. Typique en cas de trafic unidirectionnel ou de filtrage/ACL.
• 2-WAY : bidirectionnel, mais (sur Broadcast/NBMA) pas adjacente au DR/BDR. Peut être correct.
• EXSTART/EXCHANGE : synchronisation de la base de données (DBD). Fréquent : MTU mismatch ou fragmentation de paquets/filtrage incorrect.
• LOADING : LSR/LSU (Link State Request/Update) en cours, mais pas terminés. Souvent dû à des filtres LSA, perte de paquets, MTU/fragmentation, ou plan de contrôle surchargé.
• FULL : LSDB synchronisée (pour l’adjacence concernée).

Séquence de vérification pour „Neighbor ne devient pas FULL”

Travaillez de l’extérieur vers l’intérieur : d’abord connectivité et interface, puis paramètres OSPF, enfin LSDB/échange.

Étape A: La connectivité L3 pour OSPF est-elle possible ?

OSPF utilise le protocole IP 89 (pas TCP/UDP). Sur les réseaux Broadcast, les Hellos sont envoyés vers 224.0.0.5 (AllSPFRouters) et 224.0.0.6 (AllDRouters). Sur les liens Point-to-Point, cela peut également être du multicast, selon la plateforme/le type de lien. Firewalls, ACL, groupes de sécurité ou CoPP (Control Plane Policing) doivent l’autoriser.

Approche minimale de capture (Linux-Host als Tap/Span-Auswertung; bei Routern gibt es oft integrierte Packet-Capture-Features):

# Auf einem Mirror-Port oder Capture-Host:
# OSPF-Protokoll 89 und Multicast-Ziele prüfen
sudo tcpdump -ni eth0 'ip proto 89 or (ip multicast and (host 224.0.0.5 or host 224.0.0.6))'

Ce que vous devez voir : des paquets Hello réguliers (par défaut 10s sur Broadcast, 30s sur NBMA – peut varier). Si un seul sens est visible, cela correspond à INIT (trafic unidirectionnel). Si rien n’est visible : L2/VLAN, interface ou filtrage.

Étape B: Les paramètres « must-match » sont-ils cohérents ?

Pour une adjacence OSPF, des paramètres clés doivent correspondre. Lesquels exactement dépendent du type de réseau et du jeu de fonctionnalités, mais voici les classiques :

• Area-ID : les deux côtés doivent être dans le même contexte d’area (p. ex. Area 0 comme backbone).
• Hello/Dead-Interval : doivent correspondre, sinon le voisin ignore les Hellos.
• Netztyp (Broadcast, Point-to-Point, NBMA) : influence l’élection DR/BDR et les attentes sur les adjacences.
• Authentifizierung : le type (p. ex. Simple/MD5/HMAC selon la plateforme) et la clé doivent correspondre. Remarque : l’authentification est souvent « silencieuse » — des clés incorrectes entraînent DOWN/INIT.
• Stub-Flag/Area-Typ : dans les areas Stub/NSSA, le type d’area doit être consistant, sinon l’adjacence échoue.

Piège opérationnel : des modifications du type d’area ou de l’authentification provoquent souvent des resets immédiats des voisins. Planifiez cela comme un événement d’exploitation (monitoring, fenêtre de maintenance).

Étape C: MTU-Mismatch sauber abklären

MTU-Mismatch est l’une des raisons les plus fréquentes d’EXSTART/EXCHANGE. OSPF négocie les tailles de paquet lors de la synchronisation de la base de données ; si une extrémité envoie des paquets plus grands que ce que l’autre accepte, vous observez des retransmissions, des boucles d’échange ou des états bloqués. Cela se produit souvent après des modifications VLAN-/MPLS-/tunnel lorsque seule la L2-MTU d’un côté a été ajustée.

• Indice: le voisin oscille entre EXSTART et EXCHANGE ou y reste bloqué.
• Pourquoi: les paquets DBD/LSU sont rejetés ou fragmentés/bloqués.
• Risque: un « Schnellfix » via MTU-Ignore peut masquer les symptômes, mais les vrais problèmes de fragmentation/Path-MTU subsistent.

Operationnellement pertinent : définir la MTU de manière cohérente des deux côtés et, si nécessaire, vérifier la Path-MTU le long du chemin (p. ex. pour L3-Portchannels, QinQ, GRE/IPsec, VXLAN-Underlay).

Schritt D: DR/BDR und Netztyp als Fehlerquelle

Sur des segments Broadcast ou NBMA, un DR/BDR est élu. Cela influence avec qui une adjacence complète est établie. Si vous vous attendez à ce que « tous soient FULL avec tous », mais que vous êtes sur un segment Broadcast avec DR/BDR, un état 2-WAY vis-à-vis des voisins non-DR est normal. Le problème survient lorsque le DR/BDR change constamment (flapping) ou que le DR n’est pas joignable.

• Causes typiques: domaine L2 instable, perte de paquets, priorités différentes, ou redémarrages des passerelles.
• Impact: synchronisations répétées de la LSDB, inondation accrue d’LSA, problèmes de convergence.

3) LSAs et LSDB : quand des routes manquent ou semblent « incohérentes »

Si les voisins sont FULL, mais que des routes manquent ou ont un coût incorrect, les LSAs et la Link-State Database (LSDB, la base de données topologique interne d’OSPF) sont le point suivant d’analyse. OSPF ne calcule pas « à partir de rien » : si une information n’existe pas comme LSA dans la LSDB, elle ne peut pas apparaître dans la table de routage.

Types d’LSA en pratique (bref et opérationnel)

• Type 1 (Router-LSA) : décrit les liens d’un routeur au sein d’une zone (Area). Base pour SPF.
• Type 2 (Network-LSA) : généré par le DR sur Broadcast/NBMA et décrit le segment réseau partagé.
• Type 3 (Summary-LSA) : émis par les ABR (Area Border Routers) pour des réseaux agrégés ou redistribués entre Areas.
• Type 4 (ASBR-Summary) : indique le chemin vers un ASBR (Autonomous System Boundary Router) qui injecte des routes externes.
• Type 5 (External-LSA) : routes externes (redistribution), non autorisées dans les Stub-Areas.
• Type 7 (NSSA-External) : routes externes dans des NSSA-Areas ; sont traduites en Type 5 sur l’ABR.

Pourquoi c’est important : si, par ex., vous attendez soudainement des Type-5-External dans une Stub-Area, ce n’est pas que « OSPF est cassé », mais que le design ou la définition de l’area ne correspond pas à l’attente.

Diagnosepfad: „Route fehlt“ in fünf Schritten

1. Le préfixe est-il présent dans la LSDB ? Sinon : vérifier la source/la redistribution/l’ABR/les filtres.
2. Est-il dans le bon type de LSA ? Externe (Type 5/7) vs. interne (Type 1/3).
3. Provient-il de l’Area attendue ? Vérifier le design de l’Area et les chemins ABR.
4. Est-il installé ? L’Administrative Distance, un RIB-Failure, la Route-Preference ou une policy peuvent empêcher l’installation.
5. Est-il de nouveau annoncé ? Filtres, Summarization, NSSA-Übersetzung, ou problèmes Max-LSA/LSA-Refresh.

Pour la collecte des données, il est utile de créer une collection standardisée de « show » par plateforme. À titre d’exemple (runbook de substitution ; adaptez les commandes à votre OS) :

# Runbook : Collecte de données (modèle, remplacer les commandes selon la plateforme)
# 1) Voisins OSPF + états
# 2) Détails des interfaces OSPF (timers, type de réseau, MTU, auth)
# 3) Extrait de la LSDB : types de LSA pertinents et préfixes concernés
# 4) Table de routage : préfixe présent ? via quel next-hop ?
# 5) Logs : resets de voisin, erreurs d'auth, indications MTU/DBD

Causes typiques d’LSA manquants ou « étranges »

• Area-Mismatch / mauvais type d’Area : Stub/NSSA incohérent, violation du design du backbone, liens virtuels instables.
• Filtres OSPF ou route policies : filtrage entrant ou sortant des Summary/External-LSA (dépend de la plateforme).
• Summarization : l’ABR fait de la Summarization ; les préfixes individuels n’apparaissent plus de façon granulaire. C’est voulu, mais cela peut compliquer le dépannage.
• Problèmes de redistribution : les routes externes ne sont pas injectées (ex. règles de matching manquantes) ou sont distribuées sous un mauvais type (E1/E2).
• Max-LSA / limites de LSDB : certaines plateformes peuvent dropper des voisinages ou refuser des LSA en cas de débordement de la LSDB — pertinent sur de larges domaines.

4) Problèmes de convergence : lorsque OSPF met « trop » de temps ou semble instable

La convergence n’est pas seulement « le routage revient un jour ». En exploitation, ce qui compte, c’est que vos applications (VoIP, ERP, VDI, stockage, API-Gateways) soient stables dans un délai défini en secondes. La convergence OSPF se compose de plusieurs temps : la détection de l’événement (Dead-Interval/Dead-Timer ou BFD), le flooding des LSA, le calcul SPF, l’installation dans la table de routage et, le cas échéant, la programmation du FIB en matériel.

Commencer par distinguer : lent vs. instable

• Lent : après un événement de lien, cela prend de façon reproductible « trop » de temps, mais se stabilise ensuite.
• Instable : les voisins présentent du flapping, les LSA sont constamment refloodés, les routes changent fréquemment.

Causes fréquentes de lente convergence

• Dead-Interval trop élevé : la détection de l’événement prend trop de temps (classiquement 40 s). Remède : ajustement des timers ou BFD (Bidirectional Forwarding Detection ; vérification de l’aliveness plus rapide sous OSPF).

Causes fréquentes de convergence instable (flapping)

• Physique : erreurs CRC, mismatch duplex/vitesse, optiques instables, liaisons radio/WAN fluctuantes.
• ECMP/asymétrie : le trafic emprunte des chemins différents, les chemins de retour sont filtrés (symptôme INIT).
• Changements DR/BDR sur segments broadcast dus à une instabilité L2 ou des conflits de priorité.
• Mauvaise configuration : timers différents, rotation de clé d’authentification appliquée seulement d’un côté, MTU non ajustée partout après un changement.

Stratégie de mesure et d’observation (compatible monitoring)

Pour « Monitoraggio », l’important est que vous rendiez la convergence mesurable en permanence, et pas seulement lors d’un debug ponctuel :

• Uptime des voisins et taux de flap : nombre de transitions d’état par heure/jour.
• Churn LSA : combien de LSAs sont créés/rafraîchis/retransmis par unité de temps.
• Exécutions SPF : fréquence et durée des calculs SPF (si la plateforme fournit ces métriques).
• Taux d’erreurs d’interface : CRC, input drops, queue drops, puissance optique (pour la fibre).
• Corrélation d’événements : Link-Down/Up, changement de voisin OSPF, pic CPU, puis alarmes applicatives.

Si vous ne mesurez que « le ping est de nouveau là », vous passez à côté de micro-interruptions qui, par exemple, provoquent des tempêtes de TCP reset ou des pertes de paquets.

5) Listes de contrôle pratiques : vérifier rapidement que vous n’oubliez rien

Liste de contrôle A : le voisin ne devient pas opérationnel

• Interface up/up, VLAN/Tagging/Trunking corrects
• Adressage IP / masque de sous-réseau appropriés, pas d’IP dupliquée
• OSPF activé sur la bonne interface (vérifier passive-interface)
• Hello/Dead concordent
• ID d’area et type d’area concordent (Stub/NSSA)
• Authentification : méthode + key/key-id cohérents
• MTU cohérente des deux côtés ; fragmentation/PMTUD non bloquée
• Type de réseau cohérent (p2p vs broadcast) ; comportement DR/BDR compris
• ACL/Firewall/CoPP autorisent le protocole IP 89 et le multicast

Liste de contrôle B : voisins en FULL, mais route manquante

• Préfixe présent dans la LSDB ? Si non : source/redistribution/ABR/filter
• Type de LSA plausible (interne vs externe ; traduction NSSA)
• Summarisation active sur l’ABR ? Vérifier l’attente concernant les routes détaillées
• Table de routage/RIB installée ? Administrative distance/policy/next-hop récursif
• Forwarding/FIB corrects ? (programmation hardware, contexte VRF)

Liste de contrôle C : convergence trop lente

• Détection d’événements : Dead-Interval vs BFD
• Flooding LSA : perte de paquets, retransmissions, erreurs d’interface
• SPF : CPU/mémoire, paramètres de throttling SPF, taille LSDB
• Design : areas trop grandes, trop d’ABR/ASBR, redistributions inutiles
• Source du changement : liens instables, portchannels qui flappent, optiques défectueuses

6) Mise en œuvre : correctifs typiques — et quand ils échouent

En troubleshooting, il est tentant d’appliquer des contournements « rapides ». Mieux vaut isoler la cause, puis appliquer le correctif avec une analyse claire des effets secondaires.

Ajustement des timers et BFD

Le réglage des timers (réduction des Hello/Dead) peut accélérer la convergence, mais augmente la sensibilité au jitter et aux pertes de paquets courtes. BFD est souvent la variante la plus propre : il fournit une détection rapide de lien/chemin, tandis qu’OSPF conserve la logique topologique. BFD peut échouer sur des chemins asymétriques, des bugs d’offload matériel ou des intervalles trop agressifs sur le WAN.

Résoudre les problèmes de MTU et de Path-MTU

La solution durable est la cohérence : même MTU, même encapsulation, et ne pas bloquer les ICMP si PMTUD (Path MTU Discovery) est utilisé. « MTU Ignore » peut aider à court terme, mais c’est risqué : de grands LSUs ou le trafic applicatif peuvent continuer à fragmenter ou à être dropés.

Rationaliser la conception des zones

Beaucoup de problèmes de convergence et de LSA sont des conséquences du design : domaines de flooding trop grands, Externals inutiles, ou frontières d’Area peu claires. Une planification propre d’Area-0, une Redistribution limitée et une Summarization pertinente réduisent le LSA-Churn. Cela peut échouer pour des raisons organisationnelles (charge de changement) ou à cause de dépendances lorsque des applications attendent des chemins IP « fixes ».

Stabiliser DR/BDR

Si le flapping DR/BDR est un sujet, des priorités claires et des segments L2 stables aident. Dans certains designs, le Point-to-Point (lorsque possible) est plus simple à exploiter que de vastes domaines broadcast. Cela peut échouer si le design L2 (p. ex. Campus-VLANs) n’est pas modifiable facilement.

7) Documentation et routines opérationnelles : du dépannage vers la stabilité

Les problèmes OSPF réapparaissent lorsque le savoir opérationnel ne « migre » pas dans le processus. Deux éléments simples ont fait leurs preuves :

• Package de diagnostic standardisé : quelles sorties collectez-vous lors d’événements Neighbor-/LSA-/Convergence ? Où sont-elles stockées ? Qui les analyse ?
• Garde-fous de changement : pour la rotation des clés d’authentification, les modifications de MTU, les changements d’Area et la Redistribution, il existe un court Runbook avec des vérifications avant/après et un rollback.

Prévoyez aussi des limites de capacité : quand la LSDB croît (sites, VRFs, nouveaux Externals), augmentent non seulement les besoins mémoire, mais aussi la charge de calcul et de flooding. Les tendances observées tôt valent plus qu’un constat ponctuel « après l’extension, tout était lent ».

Conclusion : avec une séquence de vérification fixe, les problèmes OSPF deviennent gérables

Le troubleshooting OSPF devient nettement plus simple si vous séparez systématiquement le diagnostic en trois niveaux : relations de voisinage (états et paramètres devant correspondre), LSAs/LSDB (l’information est-elle présente et du bon type ?), et convergence (détection d’événements, flooding, SPF, installation). Avec un Runbook clair, des captures reproductibles et du monitoring sur les flaps, le LSA-Churn et les erreurs d’interface, vous identifierez les causes plus rapidement — et éviterez des correctifs qui ne déplacent que les symptômes.

Pour ce sujet, les relations de voisinage OSPF et les LSAs OSPF sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.