Link State Flooding Workbench
Trace how a link-state advertisement is installed, acknowledged, reflooded, or rejected before SPF runs
Link state flooding workbench
Watch one Link State Advertisement move through a flooding domain. Routers install only newer LSAs, flood accepted updates to neighbors except the incoming neighbor, acknowledge reception, suppress duplicates, and run SPF only after the Link State Database has changed.
Flooding Domain
originate LSALSDB Coverage
Readouts
Diagnosis
Step Transcript
Quick Reference
How To Read The Animation
Blue outlines mark the originating router. Teal routers have installed the current LSA. Red indicates a stale or invalid update was rejected. Orange marks a pending acknowledgement or retransmission path.
The workbench shows a teaching flooding domain. In real OSPF, exact flooding behavior depends on neighbor state, interface type, area scope, LSA type, acknowledgement mode, and retransmission lists.
Technical Accuracy Notes
This model follows the link-state routing pattern used by OSPF: LSAs carry freshness metadata, routers keep the newest instance in the LSDB, and accepted changes trigger a later SPF calculation.
Age is simplified as a visible freshness pressure. A real implementation also uses LSA type, Link State ID, advertising router, checksum, MaxAge handling, neighbor adjacency state, retransmission lists, and area scoping.
Primary references: RFC 2328 OSPF Version 2 and RFC 5340 OSPF for IPv6.