Deux routeurs, le même lien rompu, la même zone OSPF — et un seul paramètre de type de réseau qui fait toute la différence de quarante secondes dans le temps que met le reste du réseau à s'en apercevoir. Voici ce qui se passe réellement dans la base de données à état de liens selon le type de réseau, une bascule réelle à quatre routeurs avec la sortie LSA effective, et les commandes pour vérifier lequel vous utilisez réellement.
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
Le type de réseau est généralement choisi pour des raisons d'adjacence — correspondance de sous-réseau, éligibilité au DR — mais il décide en silence à l'avance de la vitesse à laquelle le réseau remarque un lien mort.
Deux interfaces OSPF peuvent toutes deux atteindre Full en utilisant le type de réseau Broadcast ou Point à Point — l'adjacence elle-même se moque de celui que vous avez choisi. Ce qui compte, c'est le moment où ce lien tombe réellement en panne. Sur un segment Broadcast, la panne doit passer par un routeur désigné et un network-LSA que seul le DR contrôle. Sur un lien point à point, il n'y a pas de DR, pas de network-LSA, et rien qui attend le minuteur de quelqu'un d'autre. Même panne, même protocole, deux chemins de récupération différents.
Cette note se concentre étroitement sur cet écart : ce qui se passe réellement dans la base de données à état de liens de chaque routeur quand le lien tombe, un vrai cas à quatre routeurs avec la sortie LSA des deux côtés de la même panne, la surcharge DR/BDR que seuls les segments broadcast portent, et les commandes pour vérifier quel type de réseau un segment utilise réellement avant que cela ne devienne la raison pour laquelle une bascule a pris plus de temps que prévu. Pour le déroulé de la machine à états des voisins quand une adjacence ne se forme pas du tout, voir OSPF Neighbor Troubleshooting ; pour l'endroit où les valeurs par défaut du type de réseau et le comportement DR/BDR diffèrent entre fournisseurs, voir la note Huawei-Cisco OSPF Interop.
Même événement physique, même zone OSPF — le schéma ci-dessous montre ce que chaque routeur doit réellement faire, et combien de temps cela prend.
Broadcast en haut, Point à Point en bas. La structure DR/BDR qu'introduit le broadcast est exactement la partie de la chronologie que le point à point saute entièrement.
Les légendes du schéma restent en anglais pour la clarté technique.
La différence n'est pas de savoir si un routeur remarque une panne — c'est de savoir quelles structures doivent changer avant que le reste du réseau puisse agir en conséquence.
Sur un lien point à point, les deux routeurs connectés n'échangent que des router-LSA, et chacun porte une entrée de lien décrivant directement le voisin — plus une entrée stub-network séparée pour l'interface elle-même. Cette entrée décrivant le voisin n'existe que tant que l'adjacence est réellement Full. Dès que l'interface tombe, le routeur qui la possède cesse de porter cette entrée dans son tout prochain router-LSA. Rien d'autre n'a besoin de changer avant.
Sur un segment broadcast, la même panne physique doit se refléter dans deux structures distinctes : le router-LSA propre à chaque routeur (une entrée Transit Network pointant vers le DR du segment), et un network-LSA séparé que seul le DR origine, listant chaque routeur rattaché encore considéré comme Full. Un routeur non-DR qui perd son lien peut mettre à jour son propre router-LSA tout de suite et recalculer ses propres routes rapidement. Mais le network-LSA — et l'entrée du router-LSA du DR pour ce segment — ne changent pas tant que le DR lui-même ne remarque pas que le voisin a disparu, ce qui, sur un segment partagé, signifie attendre l'expiration de son propre minuteur dead pour ce voisin, pas la chute de l'interface.
<Huawei> display ospf lsdb router
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2 2.2.2.2 12 48 8000001C 0
// P2P: this router-LSA carries the neighbor link only while the adjacency is Full
<Huawei> display ospf lsdb network
Type LinkState ID AdvRouter Age Len Sequence Metric
Network 1.1.24.4 4.4.4.4 23 32 80000001 0
// Broadcast only: originated solely by the DR -- absent entirely on a P2P segment
L'élection DR/BDR existe pour empêcher chaque routeur d'un segment multi-accès de former un maillage complet d'adjacences avec chaque autre routeur qui s'y trouve — à la place, tout le monde forme une adjacence uniquement avec le DR et le BDR. C'est un vrai gain d'efficacité quand un segment compte réellement plusieurs routeurs. Mais cela signifie aussi que l'existence même du segment dans la base de données à état de liens dépend désormais du point de vue d'un routeur précis : tant que le DR lui-même n'a pas déclaré un voisin mort, le reste du réseau doit supposer que la topologie du segment n'a pas changé, même si le lien d'un routeur rattaché vers celui-ci a clairement changé. Un lien point à point saute entièrement cette étape — il n'y a pas de DR, rien à élire, et rien qui doive attendre le minuteur d'un tiers avant que le reste du réseau puisse faire confiance à la mise à jour.
<Huawei> display ospf interface GigabitEthernet1/0/0
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
1.1.24.4 Broadcast DR 1 1 1.1.24.4 1.1.24.2
// forcing point-to-point removes DR/BDR from the picture entirely
[Huawei-GigabitEthernet1/0/0] ospf network-type p2p
SYMPTÔMEUn lien qui n'est en réalité que deux routeurs sur un segment dédié met quand même longtemps à reconverger après une panne, comme s'il s'agissait d'un grand LAN multi-accès.
CAUSELe type de réseau des interfaces Ethernet est Broadcast par défaut, quel que soit le nombre de routeurs qui partagent réellement le segment. Un segment avec exactement deux routeurs élit quand même un DR et un BDR, construit quand même un network-LSA, et conditionne quand même la suppression de ce network-LSA au propre minuteur dead du DR — même s'il n'y a jamais eu de troisième routeur ayant besoin de la mécanique DR/BDR au départ.
SOLUTIONSi un segment est dédié à exactement deux routeurs et le restera toujours, réglez délibérément les deux extrémités en point à point avec ospf network-type p2p, plutôt que d'accepter le broadcast par défaut par omission.
SYMPTÔMELa convergence semble asymétrique — le routeur qui a réellement perdu le lien recalcule ses routes presque immédiatement, mais le reste du réseau ne reconverge complètement qu'environ un intervalle de minuteur dead plus tard.
CAUSEQuand le lien en panne appartient à un routeur non-DR, ce routeur met à jour son propre router-LSA tout de suite. Mais le network-LSA du segment n'est produit que par le DR, et le DR ne sait pas que le voisin a disparu tant que son propre minuteur dead pour ce voisin n'a pas expiré — il ne surveille pas l'interface en panne, il surveille l'adjacence qu'il détient avec ce voisin.
SOLUTIONAvant de traiter une reconvergence qui semble bloquée comme une panne, vérifiez quel routeur est le DR du segment concerné avec display ospf interface — si c'est le propre minuteur dead du DR qui s'épuise, c'est un comportement attendu d'un segment broadcast, pas un bug.
SYMPTÔMEAprès avoir basculé un lien en type de réseau point à point, quelqu'un vérifie la LSDB en s'attendant aux mêmes types de LSA qu'avant, et suppose que quelque chose est cassé parce que le network-LSA de ce segment a simplement disparu.
CAUSEUn router-LSA P2P porte quand même une entrée de lien décrivant le voisin — il le fait juste directement, dans le propre router-LSA de chaque routeur, plutôt que via un network-LSA partagé. Il n'y a jamais eu de network-LSA séparé à chercher une fois le lien en P2P.
SOLUTIONVérifiez display ospf lsdb des deux côtés — attendez-vous à deux entrées de type Router avec des liens de style point à point, et confirmez qu'il n'y a pas d'entrée de type Network pour ce segment ; cette absence est correcte pour le P2P, pas un symptôme de problème.
SYMPTÔMEDès qu'ospf network-type p2p est appliqué d'un côté, la relation de voisinage tombe immédiatement, alors que rien n'a changé physiquement sur le lien lui-même.
CAUSELe type de réseau est l'un des paramètres qui doivent correspondre entre deux voisins OSPF pour que l'adjacence tienne du tout. Le changer d'un côté sans l'autre crée une incohérence immédiate, et même changer les deux côtés ensemble force la machine à états à redémarrer, puisque le statut DR/BDR et les types de LSA impliqués changent tous les deux en même temps.
SOLUTIONAppliquez le changement des deux côtés dans la même fenêtre de maintenance, et revérifiez avec display ospf interface et display ospf peer verbose immédiatement après.
SYMPTÔMEAprès une bascule, une mise à jour LSA attendue n'apparaît jamais dans la LSDB propre d'un voisin, et cela ressemble à un échec du mécanisme de convergence lui-même.
CAUSELa commande ospf filter-lsa-out (all / summary / ase / nssa) est une optimisation légitime pour réduire les inondations LSA inutiles sur une interface sortante spécifique — souvent déployée délibérément pour réduire la taille de la LSDB et améliorer la vitesse de convergence quand plusieurs liens parallèles existent entre deux routeurs. Si quelqu'un l'a configurée auparavant et que c'est oublié, un type de LSA filtré qui n'arrive tout simplement jamais ressemble exactement à une convergence bloquée.
SOLUTIONAvant de traiter une mise à jour LSA manquante comme une panne, vérifiez display current-configuration interface pour une instruction ospf filter-lsa-out sur l'interface en question.
Le même test physique, réalisé deux fois — une fois avec le type de réseau par défaut, une fois forcé en point à point — rend la différence concrète plutôt que théorique.
Le réseau : quatre routeurs exécutant OSPF area 0. SW2 et SW4 partagent un segment, avec SW4 agissant comme 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 selon le type de réseau.
Avec le lien SW2–SW4 laissé sur son 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é, puis recalcule ses propres routes rapidement. Le router-LSA de SW4 et son network-LSA pour ce segment ne changent pas encore — SW4 continue de décompter son propre minuteur dead pour le voisin qu'il a perdu. La sortie show ip ospf nei ci-dessous est capturée en plein décompte, avant que le minuteur ne s'épuise :
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
// remaining dead-time counting down out of a 40-second interval -- the wait is real, not a display artifact
SW4#show ip ospf database network self-originate
OSPF Router with ID (4.4.4.4) (Process ID 100)
Net Link States (Area 0)
Link State ID: 1.1.24.4 (address of Designated Router)
Attached Router: 4.4.4.4
Attached Router: 2.2.2.2
// still lists SW2 as attached -- SW4 hasn't yet noticed the neighbor is gone
// once 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
// the segment only flips from Transit to Stub -- and the network-lsa is only withdrawn -- once the dead timer runs out
Basculer 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, il n'y a aucune relation DR/BDR ni aucune couche network-LSA à attendre du tout. 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 — toute l'attente visible dans la trace broadcast ci-dessus n'existe tout simplement pas en point à point.
La leçon pratique n'est pas « le P2P est toujours meilleur » — un lien P2P ne peut de toute façon pas desservir un segment avec trois routeurs ou plus. C'est que le type de réseau n'est pas qu'un détail de configuration décidé au moment de la formation de l'adjacence : il décide à l'avance de la façon dont une panne se propage réellement dans la base de données à état de liens, et cela mérite d'être réglé délibérément — avec display ospf interface confirmé des deux côtés — plutôt que découvert par accident pendant une panne quand la vitesse de convergence compte réellement.
Cette note s'appuie sur un vrai cas de convergence OSPF à quatre routeurs, en utilisant la sortie show originale du matériau source, ainsi que la mécanique LSA Broadcast/P2P standard décrite dans la propre référence de filtrage LSA OSPF de Huawei. Elle ne couvre pas les types de réseau NBMA ou P2MP, l'OSPFv3, la détection de panne accélérée par BFD, ni comment ces chiffres évoluent sur un segment sécurisé par authentification — chacun mériterait un examen séparé.
Les questions qui reviennent chaque fois que cet écart de convergence est réellement sur la table.
Pas à la sélection de chemin en conditions normales — le coût est fixé indépendamment du type de réseau. Ce qui change concerne entièrement le chemin de panne : quelles structures LSA doivent être reconstruites, et le minuteur de qui le reste du réseau attend quand le lien tombe réellement.
L'attente est liée au routeur qui agit comme DR pour ce segment, car seul le DR origine le network-LSA. Si le côté en panne est DR-Other des deux côtés, le DR du segment est un troisième routeur qui doit remarquer la perte du voisin via son propre minuteur dead — le mécanisme est le même, il est juste conditionné par le minuteur d'un autre routeur, pas nécessairement celui dont le lien a physiquement échoué.
Seulement si le routeur qui part est le DR ou le BDR lui-même. Si le lien d'un routeur non-DR, non-BDR échoue, il n'y a aucune réélection du tout — le DR et le BDR existants mettent simplement à jour le network-LSA pour retirer ce routeur une fois son propre minuteur dead expiré. La réélection ne se produit que quand le DR ou le BDR lui-même tombe.
Non — le point à point est spécifiquement destiné à un lien connectant exactement deux routeurs sans aucun autre voisin partageant ce segment. Un LAN multi-accès avec trois routeurs OSPF ou plus doit utiliser Broadcast (ou NBMA), car le point à point n'a aucun mécanisme pour plus d'un voisin par interface.
Cette note suppose que l'adjacence fonctionne déjà et porte sur ce qui arrive à une adjacence fonctionnelle quand son lien tombe en panne. Pour le déroulé complet de la machine à états — de Down à Init, 2-Way, ExStart, Exchange, Loading jusqu'à Full — voir OSPF Neighbor Troubleshooting.
Envoyez-nous la sortie de display ospf interface des deux côtés — nous vous dirons ce qui arrive à ce segment dès que le lien tombe.