As networks grow beyond a handful of routers, manually configuring static routes on every device becomes unmanageable — one new subnet means updating routes on every router in the path. Dynamic routing protocols solve this by letting routers automatically discover the network topology and exchange routing information with each other. OSPF (Open Shortest Path First) is one of the most widely used dynamic routing protocols in enterprise networks, and OSPFv2 specifically handles IPv4 routing. This article covers single-area OSPF — the simplest and most common starting point for understanding OSPF.
What Problem Does OSPF Solve?
Static routes work fine for small, stable networks, but they don’t scale and don’t adapt. If a link fails, a statically-routed network keeps sending traffic toward the dead path until a human notices and manually fixes it. OSPF, as a dynamic, link-state routing protocol, automatically:
- Discovers neighboring routers.
- Learns the entire network topology (within its area).
- Calculates the best path to every known destination.
- Automatically reroutes traffic if a link fails, often within seconds.
OSPF Is a Link-State Protocol — What That Means
Unlike distance-vector protocols (like RIP), which only know “how far” a destination is and via which neighbor, OSPF routers build a complete map of the entire network topology (within their area) by exchanging Link-State Advertisements (LSAs). Every OSPF router in an area ends up with an identical copy of this topology map, called the Link-State Database (LSDB). Each router then independently runs the Dijkstra Shortest Path First (SPF) algorithm against this database to calculate the best path to every destination.
flowchart TD
A[Router A] -- LSA Exchange --> B[Router B]
B -- LSA Exchange --> C[Router C]
A -- LSA Exchange --> C
A --> D[Each router builds identical LSDB]
D --> E[Each router runs SPF algorithm independently]
E --> F[Each router builds its own optimal routing table]Key OSPF Concepts
| Term | Meaning |
|---|---|
| Router ID (RID) | A unique 32-bit identifier for each OSPF router, often set manually or derived from the highest loopback/interface IP |
| Area | A logical grouping of routers; single-area OSPF uses only Area 0 (the “backbone area”) |
| Neighbor | Another OSPF router directly reachable, with which a router has formed an adjacency |
| Adjacency | A fully synchronized relationship between two neighbors, sharing complete LSDB information |
| Hello Packets | Multicast packets sent periodically to discover and maintain neighbor relationships |
| Cost (Metric) | OSPF’s path metric, calculated by default as Reference Bandwidth / Interface Bandwidth |
| DR/BDR | Designated Router / Backup Designated Router — elected on multi-access networks (like Ethernet) to reduce the number of adjacencies needed |
How OSPF Neighbors Form Adjacencies
- Down — no Hello packets received yet.
- Init — a Hello packet has been received, but the router hasn’t seen its own Router ID in the neighbor’s Hello yet.
- 2-Way — both routers see each other in each other’s Hello packets; on multi-access networks, DR/BDR election happens here.
- ExStart / Exchange — routers begin exchanging database description packets.
- Loading — routers request any missing LSAs from each other.
- Full — the adjacency is complete; both routers have identical LSDBs.
sequenceDiagram
participant RA as Router A
participant RB as Router B
RA->>RB: Hello (multicast 224.0.0.5)
RB->>RA: Hello (includes RA's Router ID - now in Init/2-Way)
RA->>RB: Hello (includes RB's Router ID - 2-Way confirmed)
RA->>RB: Database Description (ExStart/Exchange)
RB->>RA: Database Description
RA->>RB: LSA Request (Loading)
RB->>RA: LSA Update
Note over RA,RB: Adjacency reaches FULL stateOSPF Hello and Dead Timers
For two routers to become neighbors, several parameters must match, including the Hello interval (default 10 seconds on broadcast networks) and the Dead interval (default 40 seconds — 4x the Hello interval). If a router doesn’t receive a Hello within the Dead interval, it declares the neighbor down and recalculates routes.
Configuring Single-Area OSPFv2 on Cisco IOS
Basic Configuration
Router(config)# router ospf 1
Router(config-router)# router-id 1.1.1.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 0Breaking this down:
router ospf 1— starts the OSPF process;1is the process ID, locally significant only (doesn’t need to match between routers).router-id 1.1.1.1— manually sets a unique Router ID; without this, IOS picks the highest loopback IP, or if none exists, the highest active physical interface IP.network ... area 0— this is not advertising a network like a static route; it tells OSPF which interfaces to enable OSPF on, based on matching the interface’s IP against the network/wildcard statement. Any matching interface both participates in OSPF and has its connected subnet advertised.
Example Full Topology Configuration
! Router A
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
interface Serial0/0/0
ip address 10.0.0.1 255.255.255.252
router ospf 1
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0! Router B
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface GigabitEthernet0/0
ip address 192.168.2.1 255.255.255.0
interface Serial0/0/0
ip address 10.0.0.2 255.255.255.252
router ospf 1
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 192.168.2.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.3 area 0Passive Interfaces (Best Practice)
LAN interfaces facing only end hosts (no other routers) should not send unnecessary Hello packets — this reduces overhead and closes a potential security gap (preventing a rogue device from forming an unwanted OSPF adjacency).
Router(config-router)# passive-interface GigabitEthernet0/0The subnet on Gi0/0 is still advertised into OSPF; the interface simply stops sending/receiving OSPF Hello packets.
Adjusting the Reference Bandwidth (Important on Modern High-Speed Links)
By default, OSPF cost is calculated as 100 Mbps / interface bandwidth, meaning any interface 100 Mbps or faster gets the same minimum cost of 1 — this fails to differentiate between a 1 Gbps and a 10 Gbps link. Adjusting the reference bandwidth fixes this on modern networks:
Router(config-router)# auto-cost reference-bandwidth 10000This should be configured identically on every router in the OSPF domain to avoid inconsistent path cost calculations.
Verifying OSPF
Check Neighbor Relationships
Router# show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/ - 00:00:38 10.0.0.2 Serial0/0/0The state should reach FULL (or 2WAY for DR-other routers on multi-access segments, which is normal and expected).
Check the OSPF Database
Router# show ip ospf databaseCheck Which Interfaces Are Running OSPF
Router# show ip ospf interface briefInterface PID Area IP Address/Mask Cost State Nbrs F/C
Gi0/0 1 0 192.168.1.1/24 1 DR 0/0
Se0/0/0 1 0 10.0.0.1/30 64 P2P 1/1Check the Routing Table for OSPF-Learned Routes
Router# show ip route ospfO 192.168.2.0/24 [110/65] via 10.0.0.2, 00:12:44, Serial0/0/0The [110/65] shows the Administrative Distance (110 for OSPF) and the calculated cost (65).
General OSPF Process Verification
Router# show ip protocolsComparison Table: OSPF vs Static Routing vs RIP
| Feature | Static Routing | RIP | OSPF |
|---|---|---|---|
| Type | Manual | Distance-vector | Link-state |
| Convergence Speed | N/A (manual) | Slow (up to minutes) | Fast (seconds) |
| Scalability | Poor for large networks | Poor (max 15 hops) | Excellent |
| Metric | N/A | Hop count | Cost (based on bandwidth) |
| Administrative Distance | 1 (or 0 for connected) | 120 | 110 |
| Best For | Small, stable networks | Legacy/small networks | Enterprise/campus networks |
OSPF on Linux (FRRouting)
Linux servers can run real routing protocols, including OSPF, using FRRouting (FRR) — commonly used in data centers and virtualized network labs.
sudo apt install frr -y
sudo nano /etc/frr/daemonsEnable OSPF daemon:
ospfd=yessudo systemctl restart frr
sudo vtyshInside the FRR CLI (syntax deliberately mirrors Cisco IOS):
configure terminal
router ospf
ospf router-id 3.3.3.3
network 192.168.3.0/24 area 0
end
show ip ospf neighborAutomating OSPF Neighbor Verification with Python (Netmiko)
from netmiko import ConnectHandler
device = {
"device_type": "cisco_ios",
"host": "192.168.1.1",
"username": "admin",
"password": "StrongP@ssw0rd!",
}
connection = ConnectHandler(**device)
output = connection.send_command("show ip ospf neighbor")
print(output)
if "FULL" in output:
print("OSPF adjacency healthy.")
else:
print("WARNING: OSPF adjacency not FULL - investigate.")
connection.disconnect()
This kind of check is commonly built into automated network health dashboards, flagging any OSPF adjacency that isn’t in the expected FULL (or appropriate 2WAY) state.
Best Practices
- Always set a manual Router ID rather than relying on automatic selection — automatic selection can change unexpectedly if a loopback or interface is removed, causing unnecessary adjacency resets.
- Use a Loopback interface for the Router ID source — loopbacks never go down, making the Router ID stable.
- Configure passive-interface on all LAN-facing interfaces with no other routers, to reduce unnecessary Hello traffic and reduce attack surface.
- Adjust
auto-cost reference-bandwidthconsistently across all routers when using interfaces faster than 100 Mbps, to preserve accurate path selection. - Use OSPF authentication (MD5 or SHA) to prevent unauthorized devices from forming adjacencies and injecting false routing information.
- Document your area design even in single-area deployments, since many networks later grow into multi-area OSPF, and a clean starting point simplifies that future migration.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| Neighbor stuck in INIT | One-way communication (Hello sent, not received back) — often a mismatched ACL or physical issue | Check ACLs, verify Layer 1/2 connectivity |
| Neighbor stuck in 2WAY (on point-to-point, this is wrong) | Mismatched network type expectations | Verify interface types and ip ospf network settings |
| Neighbor never forms at all | Mismatched Hello/Dead timers, area number, or subnet mask | Verify show ip ospf interface timers and area on both sides match |
Route missing from show ip route ospf | Interface not included in a network statement, or wrong area configured | Verify network statement wildcard mask and area number |
| Unexpected path selection | Reference bandwidth not adjusted for high-speed links | Set consistent auto-cost reference-bandwidth network-wide |
| Router ID conflicts (duplicate RID) | Two routers coincidentally have the same Router ID | Manually set unique router-id values |
Conclusion
Single-Area OSPFv2 gives networks automatic topology discovery, fast convergence, and scalable dynamic routing — all foundational skills before progressing to multi-area OSPF designs. Understanding the neighbor formation process, correctly using network statements to enable OSPF on the right interfaces, applying passive-interface where appropriate, and knowing the key verification commands (show ip ospf neighbor, show ip route ospf, show ip ospf interface brief) are essential building blocks for any enterprise routing deployment.
References
- RFC 2328 – OSPF Version 2 — https://datatracker.ietf.org/doc/html/rfc2328
- Cisco OSPF Design Guide — https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html
- Cisco OSPFv2 Configuration Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-16/iro-xe-16-book.html
- FRRouting Documentation — https://docs.frrouting.org/
- Netmiko GitHub Repository — https://github.com/ktbyers/netmiko
