OSPF LSA Flooding & SPF
OSPF floods link-state advertisements so every router builds an identical map of the area, then each runs Dijkstra over it to compute routes. When a link fails, convergence is a pipeline — flood the change, wait the SPF timer, run SPF, install the RIB, program the FIB — and each stage costs more as the topology grows. Change the topology and SPF timer and watch the flooding scope and convergence time move. Validated against FRRouting ospfd/ospf_flood.c, ospf_spf.c, ospf_route.c and RFC 2328.
What you'll explore
- 01
The LSA Types and Their Scope
OSPF doesn't advertise routes — it advertises pieces of the topology, and the type of the LSA decides how far that piece travels. A Router-LSA (Type 1) is originated by every router to describe its own links and floods only within its area. A Network-LSA (Type 2) is originated by the Designated Router to describe who is on a broadcast segment, also area-scoped. A Summary-LSA is originated by an ABR to carry reachability across an area boundary: Type 3 advertises an inter-area network prefix, while Type 4 advertises reachability to an ASBR so other areas can compute paths toward external routes. An AS-External-LSA (Type 5) is originated by an ASBR and floods across the entire routing domain. Getting this scope model right is the difference between reading a converged LSDB and guessing at one.
- 02
Reliable Flooding
Flooding is how every router in a scope ends up with a byte-identical link-state database. When a router receives an LSA it first runs the MinLSArrival check — a copy that arrived too recently is discarded without acknowledgement, which damps flooding storms — then installs the newer instance in its LSDB and re-floods it out every interface except the one it arrived on. Each re-origination bumps the LS sequence number so routers can tell newer from older, and floods are explicitly acknowledged, making OSPF flooding reliable rather than best-effort. A topology change floods a new LSA immediately; with no change, LSAs still refresh periodically so they never age out.
- 03
SPF: Dijkstra, Per Area
Once the LSDB is consistent, each router independently runs Dijkstra's shortest-path-first algorithm over it, rooted at itself, to build a shortest-path tree and derive routes. The work is bounded by the area's size — more routers and links mean a larger graph and a heavier computation on every topology change — which is exactly why a single flat area does not scale. FRR throttles how often SPF runs with a delay timer: too high and reconvergence lags a real failure; too low and rapid flaps can pin the CPU recomputing. The SPF timer in this simulator is that delay.
- 04
Areas Contain the Blast Radius
Areas exist because both flooding and SPF are expensive at scale, and areas bound both. Intra-area (Router/Network) LSAs never leave their area, so a change in one area doesn't force every router in the domain to re-flood or recompute; each router's Dijkstra runs only over its own area's database. Area Border Routers stitch areas to the backbone (Area 0) by injecting Summary-LSAs, and can aggregate prefixes to shrink the summaries further. Stub areas go further still: they refuse AS-External LSAs and lean on a default route, trading external detail for a much smaller LSDB — which is safe only if the area truly has no ASBR and no need for the full external table.
- 05
The Convergence Sequence
Convergence after a link failure is a pipeline, and its total time is the sum of its stages, not any single one. First the change is detected and an updated LSA is flooded through the scope; then each router waits out its SPF delay timer; then SPF runs; then the results are installed into the routing table (RIB); and finally the RIB is programmed into the forwarding table (FIB) by zebra. Flooding time grows with the topology, the SPF delay is a tunable you own, and the RIB/FIB install is a near-fixed cost. When someone says 'OSPF took 30 seconds to reconverge,' the answer is almost always in which of these stages dominated.
Validated against FRRouting frr-10.6.1 — ospfd/ospf_flood.c and friends. Every simulated behavior cites a real source function, and a server-side correlation engine computes how each layer's state cascades into the next. See the methodology →
This module is part of zerohop Pro — it unlocks alongside the full kata library, progress tracking, and weak-area analysis.