Editing Open Shortest Path First (section)

==Router relationships==

{| class="wikitable" 
|+ Network types (OSPFv2)
|-
! style="text-align:right;vertical-align:bottom;border-right: solid 2px" | Network type 
! style="vertical-align:bottom;border-right: solid 2px " | Point to point (P2P)
! style="vertical-align:bottom;" | Broadcast (default)
! style="vertical-align:bottom;border-right: solid 2px " | Non-broadcast multi-access (NBMA)
! style="vertical-align:bottom;" | Point to multipoint
! style="vertical-align:bottom;border-right: solid 2px " | Point to multipoint non broadcast (P2MP-NB)
! style="vertical-align:bottom;" | Passive
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px" | Max routers per network
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" | 2
| Unlimited
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" | Unlimited
| Unlimited
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" | Unlimited
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " | Full mesh assumed
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{Yes}}
| {{Yes}}
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{Yes}}
| {{No}}
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{No}}
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |Hello timer (default Cisco)
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |10
| 10
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |30
| 30
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |30
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px" |Dead timer (default Cisco)
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |40
| 40
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |120
| 120
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |120
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px" |Wait timer
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |0
| equal to dead timer
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |equal to dead timer
| 0
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |0
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |Automatic neighbour discovery
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{yes}}
| {{yes}}
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{No}}
| {{yes}}
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " {{No}}
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px" |Discovery and hellos are sent to
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" |224.0.0.5
| 224.0.0.5
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" |Neighbour IP
| 224.0.0.5
| style="text-align:center;vertical-align:bottom;border-right: solid 2px" |Neighbour IP
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |Neighbour communication is sent to
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |224.0.0.5
| [[Unicast]]
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |[[Unicast]]
| [[Unicast]]
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |[[Unicast]]
| {{nan|text=na}}
|- style="text-align:center;vertical-align:bottom;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |LSAs are sent to
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |224.0.0.5
| DR/BDR: 224.0.0.6<br />All: 224.0.0.5
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |DR/BDR: 224.0.0.6<br />All: 224.0.0.5
| [[Unicast]]
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |[[Unicast]]
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |Next-hop IP
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Peer
| Original router
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Original router
| Hub
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Hub
| {{nan|text=na}}
|- style="text-align:center;vertical-align:middle;"
! style="text-align:right;vertical-align:bottom;border-right: solid 2px " |Imported in to OSPF as 
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Stub and P2P
| Transit
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Transit
| Stub and P2P
| style="text-align:center;vertical-align:bottom;border-right: solid 2px " |Stub and P2P
| Stub
|}
OSPF supports complex networks with multiple routers, including backup routers, to balance traffic load on multiple links to other subnets. Neighboring routers in the same [[broadcast domain]] or at each end of a [[point-to-point link]] communicate with each other via the OSPF protocol. Routers form ''adjacencies'' when they have detected each other. This detection is initiated when a router identifies itself in a ''hello'' protocol packet. Upon acknowledgment, this establishes a ''two-way state'' and the most basic relationship. The routers in an Ethernet or Frame Relay network select a ''designated router'' (DR) and a ''backup designated router'' (BDR) which act as a hub to reduce traffic between routers. OSPF uses both [[unicast]] and multicast transmission modes to send "hello" packets and link-state updates.

As a link-state routing protocol, OSPF establishes and maintains neighbor relationships for exchanging routing updates with other routers. The neighbor relationship table is called an ''adjacency database''. Two OSPF routers are neighbors if they are members of the same subnet and share the same area ID, subnet mask, timers and authentication. In essence, OSPF neighborship is a relationship between two routers that allow them to see and understand each other but nothing more. OSPF neighbors do not exchange any routing information{{snd}} the only packets they exchange are hello packets. OSPF adjacencies are formed between selected neighbors and allow them to exchange routing information. Two routers must first be neighbors and only then, can they become adjacent. Two routers become adjacent if at least one of them is designated router or backup designated router (on multiaccess-type networks), or they are interconnected by a point-to-point or point-to-multipoint network type. For forming a neighbor relationship between, the interfaces used to form the relationship must be in the same OSPF area. While an interface may be configured to belong to multiple areas, this is generally not practiced. When configured in a second area, an interface must be configured as a secondary interface.

===Operation modes===
The OSPF can have different operation modes on the following setups on an interface or network:
* [[Point-to-point (network topology)|Point-to-point]]. Each router advertises itself by periodically multicasting hello packets. No designated router is elected. The interface can be [[IPv4#Unnumbered interface|IP unnumbered]] (without a unique IP address assigned to it).
* [[Broadcasting (networking)|Broadcast]] (default), each router advertises itself by periodically multicasting hello packets.
* [[Non-broadcast multiple-access network|Non-broadcast multi-access]], with the use of designated routers. May need static configuration. Packets are sent as [[unicast]]. 
* [[Point-to-multipoint]], where OSPF treats neighbours as a collection of point-to-point links. No designated router is elected. Separate hello packets are sent to each neighbor.
* Point to Multipoint Non Broadcast (P2MP-NB), No designated router is elected. Separate hello packets are sent to each neighbor, Packets are sent as [[unicast]].
* Passive, Only advertised to other neighbours. No adjacency is advertised on network.

====Indirect connections====

Virtual link over Virtual links, [[Tunneling protocol|tunneling]] and sham links, are a form of connections that goes over the routing engine, and is not a direct connection to the remote host.

* Virtual links: The packets are sent as [[unicast]]. Can only be configured on a non-backbone area (but not stub-area). Endpoints need to be ABR, the virtual links behave as unnumbered point-to-point connections. The cost of an intra-area path between the two routers is added to the link.
* Virtual link over [[Tunneling protocol|tunneling]] (like [[Generic Routing Encapsulation|GRE]] and [[WireGuard]]): Since OSPF does not support virtual links for areas other than the backbone, a workaround is the use of tunneling.<ref>{{Cite web|title=[Junos] GRE Configuration Example - Juniper Networks|url=https://kb.juniper.net/InfoCenter/index?page=content&id=KB19371|access-date=2021-11-28|website=kb.juniper.net|archive-date=November 28, 2021|archive-url=https://web.archive.org/web/20211128172846/https://kb.juniper.net/InfoCenter/index?page=content&id=KB19371|url-status=live}}</ref> If the same [[IPv4|IP]] or [[IPv4#Unnumbered interface|router ID]] is used, the link creates two equal-cost routes to the destination.<ref>{{Cite web|title=Generic Routing Encapsulation (GRE) {{!}} Interfaces User Guide for Switches {{!}} Juniper Networks TechLibrary|url=https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-gre.html|access-date=2021-11-28|website=www.juniper.net|archive-date=November 28, 2021|archive-url=https://web.archive.org/web/20211128172845/https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-gre.html|url-status=live}}</ref>
* Sham link{{Ref RFC|4577}}:<ref name="Juniper-sham-link">{{cite web |title=Understanding OSPF Sham Links - Technical Documentation - Support - Juniper Networks |url=https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ospf-sham-links-overview.html |website=www.juniper.net |access-date=14 November 2021 |archive-date=November 14, 2021 |archive-url=https://web.archive.org/web/20211114144842/https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ospf-sham-links-overview.html |url-status=live }}</ref><ref name="Cico-sham-link">{{cite web |title=IP Routing: OSPF Configuration Guide, Cisco IOS Release 15SY - OSPF Sham-Link Support for MPLS VPN [Cisco IOS 15.1SY] |url=https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-sy/iro-15-sy-book/iro-sham-link.html |website=Cisco |access-date=14 November 2021 |language=en |archive-date=November 1, 2021 |archive-url=https://web.archive.org/web/20211101213057/https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-sy/iro-15-sy-book/iro-sham-link.html |url-status=live }}</ref> An intra-area link that connects two sites via the MPLS VPN backbone that is preferred to an internal intra-area "OSPF backdoor link" between the same two sites. A sham link is only needed if the MPLS VPN backbone is preferred over the OSPF backdoor link.

===Adjacency state machine===
Each OSPF router within a network communicates with other neighboring routers on each connecting interface to establish the states of all adjacencies. Every such communication sequence is a separate ''conversation'' identified by the pair of router IDs of the communicating neighbors. RFC 2328 specifies the protocol for initiating these conversations (''Hello Protocol'') and for establishing full adjacencies (''database description packets'', ''link-state request packets''). During its course, each router conversation transitions through a maximum of eight conditions defined by a state machine:<ref name="rfc2328"/><ref>{{cite web |url=http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html |title=OSPF Neighbor States |website=Cisco |access-date=2018-10-28 |archive-date=October 26, 2018 |archive-url=https://web.archive.org/web/20181026025203/https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html |url-status=live }}</ref>

====Neighbor state changes====
[[File:OSPF-Adjacency-process.drawio.png|thumb|Neighbor state changes (Hello Protocol)]]
#Down: The state ''down'' represents the initial state of a conversation when no information has been exchanged and retained between routers with the Hello Protocol.
#Attempt: The ''attempt'' state is similar to the ''down'' state, except that a router is in the process of efforts to establish a conversation with another router, but is only used on [[non-broadcast multiple-access network]]s (NBMAs).
#Init: The ''init'' state indicates that a hello packet has been received from a neighbor, but the router has not established a two-way conversation.
#Two-way: The ''two-way'' state indicates the establishment of a bidirectional conversation between two routers. This state immediately precedes the establishment of adjacency. This is the lowest state of a router that may be considered as a DR.

====Database exchange====
[[File:OSPF-Adjacency-process-Neighbor state changes (Database Exchange).drawio.png|thumb|Neighbor state changes (database exchange)]]
#Exchange start (exstart): The ''exstart'' state is the first step of adjacency of two routers.
#Exchange: In the ''exchange'' state, a router is sending its link-state database information to the adjacent neighbor. At this state, a router can exchange all OSPF routing protocol packets. 
#Loading: In the ''loading'' state, a router requests the most recent [[link-state advertisement]]s (LSAs) from its neighbor discovered in the previous state.
#Full: The ''full'' state concludes the conversation when the routers are fully adjacent, and the state appears in all router- and network-LSAs. The link-state databases of the neighbors are fully synchronized.

===Broadcast networks===
In broadcast multiple-access networks, neighbor adjacency is formed dynamically using multicast hello packets to {{IPaddr|224.0.0.5}}.

 IP 192.0.2.1 > 224.0.0.5: OSPFv2, hello
 IP 192.0.2.2 > 224.0.0.5: OSPFv2, hello
 IP 192.0.2.1 > 192.0.2.2: OSPFv2, database description
 IP 192.0.2.2 > 192.0.2.1: OSPFv2, database description

===Passive network===
A network where OSPF adverts the network, but the OSPF will not start neighbour adjacency.

===Non-broadcast networks===
In a [[non-broadcast multiple-access]] (NBMA) network, a neighbor adjacency is formed by sending [[unicast]] packets to another router. A non-broadcast network can have more than two routers, but broadcast is not supported.

 IP 192.0.2.1 > 192.0.2.2: OSPFv2, hello
 IP 192.0.2.2 > 192.0.2.1: OSPFv2, hello
 IP 192.0.2.1 > 192.0.2.2: OSPFv2, database description
 IP 192.0.2.2 > 192.0.2.1: OSPFv2, database description

Examples of non-broadcast networks:
* [[X.25]] [[public data network]]
* [[Wireguard]]
* [[Serial interface]]


* Requires all routers to be able to communicate directly, on the same network.
* Designated Router is elected for the network. 
* LSA is generated for the network.