Un voisin qui ne monte pas, qui se bloque à un état précis, ou une route qui n'arrête pas d'osciller — tout cela semble mystérieux jusqu'à ce qu'on le replace sur la machine à états des voisins OSPF. Voici comment la lire, les commandes display pour chaque état, et les causes qui expliquent la plupart de ces pannes.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les problèmes de voisins OSPF semblent intimidants de l'extérieur — Init, ExStart, 2-Way — jusqu'à ce qu'on réalise que chaque état bloqué correspond à une liste courte et précise de causes.
Un voisin OSPF qui ne monte pas, qui reste bloqué à un état particulier, ou une route qui n'arrête pas d'osciller sans raison évidente — tout cela ressemble d'abord à de profonds mystères du protocole. En pratique, une fois qu'on sait à quel état l'adjacence est réellement bloquée, la liste des causes plausibles se réduit vite, car chaque état de la machine à états des voisins OSPF correspond à une étape précise de la négociation, et seule une poignée de choses peuvent casser cette étape précise.
Voici la machine à états elle-même, ce qu'implique le blocage à chaque état, les commandes display à vérifier à chacun, les causes qui reviennent sans cesse, et un vrai cas de convergence avec une sortie show réelle du terrain.
Sept états entre Down et Full — et trois d'entre eux sont ceux où une adjacence se bloque presque à chaque fois.
Avant d'exécuter la moindre commande, placez le symptôme sur cette chaîne. Cela indique exactement quelle section ci-dessous lire ensuite.
Les légendes du schéma restent en anglais pour la clarté technique.
Commencez par vérifier si le voisin apparaît seulement — puis lisez l'état précis où il est bloqué.
Si le voisin n'apparaît jamais, ou apparaît puis retombe à Down, vérifiez d'abord le mot-clé du journal avant de deviner une cause.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 1.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 1 192.168.1.1 0.0.0.0
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
HELLO packet errors:
0 : Hello timer mismatch 0 : Dead timer mismatch
// counters climbing here point straight at the mismatched parameterUne fois qu'un voisin est visible, l'état où il est figé réduit encore plus la liste des causes.
<Huawei> display ospf interface
IP Address Type State Cost Pri DR BDR
1.1.1.1 Broadcast DROther 1 0 1.1.1.2 0.0.0.0
// Pri 0 + DROther = expected 2-Way, not a fault
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
// tests whether oversized packets survive the path -- common ExStart causeUne fois l'état connu, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas en dessous.
SYMPTÔMELe voisin ne dépasse jamais Down ou Init alors que les interfaces sont up et le lien va bien — et il n'y a aucune erreur évidente nulle part.
CAUSEPlusieurs paramètres indépendants doivent correspondre exactement pour qu'un voisin se forme : l'Area ID OSPF des deux côtés, le sous-réseau et le masque pour les réseaux broadcast/NBMA/P2MP (P2P n'a pas cette exigence), et les intervalles des minuteurs hello/dead. Aucun d'eux ne produit d'erreur spectaculaire — ils empêchent simplement, silencieusement, l'adjacence de jamais se former.
SOLUTIONComparez d'abord le champ Area de display ospf interface des deux côtés. Puis exécutez display ospf error toutes les 10 secondes pendant environ 5 minutes — un compteur Hello timer mismatch ou Dead timer mismatch qui grimpe indique exactement quel minuteur aligner avec ospf timer hello ou ospf timer dead.
<Huawei> display ospf interface
OSPF Process 1 with Router ID 10.1.1.1
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
10.1.1.1 Broadcast BDR 1 1 10.1.1.2 10.1.1.1
// compare Area against the peer's own display ospf interface outputSYMPTÔMEL'état du voisin est figé à ExStart — les paquets DD vont et viennent mais la description de base de données ne se synchronise jamais.
CAUSEQuand ospf mtu-enable est configuré, les MTU des deux interfaces doivent être égaux, sinon la synchronisation DD ne peut pas aboutir. Par ailleurs, des paquets surdimensionnés silencieusement rejetés quelque part sur le chemin produisent exactement le même symptôme.
SOLUTIONExécutez ping -s 1500 neighbor-address pour vérifier si les gros paquets survivent au chemin. Si non, réparez le lien. Si oui, comparez et égalisez le MTU des deux interfaces avec la commande mtu.
<Huawei> ping -s 1500 -a 1.1.1.1 1.1.1.2
[Huawei-GigabitEthernet1/0/0] mtu 1500SYMPTÔMEUne relation de voisinage ne se forme jamais avec un routeur tiers spécifique, alors que le même routeur local interopère bien avec tous les autres voisins OSPF du réseau.
CAUSEOSPF exige que le type de réseau de l'interface corresponde aux deux extrémités d'un lien — Broadcast, NBMA, P2P et P2MP sont les quatre types standards, et broadcast/NBMA/P2MP exigent en plus que les deux côtés partagent le même sous-réseau et masque (pas P2P). Dans un cas réel d'interopérabilité, l'interface d'un routeur tiers était réglée sur un mode propriétaire « point-to-multipoint non-broadcast » — qui se comporte comme du P2MP NBMA sur le papier mais exécute en réalité un protocole propriétaire, non standard, en dessous. Les deux côtés ne parlaient jamais réellement le même dialecte OSPF, et la relation de voisinage a échoué net.
SOLUTIONVérifiez le type de réseau des deux côtés avec l'équivalent de ospf network-type et forcez-les à l'un des quatre types OSPF standards. N'acceptez pas une variante non standard ou propriétaire d'un pair juste parce que son nom semble similaire.
SYMPTÔMEUn voisin n'apparaît jamais du tout, ou le réseau se comporte de manière incohérente sans qu'on puisse le rattacher à un lien précis — des routes ou adjacences qui semblent fonctionner à un endroit et pas à un autre.
CAUSEDeux routeurs du même domaine OSPF sont configurés avec le même Router ID. Comme le Router ID est censé être unique dans tout le système autonome, une collision produit des symptômes confus et incohérents plutôt qu'une erreur nette.
SOLUTIONComparez le Router ID de display ospf brief des deux côtés, et réattribuez-en un unique avec ospf router-id.
<Huawei> display ospf brief
OSPF Process 1 with Router ID 1.1.1.1
OSPF Protocol Information
[Huawei] ospf router-id 1.1.1.2SYMPTÔMELe voisin ne se forme jamais, et toutes les autres vérifications — interface, sous-réseau, MTU, minuteurs — reviennent nettes.
CAUSELes deux routeurs construisant l'adjacence ont des types d'authentification OSPF différents configurés pour la zone.
SOLUTIONExécutez display ospf error toutes les 10 secondes pendant environ 5 minutes. Si le compteur Bad authentication type continue de grimper, cela confirme la discordance — configurez le même type d'authentification des deux côtés avec area-authentication-mode.
<Huawei> display ospf error
General packet errors:
0 : Bad authentication type 0 : Bad authentication key
// a climbing Bad authentication type counter confirms the mismatch
[Huawei-ospf-1-area-0.0.0.0] area-authentication-mode md5Quatre commutateurs, un lien rompu, et la différence que fait le type de réseau sur la vitesse — et la manière — dont OSPF le remarque réellement.
Le réseau : quatre routeurs exécutant OSPF area 0, avec SW2 et SW4 partageant un segment où SW4 est le DR. Le trafic normal entre SW2 et une loopback sur SW4 (4.4.4.4) transite par un troisième routeur, SW3. Le test : maintenir un ping continu de SW2 vers 4.4.4.4, puis déconnecter physiquement le lien de SW2 vers SW4, et observer ce que font réellement les LSA propres à chaque routeur.
Avec le lien SW2–SW4 réglé sur le type de réseau broadcast par défaut, le débrancher ne libère pas l'adjacence immédiatement. SW2 s'en aperçoit tout de suite et republie son propre router-LSA sans le réseau partagé, et recalcule rapidement ses propres routes. Mais le router-LSA de SW4 et son network-LSA pour ce segment ne changent pas encore — SW4 attend toujours l'expiration de son minuteur dead. Quand SW4 recalcule entre-temps son propre arbre SPF, il doit vérifier dans le router-LSA de SW2 un lien retour vers le réseau partagé pour valider ce chemin ; comme le nouveau LSA de SW2 ne le liste plus, SW4 refuse correctement d'utiliser ce chemin, mais le segment ne se libère complètement de la topologie qu'une fois le minuteur dead de SW4 lui-même écoulé.
SW4#show ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:37 1.1.24.2 GigabitEthernet0/24
1.1.1.1 1 FULL/DR 00:00:39 1.1.14.1 GigabitEthernet0/1
// after SW4's dead timer actually expires:
*Mar 1 01:18:54.681: %OSPF-5-ADJCHG: Process 100, Nbr 2.2.2.2 on GigabitEthernet0/24
from FULL to DOWN, Neighbor Down: Dead timer expired
SW4#show ip ospf database router self-originate
Link connected to: a Stub Network
(Link ID) Network/subnet number: 1.1.24.0
(Link Data) Network Mask: 255.255.255.0
// the segment only changes from Transit to Stub -- and the matching
// network-lsa is only withdrawn -- once SW4's own dead timer expiresBasculer ce même lien SW2–SW4 en type de réseau point à point change le résultat, pas seulement le calendrier. Sur un lien P2P, débrancher le câble (ou arrêter l'interface) fait tomber le voisin immédiatement des deux côtés — il n'y a pas de relation DR/BDR ni de couche network-LSA à attendre. SW2 cesse d'annoncer le lien à l'instant où sa propre interface tombe ; SW4 fait de même dès que sa relation de voisinage se rompt, car un router-LSA P2P ne porte l'entrée de lien décrivant le voisin que tant que l'adjacence est réellement Full. Aucun côté n'est bloqué à attendre le minuteur dead de l'autre pour que le réseau reconverge complètement.
La leçon pratique n'est pas « P2P est toujours meilleur » — c'est que le type de réseau n'est pas qu'un détail de configuration, il change réellement la façon dont une panne se propage dans la base de données à état de liens, et cela mérite d'être su délibérément plutôt que découvert par accident quand la vitesse de convergence compte.
Cette note s'appuie sur le flux de diagnostic de l'état des voisins OSPF du routeur Huawei série AR (display ospf interface / display ospf error / display logbuffer) ainsi que sur un vrai cas de convergence multi-fournisseurs. Elle ne couvre pas en profondeur le comportement spécifique NSSA, les liens virtuels, les différences OSPFv3, ou les problèmes de résumé ABR multi-zones — chacun a ses propres modes de défaillance qui mériteraient un examen séparé.
Dites-nous à quel état il est figé et envoyez la sortie de display ospf interface / display ospf error — nous vous aiderons à l'interpréter.