
Where We Finally Explain How OSPF Actually Chooses a Path—Without Math Trauma
You’ve made it to Post 5—congratulations. At this point, you know more about OSPF than the average person knows about their own taxes.
Now we finally lift the hood and look at the part of OSPF that actually makes decisions:
SPF — the Shortest Path First algorithm, courtesy of Edsger Dijkstra, a man who clearly enjoyed clarity, efficiency, and making network engineers sweat.
This is the part that turns topology into reality — and when it misbehaves, entire networks feel it.
Don’t worry—this isn’t going to be a math lecture. This is the “explain-it-to-a-senior-architect-at-2-AM” version.
What SPF Actually Does (Without the Hype)
SPF takes OSPF’s LSDB (aka the encyclopedia of network gossip) and turns it into:
• A shortest-path tree
• A set of best routes
• A stable forwarding table
It’s the part of OSPF that actually decides, “This is the fastest path to get traffic from here to there.”
OSPF doesn’t run SPF constantly (that would melt your routers).
It runs when it has to:
• A topology change
• A new LSA
• A dead link
• A neighbor goes out for cigarettes and never returns
This is why we design to limit LSDB churn—every SPF run is CPU work.

How SPF Builds the Shortest Path Tree (SPT)
Think of SPF as building a family tree, except instead of tracking your weird uncle who only shows up for the holidays, it tracks network links.
Here’s the simplified steps:
Step 1 — Start With You (the Local Router)
OSPF begins the tree at itself.
This is the “root” of the tree.
Everything else is calculated in relation to you.
Step 2 — Look at All Directly Connected Links
OSPF pulls the Type 1 (Router) and Type 2 (Network) LSAs from the LSDB.
It sees:
• Which neighbors you have
• The cost to reach them
• What networks exist around you
These form the first “ring” of the tree.
Step 3 — Explore Neighbors’ Links
For each neighbor, OSPF checks their LSAs:
• Who they can reach
• At what cost
• Through which links
OSPF continues exploring outward, ring after ring, like ripples in a pond.
Step 4 — Choose the Lowest-Cost Paths
At every branch, OSPF picks the lowest cumulative cost.
OSPF cost formula (default):
Cost = 10^8 / bandwidth (in bps)
This is why old FastEthernet links have a cost of 10— which is why FastEthernet still haunts old designs.
Step 5 — Build the Final Tree and Routing Table
Once the SPT is complete, OSPF pulls the best next-hops from the tree and installs them into the routing table.
Done.
Clean.
Deterministic.
Mathematically beautiful (in a nerdy way).
The SPF Tree: Visual Metaphor Edition
Picture SPF like arranging your commute:
• You start at home (root)
• You check connections from your street (direct neighbors)
• You explore the city map (the LSDB)
• You pick the fastest route to each destination
• You ignore roads with construction, floods, or terrible cost metrics
• You write the whole plan down in your GPS (RIB)
That’s SPF.
SPF Isn’t Free — Why It Can Hurt Performance
SPF is CPU-heavy because it processes an entire topology graph.
If your LSDB is large and constantly changing, your routers will:
• Run SPF too often
• Burn CPU cycles
• Cause route churn
• Eventually enter a spiral of pain
This is why OSPF design philosophy exists:
• Limit area size
• Summarize routes
• Reduce LSA flooding
• Avoid unstable links
• Keep adjacency count sane
SPF is elegant. Deterministic. Brutally honest. It will always do the right thing — even when your design makes that painful.
Incremental SPF: OSPF’s Efficiency Hack
Modern OSPF implementations (Cisco, Juniper, Arista, FRR, etc.) use:
• Partial SPF runs
• Incremental recalculations
• SPF throttling
• LSA propagation pacing
Meaning OSPF tries hard not to blow your router’s CPU every time someone jiggles a cable.
Architect’s Corner: The SPF Design Rules We Live By
• Avoid too many ABRs — They generate summary LSAs which trigger SPF.
• Use point-to-point links — Fewer DR elections, fewer LSAs.
• Summarize routes at area borders — Smaller LSDB = faster SPF.
• Stabilize your links — SPF hates flapping interfaces.
• Keep areas small-ish — SPF scales with LSDB size.
And most importantly:
Never underestimate the CPU impact of 1,000 external routes being redistributed every 30 seconds.
(Ask me how I know.)
⸻
Coming Next: “OSPF Design Tips – Lessons From the Field (and the Outages)”
Post 6 is where we get practical:
• Real-world OSPF design philosophy
• Multi-area layouts that actually work
• Where most people go wrong
• How to avoid OSPF-induced meltdowns
• Architecture patterns from enterprise, DC, and WAN environments