Two routers, the same broken link, the same OSPF area — and one network-type setting away from a forty-second difference in how long the rest of the network takes to notice. Here's what actually happens inside the link-state database on each network type, a real four-router failover with the actual LSA output, and the commands to check which one you're actually running.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Network type is usually chosen for adjacency reasons — subnet matching, DR eligibility — but it quietly pre-decides how fast the network notices a dead link.
Two OSPF interfaces can both reach Full using either Broadcast or Point-to-Point network type — the adjacency itself doesn't care which one you picked. What does care is the moment that link actually fails. On a Broadcast segment, the failure has to work its way through a Designated Router and a network-LSA that only the DR controls. On a Point-to-Point link, there's no DR, no network-LSA, and nothing waiting on anyone else's timer. Same failure, same protocol, two different recovery paths.
This note is narrowly about that gap: what actually happens in each router's own link-state database when the link goes down, a real four-router case with the LSA output from both sides of the same failure, the DR/BDR overhead that only broadcast segments carry, and the commands to check which network type a segment is actually running before it becomes the reason a failover took longer than it should have. For the neighbor state-machine flow when an adjacency won't form at all, see OSPF Neighbor Troubleshooting; for where network-type defaults and DR/BDR behavior differ between vendors, see the Huawei-Cisco OSPF Interop note.
Same physical event, same OSPF area — the diagram below is what each router actually has to do about it, and how long it takes.
Broadcast on top, Point-to-Point below. The DR/BDR structure that broadcast introduces is exactly the part of the timeline that point-to-point skips entirely.
Diagram labels are kept in English for engineering clarity.
The difference isn't in whether a router notices a failure — it's in which structures have to change before the rest of the network can act on it.
On a Point-to-Point link, the two connected routers exchange only router-LSAs, and each one carries a link entry describing the neighbor directly — plus a separate stub-network entry for the interface itself. That neighbor-describing entry only exists while the adjacency is actually Full. The moment the interface goes down, the router that owns it stops carrying that entry in its very next router-LSA. Nothing else has to change first.
On a Broadcast segment, the same physical failure has to be reflected in two separate structures: each router's own router-LSA (a Transit Network entry pointing at the segment's Designated Router), and a separate network-LSA that only the DR originates, listing every attached router still considered Full. A non-DR router losing its link can update its own router-LSA right away and recompute its own routes fast. But the network-LSA — and the DR's own router-LSA entry for that segment — don't change until the DR itself notices the neighbor is gone, which on a shared segment means waiting out its own dead-timer for that neighbor, not the interface going down.
<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 segmentDR/BDR election exists to stop every router on a multi-access segment from forming a full mesh of adjacencies with every other router on it — instead, everyone adjacencies with the DR and BDR only. That's a real efficiency win when a segment genuinely has several routers on it. But it also means the segment's very existence in the link-state database now depends on one specific router's view of things: as long as the DR itself hasn't declared a neighbor dead, the rest of the network has to assume the segment topology hasn't changed, even if one attached router's link to it clearly has. A Point-to-Point link skips this entirely — there's no DR, nothing to elect, and nothing that must wait on a third party's timer before the rest of the network can trust the update.
<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 p2pSYMPTOMA link that's really just two routers on a dedicated segment still takes the long way to reconverge after a failure, as if it were a large multi-access LAN.
CAUSENetwork type defaults to Broadcast on Ethernet interfaces regardless of how many routers actually share the segment. A segment with exactly two routers still elects a DR and BDR, still builds a network-LSA, and still gates that network-LSA's removal on the DR's own dead-timer — even though there was never a third router that needed the DR/BDR machinery in the first place.
FIXIf a segment is dedicated to exactly two routers and always will be, set both ends to point-to-point deliberately with ospf network-type p2p, rather than accepting the broadcast default by omission.
SYMPTOMConvergence looks asymmetric — the router that actually lost the link recomputes routes almost immediately, but the rest of the network doesn't fully reconverge until roughly a dead-timer interval later.
CAUSEWhen the failing link belongs to a non-DR router, that router updates its own router-LSA right away. But the network-LSA for the segment is only originated by the DR, and the DR doesn't know the neighbor is gone until its own dead-timer for that neighbor expires — it isn't watching the interface that failed, it's watching the adjacency it holds with that neighbor.
FIXBefore treating a stuck-looking reconvergence as a fault, check which router is the DR for the affected segment with display ospf interface — if it's the DR's own dead-timer running out, that's expected broadcast-segment behavior, not a bug.
SYMPTOMAfter switching a link to point-to-point network type, someone checks the LSDB expecting the same LSA types as before, and assumes something is broken because the network-LSA for that segment is simply gone.
CAUSEA P2P router-LSA still carries a link entry describing the neighbor — it just does it directly, as part of each router's own router-LSA, rather than through a shared network-LSA. There was never a separate network-LSA to look for once the link is P2P.
FIXCheck display ospf lsdb on both ends — expect two Router-type entries with point-to-point-style links, and confirm there's no Network-type entry for that segment; that absence is correct for P2P, not a symptom of a problem.
SYMPTOMThe moment ospf network-type p2p is applied on one end, the neighbor relationship drops immediately, even though nothing about the physical link itself changed.
CAUSENetwork type is one of the parameters that must match between two OSPF neighbors for the adjacency to stay up at all. Changing it on one side without the other creates an immediate mismatch, and even changing both sides together forces the state machine to restart, since DR/BDR status and the LSA types involved both change at once.
FIXApply the change on both ends inside the same maintenance window, and reverify with display ospf interface and display ospf peer verbose immediately after.
SYMPTOMAfter a failover, an expected LSA update never shows up in a neighbor's own LSDB, and it looks as if the convergence mechanism itself has failed.
CAUSEThe command ospf filter-lsa-out (all / summary / ase / nssa) is a legitimate optimization for cutting unnecessary LSA floods on a specific outgoing interface — often deployed deliberately to reduce LSDB size and improve convergence speed when multiple parallel links exist between two routers. If someone configured it previously and it was forgotten, a filtered LSA type simply never arriving looks exactly like a stuck convergence.
FIXBefore treating a missing LSA update as a fault, check display current-configuration interface for an ospf filter-lsa-out statement on the interface in question.
The same physical test, run twice — once at the default network type, once forced to point-to-point — makes the difference concrete instead of theoretical.
The network: four routers running OSPF area 0. SW2 and SW4 share a segment, with SW4 acting as DR for it. Normal traffic between SW2 and a loopback on SW4 (4.4.4.4) transits a third router, SW3. The test: keep a continuous ping from SW2 to 4.4.4.4 running, then physically disconnect SW2's link to SW4, and watch what each router's own LSAs actually do on each network type.
With the SW2–SW4 link left at its default broadcast network type, disconnecting it doesn't clear the adjacency immediately. SW2 notices right away and reissues its own router-LSA without the shared network in it, then recomputes its own routes fast. SW4's router-LSA and its network-LSA for that segment don't change yet — SW4 is still counting down its own dead-timer for the neighbor it lost. The show ip ospf nei output below is captured mid-countdown, before the timer runs out:
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 outSwitching that same SW2–SW4 link to point-to-point network type changes the outcome, not just the timing. On a P2P link there's no DR/BDR relationship and no network-LSA layer to wait on at all. SW2 stops advertising the link the instant its own interface goes down; SW4 does the same the moment its neighbor relationship breaks, because a P2P router-LSA only carries the neighbor-describing link entry while the adjacency is actually Full. Neither side is stuck waiting on the other's dead-timer for the network to fully reconverge — the entire wait visible in the broadcast trace above simply doesn't exist on point-to-point.
The practical lesson isn't "P2P is always better" — a P2P link can't serve a segment with three or more routers on it in the first place. It's that network type isn't just a configuration detail decided at adjacency-formation time: it pre-decides how failure actually propagates through the link-state database, and it's worth setting deliberately — with display ospf interface confirmed on both ends — rather than discovering it by accident during an outage when convergence speed actually matters.
This note is built around one real four-router OSPF convergence case, using the original show output from the source material, plus the standard Broadcast/P2P LSA mechanics described in Huawei's own OSPF LSA-filtering reference. It doesn't cover NBMA or P2MP network types, OSPFv3, BFD-accelerated failure detection, or how these numbers shift on a segment secured with authentication — those each deserve their own look.
The questions that come up whenever this convergence gap is actually on the table.
Not to path selection under normal conditions — cost is set independently of network type. What changes is entirely about the failure path: which LSA structures have to be rebuilt, and whose timer the rest of the network is waiting on when the link actually breaks.
The wait is tied to whichever router is acting as DR for that segment, because only the DR originates the network-LSA. If the failing side is DR-Other on both ends, the segment's DR is a third router that has to notice the neighbor loss through its own dead-timer — the mechanism is the same, it's just gated by a different router's timer, not necessarily the one whose link physically failed.
Only if the router leaving is the DR or BDR itself. If a non-DR, non-BDR router's link fails, there's no re-election at all — the existing DR and BDR simply update the network-LSA to remove that router once its own dead-timer expires. Re-election only happens when the DR or BDR itself is the one that goes down.
No — point-to-point is specifically for a link connecting exactly two routers with no other neighbor sharing that segment. A multi-access LAN with three or more OSPF routers has to run Broadcast (or NBMA), because point-to-point has no mechanism at all for more than one neighbor per interface.
This note assumes the adjacency already works and is about what happens to a working adjacency when its link fails. For the full state-machine diagnostic flow — Down through Init, 2-Way, ExStart, Exchange, Loading to Full — see OSPF Neighbor Troubleshooting.
Send us the display ospf interface output from both ends — we'll tell you what happens to that segment the moment the link drops.