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.

Launch Simulator →

What you'll explore

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

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

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

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

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