What Is OSPF?
Open Shortest Path First (OSPF) is a link-state interior gateway protocol (IGP) standardized by the IETF in RFC 2328 (OSPFv2 for IPv4) and RFC 5340 (OSPFv3 for IPv6). Unlike distance-vector protocols that pass routing tables between neighbors, OSPF routers exchange raw topology information in the form of Link State Advertisements (LSAs) and independently compute the best path to every destination using Dijkstra's Shortest Path First algorithm.
OSPF operates entirely within a single autonomous system. Its hierarchical area model, fast convergence characteristics, and absence of a hop-count limit have made it the dominant IGP in enterprise and service provider networks for decades. Where RIP runs out of gas at 15 hops and converges in minutes, OSPF scales to thousands of routers and converges in seconds — or milliseconds when paired with BFD.
How OSPF Works
Router ID Selection
Every OSPF router is identified by a unique 32-bit Router ID (RID), presented in dotted-decimal notation. The router selects its RID in order of priority: an explicitly configured RID takes precedence, followed by the highest IP address on any loopback interface, and finally the highest IP address on any active physical interface. In production, always configure the RID explicitly on a stable loopback to prevent the RID from changing when a link flaps — a RID change forces the router to re-establish all adjacencies and re-flood its LSAs.
! Cisco IOS — configure OSPF process 1 with a fixed Router ID
router ospf 1
router-id 10.0.0.1
network 192.168.1.0 0.0.0.255 area 0
network 10.0.0.0 0.0.0.255 area 0
auto-cost reference-bandwidth 10000The Neighbor State Machine
Before any topology data is shared, OSPF must bring two routers through a well-defined adjacency state machine. Understanding this sequence is essential for diagnosing stuck adjacencies — one of the most common OSPF troubleshooting scenarios in production.
- Down — No Hello packets have been received from this neighbor within the Dead interval.
- Attempt — Applies only on NBMA networks. The local router is sending unicast Hellos but has not yet received a response.
- Init — A Hello has arrived from the neighbor, but the local router's own RID does not yet appear in that Hello's neighbor list, meaning communication is still one-directional.
- 2-Way — Bidirectional communication is confirmed; the local RID appears in the neighbor's Hello. On multi-access segments, DR and BDR election occurs at this stage. DROther routers remain at 2-Way with each other indefinitely — this is normal, not a fault.
- ExStart — The two routers negotiate a master/slave relationship using Database Description (DBD) packets. The router with the higher RID becomes master and controls the exchange sequence numbers.
- Exchange — DBD packets summarizing each router's Link State Database (LSDB) are exchanged. No full LSA content is sent yet, only headers.
- Loading — Each router sends Link State Request (LSR) packets to obtain the full content of LSAs that were listed in DBD packets but not yet held locally. The peer responds with Link State Update (LSU) packets.
- Full — Both routers have synchronized LSDBs. The adjacency is complete and stable.
Hello Protocol and Adjacency Parameters
OSPF Hellos are sent to the multicast address 224.0.0.5 (AllSPFRouters). For an adjacency to advance past Init, both routers must agree on four parameters: Hello interval, Dead interval, Area ID, and authentication. Mismatched MTU values also block adjacency formation on most platforms. Default timer values depend on network type:
- Broadcast and Point-to-Point: Hello = 10 seconds, Dead = 40 seconds
- NBMA: Hello = 30 seconds, Dead = 120 seconds
! Verify OSPF neighbor states on sw-infrarunbook-01
sw-infrarunbook-01# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:38 192.168.1.2 GigabitEthernet0/1
10.0.0.3 1 FULL/BDR 00:00:35 192.168.1.3 GigabitEthernet0/1
10.0.0.4 0 FULL/DROTHER 00:00:32 192.168.1.4 GigabitEthernet0/1
10.0.0.5 0 2WAY/DROTHER 00:00:33 192.168.1.5 GigabitEthernet0/1Designated Router and Backup Designated Router
On multi-access segments such as Ethernet, OSPF elects a Designated Router (DR) and a Backup Designated Router (BDR) to reduce the O(n²) adjacency problem. Without DR/BDR, every router would need a full adjacency with every other router on the segment. With DR/BDR, each DROther forms full adjacencies only with the DR and BDR. LSA flooding is handled by the DR, which multicasts updates to 224.0.0.5; DROthers send updates to the DR at 224.0.0.6 (AllDRRouters).
DR election is based on OSPF interface priority (highest wins, default 1). Ties are broken by Router ID. Priority 0 makes a router ineligible for DR/BDR roles — useful for spoke routers in a hub-and-spoke design. Critically, DR election is non-preemptive: once elected, the DR keeps its role until it fails, regardless of new higher-priority routers joining the segment.
OSPF Areas and Hierarchical Design
OSPF organizes routers into areas to limit the scope of LSA flooding and SPF recalculation. Area 0, the backbone, is mandatory. All non-backbone areas must connect to Area 0 either physically or via a virtual link. Inter-area traffic always transits Area 0, preventing routing loops at the area level.
Area Types
- Backbone Area (Area 0): The transit core. Must be contiguous. All ABRs connect here.
- Standard Area: Receives all LSA types including Type 5 external routes.
- Stub Area: Blocks Type 4 and Type 5 LSAs. The ABR injects a default route (Type 3) to reach external destinations, shrinking the LSDB significantly for edge routers.
- Totally Stubby Area (Cisco proprietary): Blocks Type 3, 4, and 5 LSAs. Only the default route is injected. Best for branch offices with a single uplink where the full routing table is unnecessary.
- Not-So-Stubby Area (NSSA): Defined in RFC 3101. Blocks Type 5 LSAs from entering the area but permits a local ASBR to redistribute external routes as Type 7 LSAs. The ABR translates Type 7 to Type 5 at the boundary.
Router Roles
- Internal Router: All interfaces in a single OSPF area.
- Area Border Router (ABR): Interfaces in two or more areas; maintains a separate LSDB for each area and generates Type 3 and Type 4 LSAs.
- Autonomous System Boundary Router (ASBR): Redistributes routes from external routing domains into OSPF; generates Type 5 (or Type 7 in NSSA) LSAs.
- Backbone Router: Has at least one interface in Area 0; may also be an ABR or internal router.
OSPF LSA Types Explained
LSAs are the building blocks of OSPF topology exchange. Each LSA has a type field, a Link State ID, an Advertising Router field (the originating router's RID), a sequence number, an age field (max age is 3600 seconds), and a checksum. Routers store received LSAs in their LSDB and run SPF against the combined database to build their routing table.
Type 1 — Router LSA
Originated by every OSPF router — one per area the router participates in. Describes the router's interfaces within that area, their states (point-to-point, transit, stub, virtual), and their associated OSPF costs. Flooded only within the originating area. This LSA is the raw material from which the intra-area topology is assembled.
Type 2 — Network LSA
Originated by the Designated Router on any multi-access segment that has at least two attached OSPF routers. Lists all routers attached to the segment, representing it as a pseudo-node in the SPF graph. Flooded only within the originating area. On point-to-point links, no DR exists and therefore no Type 2 LSA is generated.
Type 3 — Summary LSA (Network Summary LSA)
Generated by ABRs to advertise inter-area prefixes. When a router in Area 1 needs to reach a prefix in Area 2, it does not see Area 2's Type 1 and Type 2 LSAs — it sees only Type 3 LSAs injected by the ABR. This is how OSPF achieves scalability: remote areas appear as a set of reachable prefixes with associated costs, not as a full topology. Flooded throughout the OSPF domain except into stub and totally stubby areas.
Type 4 — ASBR Summary LSA
Also generated by ABRs. Advertises the location (Router ID) of an ASBR to routers in other areas. Without Type 4 LSAs, a router in a remote area would see a Type 5 external route but have no way to determine which ABR to use to reach the originating ASBR. Type 4 LSAs are not flooded into stub areas.
Type 5 — AS External LSA
Generated by ASBRs for every prefix redistributed into OSPF from an external routing domain — BGP routes, EIGRP routes, static routes, connected networks. Flooded throughout the entire OSPF domain, crossing area boundaries, except into stub and NSSA areas. Two metric types are supported: E1 routes accumulate the internal OSPF cost to reach the ASBR plus the external metric; E2 routes (the default) carry only the external metric regardless of internal distance. E1 is more accurate when multiple ASBRs redistribute the same prefix at different internal distances.
Type 6 — Multicast OSPF LSA
Defined for Multicast OSPF (MOSPF). Carries multicast group membership information to enable multicast-aware SPF calculations. MOSPF is not supported by most modern vendors and has been superseded by PIM-based multicast. Type 6 LSAs will not appear in any current production OSPF deployment and can be safely ignored.
Type 7 — NSSA External LSA
Functionally equivalent to a Type 5 LSA but confined to the NSSA where it originates. Generated by an ASBR inside an NSSA to redistribute external routes without breaking the stub-like properties of the area. When the Type 7 LSA reaches the NSSA ABR, the ABR translates it into a Type 5 LSA (setting the Forwarding Address from the Type 7 LSA) and floods it into Area 0 and all other non-stub areas. If multiple ABRs border the NSSA, only the ABR with the highest RID performs translation by default, preventing duplicate Type 5 LSAs.
Type 8 — Link LSA (OSPFv3 Only)
Used exclusively in OSPFv3 (IPv6). Provides the originating router's link-local address and lists the IPv6 prefixes associated with that link. Flooded only on the local link (link-local scope). There is no OSPFv2 equivalent because IPv4 address information is embedded directly in Type 1 and Type 2 LSAs.
Type 9 — Intra-Area Prefix LSA (OSPFv3 Only)
Used in OSPFv3 to carry IPv6 prefix information that OSPFv2 embeds inside its Router and Network LSAs. Separates address information from topology information, allowing OSPFv3 to remain address-family agnostic. One or more Type 9 LSAs are associated with each router or transit network in an area.
Opaque LSAs — Types 9, 10, and 11
Defined in RFC 2370, Opaque LSAs extend OSPF without modifying the base protocol. They carry application-specific TLV-encoded data and are categorized by flooding scope: Type 9 is link-local scoped, Type 10 is area-scoped, and Type 11 is AS-scoped. The most widely deployed use case is OSPF Traffic Engineering (RFC 3630), which uses Type 10 Opaque LSAs to flood TE attributes such as maximum link bandwidth, available bandwidth, administrative color (affinity), and SRLG membership. These TE LSAs feed the CSPF (Constrained Shortest Path First) computation in MPLS-TE implementations.
! Inspect the full LSDB on sw-infrarunbook-01
sw-infrarunbook-01# 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 412 0x80000009 0x00C3A1 3
10.0.0.2 10.0.0.2 398 0x80000007 0x00A2F4 2
10.0.0.3 10.0.0.3 401 0x80000005 0x00B1D3 2
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.1.2 10.0.0.2 388 0x80000003 0x00D4E2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
172.16.10.0 10.0.0.4 520 0x80000002 0x00F3A1
172.16.20.0 10.0.0.4 520 0x80000002 0x00E2B3
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.0.0.6 10.0.0.4 540 0x80000001 0x00A1C2
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.0.0.6 612 0x80000001 0x00C1D2 0
8.8.8.0 10.0.0.6 612 0x80000001 0x00B3E1 0OSPF Cost Metric and Path Selection
OSPF uses a dimensionless metric called cost. The default formula is: cost = reference bandwidth / interface bandwidth. With the default reference bandwidth of 100 Mbps, a Fast Ethernet (100 Mbps) interface has cost 1, a 10 Mbps Ethernet interface has cost 10, and a 1 Gbps interface also has cost 1. This means Gigabit, 10G, 40G, and 100G interfaces are all indistinguishable by default — a known design flaw. Always raise the reference bandwidth to match the fastest links in your network.
! Set reference bandwidth to 10 Gbps (10000 Mbps)
! Run this on ALL routers in the OSPF domain for consistency
router ospf 1
auto-cost reference-bandwidth 10000
! Result: 1G = cost 10, 10G = cost 1, 100M = cost 100
! Override cost on a specific interface
interface GigabitEthernet0/2
ip ospf cost 50When multiple routes to the same destination exist, OSPF selects by route type before comparing costs. The preference order is: intra-area (O) beats inter-area (O IA), which beats external type 1 (O E1), which beats external type 2 (O E2), which beats NSSA type 1 (O N1), which beats NSSA type 2 (O N2). Within the same route type, lowest total cost wins. Equal-cost paths are installed simultaneously, enabling ECMP load balancing.
Why OSPF Matters in Production Networks
OSPF has remained dominant across enterprise and service provider networks because it solves real operational problems that simpler protocols cannot:
- Fast convergence: SPF recalculation is event-driven, not timer-driven. Incremental SPF (iSPF) limits recalculation to only the affected portion of the topology tree. When BFD (Bidirectional Forwarding Detection) is enabled, link failures are detected in under 100 milliseconds and immediately reported to OSPF, making sub-second failover achievable.
- Hierarchical scalability: Area boundaries contain LSA flooding and SPF scope. A change inside Area 1 triggers SPF only in Area 1; other areas see only a modified Type 3 LSA from the ABR, not the full topology change.
- No hop-count limitation: OSPF's cost metric is purely bandwidth-derived. Networks spanning hundreds of router hops operate identically to small networks.
- ECMP load balancing: Multiple equal-cost paths are installed in the forwarding table simultaneously, providing both redundancy and throughput aggregation without additional protocol machinery.
- Authentication: MD5 and SHA-HMAC cryptographic authentication prevent unauthorized routers from injecting LSAs — a critical control against both accidental misconfiguration and deliberate route injection attacks.
- Mature tooling: Decades of deployment mean OSPF debugging commands, monitoring integrations, and operational runbooks are universally available across all major platforms.
Real-World Example: Multi-Area OSPF at solvethenetwork.com
The solvethenetwork.com infrastructure uses a three-area OSPF design. sw-infrarunbook-01 is the ABR connecting the backbone (Area 0, prefix 10.0.0.0/24) to two branch areas. Area 1 (172.16.10.0/24) is a stub area serving a branch with a single uplink. Area 2 (172.16.20.0/24) is an NSSA where a branch router redistributes a locally attached monitoring network as an external route. An ASBR in Area 0 redistributes a BGP default route from the upstream ISP.
! sw-infrarunbook-01 — ABR configuration
! Backbone: 10.0.0.0/24 (Area 0)
! Branch 1: 172.16.10.0/24 (Area 1 — Stub)
! Branch 2: 172.16.20.0/24 (Area 2 — NSSA)
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface GigabitEthernet0/0
description Backbone_Link
ip address 10.0.0.254 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 R0ut3rAuth!
!
interface GigabitEthernet0/1
description Branch1_Link
ip address 172.16.10.254 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 R0ut3rAuth!
!
interface GigabitEthernet0/2
description Branch2_Link
ip address 172.16.20.254 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 R0ut3rAuth!
!
router ospf 1
router-id 10.0.0.1
auto-cost reference-bandwidth 10000
area 1 stub no-summary
area 2 nssa
network 10.0.0.0 0.0.0.255 area 0
network 172.16.10.0 0.0.0.255 area 1
network 172.16.20.0 0.0.0.255 area 2
passive-interface GigabitEthernet0/3In this design, branch routers in Area 1 carry only three LSAs in their LSDB: their own Type 1, the Type 2 from the DR on their segment, and a single Type 3 default route injected by sw-infrarunbook-01. The branch router in Area 2 generates Type 7 LSAs for its monitoring subnet; sw-infrarunbook-01 translates these into Type 5 LSAs and floods them into Area 0. The infrarunbook-admin team manages all OSPF authentication keys via a centralized secrets store, rotating them quarterly.
Common Misconceptions About OSPF
Misconception 1: All OSPF routers on a segment form full adjacencies with each other
On broadcast segments, DROther routers form full adjacencies only with the DR and BDR. Between two DROther routers, the state is 2-Way — bidirectional Hellos are exchanged but no LSDB synchronization occurs. This is correct behavior and not a fault. Misinterpreting 2-Way as a problem leads engineers to make unnecessary changes that disrupt the network.
Misconception 2: Setting a higher OSPF priority guarantees DR role
OSPF DR election is non-preemptive. A router with priority 255 that joins a segment where a DR is already elected with priority 1 will become BDR, not DR. The incumbent DR retains its role until it fails or the OSPF process is restarted on all segment routers. Plan DR placement during initial deployment, not after the fact.
Misconception 3: Type 3 LSAs carry the source area's full topology
Type 3 LSAs are opaque distance advertisements — they carry only a prefix and a cost value. The receiving router has no visibility into the internal topology of the originating area. This information hiding is intentional: it keeps SPF calculations small and prevents instability in one area from triggering SPF recalculations in others.
Misconception 4: Stub areas cannot perform any external redistribution
A standard stub area blocks incoming Type 5 LSAs from the rest of the domain. An NSSA, however, explicitly allows a local ASBR to redistribute external routes as Type 7 LSAs. The stub-like behavior (no external Type 5 flooding from outside) is preserved while still supporting local redistribution — which is precisely why NSSA was defined in RFC 3101.
Misconception 5: OSPF always picks the cheapest path
Cost comparison only applies within the same route type. An intra-area route (O) with cost 1000 always wins over an inter-area route (O IA) with cost 1. If you see unexpected path selection, check the route type first using
show ip routebefore assuming a cost misconfiguration.
Frequently Asked Questions
Q: What is the difference between OSPF Type 1 and Type 2 LSAs?
A: Type 1 (Router LSA) is generated by every OSPF router and describes its own interfaces, link states, and associated costs within a single area. Type 2 (Network LSA) is generated only by the Designated Router on a multi-access segment and lists all routers attached to that segment. Both LSA types are flooded only within the originating area and are never forwarded across area boundaries.
Q: Why is Area 0 mandatory, and what happens if it becomes partitioned?
A: Area 0 is the backbone through which all inter-area routing traffic must flow. OSPF's two-level hierarchy relies on a single contiguous backbone to prevent inter-area routing loops. If Area 0 is physically partitioned, inter-area routing between the disconnected halves breaks. Virtual links can reconnect a partitioned backbone by extending Area 0 logically through a transit non-backbone area, but this is a workaround — permanent physical backbone connectivity is the correct solution.
Q: What is the practical difference between E1 and E2 external routes?
A: E2 routes (the default) carry only the external metric set at the ASBR. The internal OSPF cost to reach the ASBR from different parts of the domain is ignored when comparing E2 routes. E1 routes add the internal OSPF cost to the external metric, so two routers at different distances from the same ASBR see different total costs. E1 is the correct choice when multiple ASBRs are redistributing the same external prefix at different points in the topology, as it ensures the closest ASBR is always preferred.
Q: How does OSPF handle equal-cost multipath (ECMP)?
A: When the SPF algorithm finds multiple paths to the same destination with identical total costs, OSPF installs all of them into the routing information base simultaneously. The forwarding plane load-balances traffic across these paths — typically per-flow (based on a hash of src/dst IP and port) to maintain packet ordering within a flow. The number of supported ECMP paths varies by platform: commonly 4, 8, or 16 paths. ECMP is transparent to the control plane and requires no additional configuration beyond ensuring equal costs exist.
Q: What is a virtual link and when is it appropriate to use one?
A: A virtual link is a logical point-to-point OSPF connection configured between two ABRs, tunneled across a non-backbone transit area. It is used to either reconnect a partitioned Area 0 or to connect a new area to Area 0 when a direct physical connection is not available. Virtual links are a last-resort measure — they add operational complexity, obscure the true topology, and complicate troubleshooting. A dedicated physical or logical (VLAN, subinterface) connection to Area 0 is always the preferred architecture in production.
Q: How does OSPF authentication protect the routing domain?
A: OSPF supports three authentication modes: null (Type 0, no authentication), simple plaintext (Type 1, sends the password in cleartext — never use in production), and cryptographic MD5/SHA-HMAC (Type 2, recommended). Cryptographic authentication signs every OSPF packet with a keyed hash. Any packet with a missing or incorrect hash is silently dropped, preventing unauthorized routers from forming adjacencies, injecting false LSAs, or poisoning the LSDB. Authentication keys should be rotated regularly and stored in a secrets management system accessible to infrarunbook-admin.
Q: What triggers an SPF recalculation, and how can it be tuned?
A: SPF runs whenever the LSDB changes in a way that affects topology — a link going up or down, a cost change, a new router appearing. To protect CPU during link instability (flapping links), OSPF implements SPF throttling with three configurable timers: an initial delay before the first SPF run, a minimum hold time between successive runs, and a maximum hold time (exponential backoff ceiling). Tuning these timers is a balance: too aggressive and CPU spikes during instability; too conservative and convergence is delayed during real failures. Typical production values are 50ms initial / 200ms hold / 5s max.
Q: What is LSA throttling, and why does it matter?
A: LSA throttling limits how frequently a router can originate or re-originate the same LSA. Without throttling, a flapping interface can cause a router to flood thousands of LSA updates per second, overwhelming neighbors' LSDB processing and consuming excessive CPU and memory across the domain. LSA throttling imposes a minimum interval (arrival rate limiter) between successive originations of the same LSA, stabilizing the flooding behavior during instability. On Cisco IOS, this is controlled by the
timers throttle lsacommand in the OSPF process configuration.
Q: How does an NSSA ABR decide which router translates Type 7 to Type 5 LSAs?
A: When multiple ABRs border an NSSA, only one should perform Type 7 to Type 5 translation to prevent duplicate Type 5 LSAs from flooding the domain. By default, the ABR with the highest OSPF Router ID is elected as the translator. This election is automatic and reflected in the Type 7 LSA's Translator State bit. The election can be influenced by configuring
area X nssa translate type7 suppress-fato control Forwarding Address handling, or by manipulating RIDs to prefer a specific ABR as translator.
Q: Can OSPF and BGP coexist on the same router, and how do they interact?
A: Yes — coexistence of OSPF and BGP on the same router is the standard architecture in enterprise and service provider networks. OSPF (or another IGP) handles internal reachability: loopback addresses, infrastructure links, management prefixes. BGP carries internet routes, customer prefixes, or VPN routes. BGP next-hops are resolved via OSPF-advertised infrastructure routes. Mutual redistribution between OSPF and BGP is possible but dangerous without careful filtering: redistributing full BGP tables into OSPF will overwhelm the LSDB, and redistributing OSPF routes into BGP without filtering leaks internal topology to external peers.
Q: What is BFD and how does it improve OSPF convergence?
A: Bidirectional Forwarding Detection (BFD) is a lightweight, protocol-independent hello mechanism that detects forwarding-plane failures in milliseconds — far faster than OSPF's Dead timer (40 seconds by default). BFD sessions run independently of OSPF but are registered as clients. When a BFD session fails, the BFD daemon immediately notifies OSPF, which declares the neighbor down and triggers SPF without waiting for the Dead timer. BFD with aggressive timers (300ms hello / 3x multiplier = 900ms detection) enables sub-second OSPF convergence on platforms that support hardware-assisted BFD.
Q: Where should OSPF route summarization be performed?
A: OSPF supports manual summarization at two points only: at ABRs for inter-area routes (suppressing specific Type 3 LSAs and replacing them with a summary), and at ASBRs for external routes (suppressing specific Type 5 LSAs). Unlike EIGRP, OSPF never auto-summarizes. Summarization reduces LSDB size, limits SPF scope, and hides specific link failures from remote areas — but at the cost of precision. Over-aggressive summarization can cause traffic to continue flowing toward a summarized prefix even when all specific routes within it are unreachable. Always verify that summarization boundaries align with actual address allocation boundaries.