Accueil / Notes techniques / Convergence OSPF : Broadcast vs Point à Point

Convergence OSPF après une panne de lien : Broadcast vs Point à Point, une étude de cas réelle

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

La convergence se décide bien avant que le lien ne tombe réellement

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.

Deux chronologies pour le même lien rompu

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.

BROADCAST NETWORK TYPE Link Down SW2 (non-DR): new router-LSAimmediately — SPF runs fast SW4 (DR): router/network-LSAunchanged — waiting on dead-timer ~40s later:dead-timer expires network-LSAwithdrawn, full reconverge segment not fully clear from topology until SW4's own dead-timer runs out POINT-TO-POINT NETWORK TYPE Link Down SW2: router-LSA drops theneighbor entry — instantly SW4: router-LSA drops theneighbor entry — instantly Full network reconvergesno DR, no network-LSA, no timer wait both sides gone the instant the interface goes down — bounded only by SPF run time, not a timer Same physical failure, same OSPF area — the DR/BDR layer is the only reason the top row waits.

Les légendes du schéma restent en anglais pour la clarté technique.

Ce qui change dans la LSDB — et ce qui ne change pas

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.

Router-LSA et Network-LSA : la couche supplémentaire qu'introduit le broadcast

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

DR/BDR : une mécanique qui n'existe que parce que les segments broadcast en ont besoin

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

Cinq pièges à connaître avant une bascule, pas après

1. Un segment « Broadcast » à deux routeurs paie quand même la totalité de la taxe DR/BDR

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.

2. Le propre minuteur dead du DR conditionne tout le segment, pas seulement sa propre route

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.

3. Le point à point génère quand même des LSA — juste pas de network-LSA

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.

4. Changer le network-type fait rebondir l'adjacence — planifiez la fenêtre

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.

5. ospf filter-lsa-out peut ressembler à une panne de convergence si on oublie qu'il est là

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.

Conceptions de solutions associées

Une vraie bascule : quatre routeurs, un lien coupé, deux types de réseau

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.

Limites honnêtes de cette note

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é.

FAQ

Les questions qui reviennent chaque fois que cet écart de convergence est réellement sur la table.

Basculer le type de réseau d'un lien de Broadcast à P2P change-t-il quelque chose avant qu'une panne ne survienne ?

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.

Si SW2 et SW4 partagent un segment mais que SW4 n'est pas le DR, la même attente de quarante secondes s'applique-t-elle quand même ?

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é.

Un segment Broadcast a-t-il toujours besoin d'une élection DR/BDR en cas de panne ?

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.

Puis-je régler le type de réseau en point à point sur un segment avec plus de deux routeurs ?

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.

Où aller si le voisin lui-même n'atteint jamais Full, quel que soit le type de réseau ?

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.

Vous n'êtes pas sûr du type de réseau qu'utilise réellement un segment ?

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.

WhatsApp avec un ingénieur →

Lectures connexes

Nous n'utilisons des cookies que pour des statistiques anonymes — pas de publicité, pas de suivi intersites.Politique de confidentialité