OSPF Deep Dive Part 3: The SPF Algorithm, Cost, and Route Selection
Parts 1 and 2 got every router in this series’ lab to a Full adjacency with an identical LSDB per area. None of that puts a single route in a routing table. That’s a separate step, and it’s where OSPF stops being a flooding protocol and starts being a routing protocol: each router runs Dijkstra’s shortest-path-first algorithm against its own copy of the LSDB, independently, and arrives at a shortest-path tree with itself at the root.
Running SPF is a local calculation, not a shared one
This is worth stating plainly because it’s easy to assume the LSDB being identical means the resulting routes are somehow computed once and distributed. They aren’t. CORE-CSR, BRANCH-FGT, and EDGE-MX each run their own SPF calculation, rooted at themselves, against the same set of LSAs. The math only agrees because the inputs agree. If two routers in the same area ever disagree about a route, the LSDB itself is the first place to look, not the routing table, because a routing table difference is always downstream of either a database difference or a genuinely different root node producing a genuinely different shortest path.
The algorithm itself builds a tree, not a graph walk to one destination. Starting from itself, a router adds the closest unvisited node, then the next closest, and so on, accumulating cost along the way, until every reachable router and network in the area is placed in the tree at its true shortest-path cost. Intra-area routes come directly off this tree. Inter-area routes (from Type 3 LSAs) and external routes (from Type 5/7 LSAs) get added afterward, using the intra-area tree to resolve the next hop toward whichever ABR or ASBR originated them.
Cost, and the trap every vendor shares
OSPF cost is inversely proportional to bandwidth: cost = reference-bandwidth / interface-bandwidth. All three platforms in this series default the reference bandwidth to 100 Mbps, a value that made sense when Fast Ethernet was the fastest common interface and has not aged well since. The formula means a 100 Mbps interface costs 1. A 1 Gbps interface also costs 1, because the formula floors at 1 and never goes below it, and a 10 Gbps interface costs 1 too, for the same reason. Three interfaces spanning a hundred-fold difference in actual capacity all present the same cost to SPF, which will happily prefer a path across three Fast-Ethernet-cost hops over a single 10 Gbps hop if the hop count comes out lower, because SPF only ever minimizes total cost, not bandwidth.
Every serious OSPF deployment raises the reference bandwidth, and every serious OSPF deployment has to raise it identically on every router in the domain, because cost is only ever meaningful in comparison, and a mismatched reference bandwidth between two routers doesn’t produce an error. It produces a routing table that’s internally consistent on each router and quietly wrong relative to the other one. Parts 7 through 9 cover the exact command on each platform. The concept to take from this post is that “my costs look fine on this router” is not the same claim as “my costs agree across the domain,” and the second one is the only claim that matters to SPF.
ECMP: multiple paths, one cost
When SPF finds two or more paths to the same destination with identical total cost, OSPF doesn’t pick one arbitrarily and discard the rest. It installs all of them as Equal-Cost Multi-Path routes, up to a platform-specific maximum path count. CORE-CSR to Area 1’s 10.10.10.0/24 subnet in this lab has exactly one path once Area 2’s virtual link is up in Part 4, so ECMP doesn’t show up naturally in this topology, but it’s worth knowing the failure mode: a link that’s supposed to provide redundancy but was configured with a slightly different cost (a different bandwidth statement, a different reference-bandwidth setting inherited before a change, an interface that auto-negotiated to a different speed than assumed) won’t show up as a broken redundant path. It’ll show up as a redundant path that simply never carries traffic, because it lost the tie by one unit of cost and SPF has no concept of “close enough.”
Why route type beats cost, always
This is the part of OSPF route selection that catches people who otherwise understand SPF completely: cost only breaks ties within the same route type. Route type itself is preferred in a fixed order that cost can never override.
- Intra-area routes (O)
- Inter-area routes (O IA)
- External Type 1 routes (E1), where the external cost accumulates with the internal cost to reach the ASBR
- External Type 2 routes (E2), where only the external cost counts, and the internal cost to reach the ASBR is ignored entirely once compared
An intra-area route with a cost of 1000 is still preferred over an inter-area route with a cost of 10, every time, because the comparison never gets that far. OSPF checks route type first and only compares cost between routes of the same type. This is a deliberate design choice, not an edge case: it reflects that a route learned entirely within one area is assumed to be based on more complete, more current information than one that’s been summarized across an area boundary, regardless of what the numbers say.
The E1/E2 distinction inside external routes matters for exactly the redistribution scenario Area 1 sets up in this lab. A static route redistributed as E2 (the default on all three platforms) is compared to other E2 candidates using only its configured external cost, so two ASBRs redistributing the same prefix with the same external cost produce a genuine tie regardless of how far away either ASBR actually is. Redistributing as E1 instead makes that internal distance part of the comparison, which is usually what’s actually wanted when a network has more than one exit point advertising the same external prefix. Part 4 covers the redistribution syntax on all three vendors; this post is the reason to care about which metric type gets chosen when it does.
Next up: virtual links, summarization, and redistribution, the three things an ABR/ASBR actually does with everything covered so far.