Why Static Routes Alone Do Not Scale
The static routes discussed earlier in this series work well for small, stable networks, but require manual reconfiguration every time the topology changes, and do not automatically route around a failed link. Dynamic Routing Protocols solve this by having routers automatically discover neighboring routers, exchange information about reachable networks, and recalculate paths when the topology changes — without requiring any manual intervention.
What Makes OSPF a Link-State Protocol
OSPF (Open Shortest Path First) belongs to a category called Link-State routing protocols, fundamentally different from simpler Distance-Vector protocols that only exchange a summarized routing table with directly connected neighbors. A link-state router instead builds a complete map of the entire network's topology, then independently calculates the best path to every destination using that full map.
Distance-vector approach:
"I can reach network X, and it costs me 3 hops"
(the neighbor trusts this summary without seeing
the actual topology behind it)
Link-state approach:
"Here is exactly how I am connected to my neighbors,
and their reported costs" (this detailed information
is flooded to every router, so every router ends up
with an identical, complete topology map)This complete topology awareness is why OSPF generally converges faster and avoids certain routing loop problems that distance-vector protocols must specifically guard against — every router calculates paths from the same complete, consistent view of the network rather than trusting summarized information passed hop by hop.
How OSPF Routers Become Neighbors
Before two OSPF routers can exchange topology information, they must first establish a Neighbor Adjacency through a multi-step process involving Hello packets sent periodically on every OSPF-enabled interface.
OSPF neighbor formation requirements —
these must match between two potential neighbors:
- Same area number on the connecting interfaces
- Same hello and dead interval timers
- Same subnet (they must be on the same network segment)
- Matching authentication configuration, if enabled
- No duplicate router IDsIf any of these values mismatch, the neighbor relationship fails to form, and no topology information is ever exchanged across that link — checking for exactly these mismatches is the standard first step when troubleshooting why two routers refuse to become OSPF neighbors.
Configuring Basic OSPF
Router(config)# router ospf 1
Router(config-router)# network 192.168.1.0 0.0.0.255 area 0
Router(config-router)# network 10.0.0.0 0.0.0.3 area 0
-- "1" is the process ID, locally significant only,
-- and does not need to match between routers
-- The network command uses a wildcard mask,
-- discussed earlier in this series regarding ACLs,
-- to identify which interfaces participate in OSPFThe network command does not directly configure OSPF on a specific interface; instead, it identifies which interface IP addresses fall within the specified range, and OSPF automatically enables itself on any matching interface — a subtlety that occasionally confuses those expecting to type an interface name directly into this command.
The Cost Metric: How OSPF Chooses the Best Path
OSPF calculates the best path to each destination using a metric called Cost, derived by default from each interface's bandwidth — lower cost is always preferred.
Default OSPF cost formula:
Cost = Reference Bandwidth / Interface Bandwidth
Default reference bandwidth: 100 Mbps
10 Mbps interface: cost = 100/10 = 10
100 Mbps interface: cost = 100/100 = 1
1 Gbps interface: cost = 100/1000 = 1 (rounds to minimum of 1)The default reference bandwidth of 100 Mbps was reasonable when OSPF was first designed, but modern networks with multi-gigabit links can end up with many different interface speeds all calculating to the same minimum cost of 1, making it impossible for OSPF to distinguish between them.
Router(config)# router ospf 1
Router(config-router)# auto-cost reference-bandwidth 10000
-- Raising the reference bandwidth to 10 Gbps (10000 Mbps)
-- restores meaningful cost differentiation between
-- modern high-speed interfaces
-- This value must be configured identically on
-- every router in the OSPF domain, or cost
-- calculations will be inconsistent across the networkVerifying OSPF Neighbors and Routes
Router# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/BDR 00:00:34 10.0.0.2 GigabitEthernet0/1
Router# show ip route ospf
O 192.168.2.0/24 [110/2] via 10.0.0.2, GigabitEthernet0/1A neighbor state of FULL confirms the two routers have completely synchronized their topology databases — any other state, such as being permanently stuck at 2-WAY or EXSTART, signals a problem in the adjacency formation process that requires further investigation. In the routing table, the [110/2] notation shows OSPF's administrative distance (110) and the calculated cost (2) to reach that specific network.
Viewing the Complete Link-State Database
Router# show ip ospf database
OSPF Router with ID (10.0.0.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
10.0.0.1 10.0.0.1 845 0x80000003 0x00a1c1 2
10.0.0.2 10.0.0.2 722 0x80000002 0x00b2d2 2This database, identical on every router within the same OSPF area, is the raw topology information from which each router independently calculates its own routing table — verifying that every router's database matches is a deeper diagnostic step when routes appear incorrect despite neighbors showing a healthy FULL state.
Why OSPF's Approach Matters for Enterprise Networks
OSPF's link-state design, fast convergence, and vendor-neutral open standard status make it the default choice for interior routing in the vast majority of enterprise networks, from small businesses to large multi-building campuses. Understanding neighbor formation requirements, the cost metric, and how to read both the neighbor table and the link-state database provides the essential foundation for the more advanced multi-area OSPF topics, such as area types and route summarization, covered later in this series.