# Open Shortest Path First
**Open Shortest Path First** (OSPF) is a link-state interior gateway protocol (IGP) that routes IP traffic within a single Autonomous System: each router floods its local link state to all others, keeps an identical link-state database, and computes a shortest-path tree from that database to build its [routing table](https://www.edgepedia.org/routing-table).[1](https://datatracker.ietf.org/doc/html/rfc2328) OSPF recalculates routes quickly after topology changes while using a minimum of routing protocol traffic, supports equal-cost multipath, and divides a routing domain into areas for additional protection and reduced traffic.[1](https://datatracker.ietf.org/doc/html/rfc2328)
| Key fact | Detail |
|---|---|
| Protocol family | Link-state IGP for a single Autonomous System; routing table built as a shortest-path tree from a shared link-state database[1](https://datatracker.ietf.org/doc/html/rfc2328) |
| Current IPv4 version | OSPFv2, specified in RFC 2328 (April 1998), authored by John Moy; obsoletes RFC 2178[2](https://www.rfc-editor.org/info/rfc2328/) |
| IPv6 version | OSPFv3, introduced in RFC 2740 (1999) and replaced by RFC 5340 (July 2008)[3](https://www.ws.afnog.org/afnog2013/sie/231-isis/is-is-ospf.pdf) |
| Neighbor detection | Periodic HELLO messages; a neighbor is declared down after 40 seconds without HELLOs in OSPF[4](https://www.rfc-editor.org/info/rfc2791/) |
| Area structure | Non-backbone areas must all connect to a single backbone area (area 0), which limits the design to a two-level hierarchy[5](https://ftp.u-strasbg.fr/rfc/rfc2791.txt.pdf) |
| Fast failure repair | Loop-free alternates give precomputed backup next-hops, targeting failure reaction in tens of milliseconds[6](https://www.rfc-editor.org/info/rfc5286/) |
| Modern extensions | IGP Flexible Algorithm (RFC 9350, February 2023) lets OSPFv2 and OSPFv3 compute constraint-based paths with Segment Routing steering[7](https://www.rfc-editor.org/info/rfc9350/) |
## History
Development of OSPF began in 1987 in the IETF. Version 1 was published as RFC 1131 in October 1989, authored by John Moy.[8](https://www.rfc-editor.org/info/rfc1131/) Version 2 followed in RFC 1247 (July 1991), with further revisions in RFC 1583 (1994), RFC 2178 (1997), and the current RFC 2328 (April 1998), which fixed minor problems; all of these OSPFv2 RFCs were authored by Moy.[3](https://www.ws.afnog.org/afnog2013/sie/231-isis/is-is-ospf.pdf) The changes from version 1 to version 2 were not backward-compatible, so the two versions do not interoperate.[9](https://www.rfc-editor.org/rfc/rfc1247.html)
The IPv6 version, OSPFv3, appeared in RFC 2740 in 1999 and was replaced by RFC 5340 in July 2008.[3](https://www.ws.afnog.org/afnog2013/sie/231-isis/is-is-ospf.pdf) RFC 2328 remains the base specification and has been updated by eight later RFCs, covering HMAC-SHA cryptographic authentication (RFC 5709), multi-instance extensions (RFC 6549), manual key management security (RFC 7474), BFD strict-mode (RFC 9355), and terminology updates (RFC 9454), among others.[2](https://www.rfc-editor.org/info/rfc2328/)
## How it works
In a link-state routing protocol, each router maintains a database describing the Autonomous System's topology, and every participating router holds an identical copy. Each piece of the database is a particular router's local state, such as its usable interfaces and reachable neighbors, and the router distributes that local state throughout the Autonomous System by flooding.[1](https://datatracker.ietf.org/doc/html/rfc2328) All routers then run the same algorithm in parallel: from the link-state database each constructs a tree of shortest paths with itself as root, and this shortest-path tree gives the route to every destination in the Autonomous System.[1](https://datatracker.ietf.org/doc/html/rfc2328)
The path computation uses the Dijkstra algorithm. At each iteration a list of candidate vertices is held; the candidate closest to the root is guaranteed to be on a shortest path, so it is added to the tree and its neighbors are examined. A path's link state cost is the sum of the costs of its constituent links as advertised in router-LSAs and network-LSAs, and one path is shorter than another if it has a smaller cost.[1](https://datatracker.ietf.org/doc/html/rfc2328)
Routers discover and maintain adjacencies through the exchange of HELLO messages sent periodically from each node. When a node fails to receive HELLO messages from a neighbor within a certain period, 40 seconds in OSPF, it considers the neighbor down.[4](https://www.rfc-editor.org/info/rfc2791/) The Hello protocol also carries configured state such as the dead-interval, router priority for designated-router election, election results, and each router's optional capabilities.[10](https://docs.frrouting.org/en/latest/ospfd.html)
## Areas and scaling
OSPF allows sets of networks to be grouped into areas, and the topology of an area is hidden from the rest of the Autonomous System, which produces a significant reduction in routing traffic.[9](https://www.rfc-editor.org/rfc/rfc1247.html) Each area must be connected to a common backbone area by an Area Border Router (ABR). ABRs summarize an area's link-state routing information into Summary LSAs, possibly in aggregated form, and originate those summaries into every other area they connect to. Only summaries and external routes pass between areas; because these describe paths rather than router link-states, routing between areas is by distance-vector, not link-state.[10](https://docs.frrouting.org/en/latest/ospfd.html)
The area structure also bounds the protocol's hierarchy. In OSPF all areas must connect via the backbone area, which eliminates the possibility of more than two levels of hierarchy; IS-IS has the same limitation.[5](https://ftp.u-strasbg.fr/rfc/rfc2791.txt.pdf) A scalable design should avoid including too many routers in an IGP area, carrying a large number of external routes in the IGP, and, above all, excessive adjacencies in an area; when the topology is unstable, the computation, processing, and bandwidth costs are magnified, and if instability prevents the protocol from maintaining adjacencies, a routing meltdown occurs.[4](https://www.rfc-editor.org/info/rfc2791/)
Stub and Not-So-Stubby areas were designed to minimize link-state database and routing-table sizes for a area's internal routers, allowing routers with minimal resources to participate in very large OSPF routing domains.[11](https://datatracker.ietf.org/doc/html/rfc5340) Cisco's totally-stubby area, a proprietary extension of the standard stub area, additionally excludes summarized network routes as well as external routes, further reducing the OSPF database size.[12](https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide/BN_Campus_Technologies.html) In enterprise campus designs, Cisco recommends placing the campus core in the OSPF backbone area and configuring the aggregation layer systems in the ABR role, interconnecting the backbone to access-layer non-backbone areas.[12](https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide/BN_Campus_Technologies.html)
## OSPFv3 and IPv6
OSPFv3 carries IPv6 prefixes and revised LSA formats. Neighboring routers on a link are always identified by their OSPF Router ID, which contrasts with the IPv4 version, and loopback interfaces advertise their prefixes with prefix length 128 and metric 0 in intra-area-prefix-LSAs.[11](https://datatracker.ietf.org/doc/html/rfc5340) OSPFv3 requires only IPv6 link-local addresses to form adjacencies.[13](https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/07/) Extensions in RFC 5838 added support for additional address families in OSPFv3.[14](https://datatracker.ietf.org/doc/rfc5838/)
## Fast failure repair and traffic engineering
Applications such as [Voice over IP](https://www.edgepedia.org/voice-over-ip) can be sensitive to traffic losses greater than tens of milliseconds, while a router's convergence time is generally on the order of hundreds of milliseconds. IP Fast Reroute addresses this gap: a router whose local link fails forwards traffic to a pre-computed loop-free alternate next-hop until distributed convergence completes. A neighbor N provides a loop-free alternate to destination D when Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D), meaning forwarding through N cannot loop. The mechanism assumes routing runs over a link-state protocol such as OSPF or IS-IS and requires no support from other routers, though its coverage depends on the network topology.[6](https://www.rfc-editor.org/info/rfc5286/)
For traffic engineering, RFC 9350 specifies extensions to OSPFv2 and OSPFv3 that let a router advertise a Flexible Algorithm Definition, a combination of calculation type, metric type, and topology constraints, so that the IGP itself computes constraint-based paths rather than relying on external RSVP-TE or SR-TE computation. Segment Routing Prefix-SIDs or SRv6 locators are then associated with a Flex-[Algorithm](https://www.edgepedia.org/algorithm) to steer packets along those paths.[7](https://www.rfc-editor.org/info/rfc9350/) Later RFCs extended the definition with bandwidth, delay, and additional constraints (RFC 9843) and a reverse-affinity constraint (RFC 9917).[7](https://www.rfc-editor.org/info/rfc9350/)
## Security
The OSPFv2 cryptographic authentication defined in RFC 2328 and updated in RFC 5709 has two documented weaknesses: it does not include the IP header in the authenticated data, so an attacker can change a packet's IP source address to produce denial-of-service attacks or disrupt an adjacency, and its per-packet sequence numbers are reinitialized when an adjacency goes down, which can be exploited for replay attacks. RFC 7474 defines extensions to the authentication mechanism to prevent these IP-layer attacks.[15](https://www.rfc-editor.org/pdfrfc/rfc7474.txt.pdf) A 2013 analysis under the IETF's Keying and Authentication for Routing Protocols (KARP) program examined the security state of both OSPFv2 and OSPFv3 and identified gaps whose solutions were already underway.[16](https://www.rfc-editor.org/rfc/rfc6863.html) For OSPFv3, authentication and confidentiality are provided by RFC 4552.[17](https://www.rfc-editor.org/rfc/rfc9492.html)
## OSPF compared with IS-IS
OSPF and IS-IS are the two link-state IGPs in wide use; a large network typically employs one of them as its interior routing protocol and BGP as its exterior protocol.[4](https://www.rfc-editor.org/info/rfc2791/) A 1991 IEEE Network comparison evaluated the two protocols' ability to route IP traffic, and later analyses have treated them as two landmarks in the link-state design space, attributing their differences to engineering trade-offs made by their designers.[18](https://ieeexplore.ieee.org/document/121955/) • [19](https://users.cs.fiu.edu/~afanasyev/assets/papers/zhang2017isis-ospf.pdf) OSPF was created by the IETF expressly for IP networks, while IS-IS was originally designed for the ISO networking paradigm and later adapted to IP routing.[20](https://www.ijfmr.com/papers/2020/5/11550.pdf) In practice, OSPF is widely deployed in enterprise networks, while IS-IS is popular among service providers for large deployments.[20](https://www.ijfmr.com/papers/2020/5/11550.pdf)
## References
1. [RFC 2328: OSPF Version 2, J. Moy, April 1998](https://datatracker.ietf.org/doc/html/rfc2328)
2. [RFC 2328: OSPF Version 2, RFC Editor info page](https://www.rfc-editor.org/info/rfc2328/)
3. [Comparing IS-IS and OSPF, AFNOG presentation](https://www.ws.afnog.org/afnog2013/sie/231-isis/is-is-ospf.pdf)
4. [RFC 2791: Scalable Routing Design Principles, July 2000](https://www.rfc-editor.org/info/rfc2791/)
5. [RFC 2791 (PDF), University of Strasbourg mirror](https://ftp.u-strasbg.fr/rfc/rfc2791.txt.pdf)
6. [RFC 5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates, September 2008](https://www.rfc-editor.org/info/rfc5286/)
7. [RFC 9350: IGP Flexible Algorithm, February 2023](https://www.rfc-editor.org/info/rfc9350/)
8. [RFC 1131: OSPF specification, October 1989](https://www.rfc-editor.org/info/rfc1131/)
9. [RFC 1247: OSPF Version 2, July 1991](https://www.rfc-editor.org/rfc/rfc1247.html)
10. [FRRouting OSPFv2 documentation](https://docs.frrouting.org/en/latest/ospfd.html)
11. [RFC 5340: OSPF for IPv6, July 2008](https://datatracker.ietf.org/doc/html/rfc5340)
12. [Cisco Borderless Campus 1.0 Design Guide](https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide/BN_Campus_Technologies.html)
13. [draft-ietf-ospf-transition-to-ospfv3, OSPFv3 over IPv4 for IPv6 Transition](https://datatracker.ietf.org/doc/draft-ietf-ospf-transition-to-ospfv3/07/)
14. [RFC 5838: Support of Address Families in OSPFv3](https://datatracker.ietf.org/doc/rfc5838/)
15. [RFC 7474: Security Extension for OSPFv2 When Using Manual Key Management, April 2015](https://www.rfc-editor.org/pdfrfc/rfc7474.txt.pdf)
16. [RFC 6863: Analysis of OSPF Security According to the KARP Design Guide, March 2013](https://www.rfc-editor.org/rfc/rfc6863.html)
17. [RFC 9492: OSPF Application-Specific Link Attributes](https://www.rfc-editor.org/rfc/rfc9492.html)
18. [A comparison between two routing protocols: OSPF and IS-IS, IEEE Network, September 1991](https://ieeexplore.ieee.org/document/121955/)
19. [Similar Yet Different: Protocol Design Choices in IS-IS and OSPF, Zhang et al.](https://users.cs.fiu.edu/~afanasyev/assets/papers/zhang2017isis-ospf.pdf)
20. [OSPF vs IS-IS comparison, International Journal for Multidisciplinary Research](https://www.ijfmr.com/papers/2020/5/11550.pdf)
---
*Topic: Encyclopedia › Technology and the built world › Computing and digital systems › Networks and security › Networking fundamentals and architecture › Routing and addressing › Routing protocols and daemons*
*Initially written Sep 17, 2026 · Reviewed: Oct 15, 2026 · Edited: Oct 15, 2026 · Last review: Oct 15, 2026*
*Copyright 2026 EdgeChat AI, a subsidiary of Biostate AI.*
License: Edgepedia Community License 1.0, https://www.edgepedia.org/edgepedia/license