Link State Flooding Workbench

Link State Flooding Workbench

Trace how a link-state advertisement is installed, acknowledged, reflooded, or rejected before SPF runs

Interactive link-state flooding animation showing LSA origination, sequence-number freshness checks, duplicate suppression, neighbor acknowledgements, retransmission, area scope, LSDB convergence, and SPF trigger behavior.

Link-state routing Controlled flooding LSDB before SPF

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.

R1 Router-LSAadvertisement

seq 0x8000002Afreshness

install + floodreceiver action

6/6 routersLSDB coverage

Scenario

Flood Controls

Flooding scope area local Area local Whole teaching domain Stop at area boundary

LSA age 80 s

Neighbor reliability reliable flood Reliable flood One missing ack Duplicate copy arrives

Ready: inspect LSA header

Watch For

Flooding is controlled, not blind broadcast. The receiver checks freshness first, then decides whether to install, flood onward, acknowledge, or discard.

Newer LSAHigher sequence, newer instance, or better checksum wins the database slot.

Same LSASame instance is a duplicate; acknowledge if needed, but do not reflood forever.

Older LSALower sequence is stale and must not overwrite the LSDB.

SPF triggerDijkstra runs after the LSDB changes, not for every duplicate packet.

Flooding Domain

originate LSA

1. Originatebuild LSA

2. Checkfreshness test

3. Floodneighbors except sender

4. Ackreliable delivery

5. SPFrecompute if changed

LSDB Coverage

Readouts

R1 Router-LSALSA identity in this flooding domain

0x8000002Asequence number being compared

install + floodreceiver database action

3 flood edgesoutgoing neighbor work

acks currentreliable flooding state

SPF pendingcalculation trigger

Diagnosis

Step Transcript

Quick Reference

LSAA link-state advertisement describes one router, network, or summary object plus metadata for freshness.

LSDBThe Link State Database stores the newest accepted instance of each LSA in the flooding scope.

Flood ruleInstall newer LSAs, send them to other eligible neighbors, and acknowledge reception.

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.

Try

Choose Duplicate copy arrives, Flooding scope Area local, LSA age 80 s, and Neighbor reliability Reliable flood.

Observe

Receiver database action acknowledges but does not reinstall the same sequence/checksum instance; LSDB coverage remains unchanged after 1 duplicate.

Explain

At LSA age 80 s, the identity and freshness tuple select 1 database instance; only newer sequence/age/checksum changes LSDB and triggers SPF.

Technical boundaries. The simulator uses a small topology with scripted loss, acknowledgement, duplicate, and ageing behavior. It does not implement full OSPF or IS-IS adjacencies, areas, authentication, SPF scheduling, equal-cost paths, sequence wrap, or large-network scaling.