Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Open Shortest Path First
open-in-new
<h2 id="concepts">Concepts</h2> <p>OSPF is an <a href="/facts/Interior_gateway_protocol/RDWHfeLE">interior gateway protocol</a> (IGP) for routing <a href="/facts/Internet_Protocol/Qq6VeEal">Internet Protocol</a> (IP) packets within a single routing domain, such as an <a href="/facts/Autonomous_system_(Internet)/zIVqxPX1">autonomous system</a>. It gathers link state information from available routers and constructs a topology map of the network. The topology is presented as a <a href="/facts/Routing_table/tufajWvV">routing table</a> to the <a href="/facts/Internet_layer/336eMWJu">internet layer</a> which routes packets based solely on their destination <a href="/facts/IP_address/z9V22Sw9">IP address</a>. </p><p>OSPF detects changes in the topology, such as link failures, and <a href="/facts/Convergence_(routing)/p9Y4xIlJ">converges</a> on a new loop-free routing structure within seconds.<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> It computes the <a href="/facts/Shortest-path_tree/9GDrhwmY">shortest-path tree</a> for each route using a method based on <a href="/facts/Dijkstra%2527s_algorithm/ehun88jl">Dijkstra's algorithm</a>. The OSPF routing policies for constructing a route table are governed by link <a href="/facts/Metrics_(networking)/cIlvV1oH">metrics</a> associated with each routing interface. Cost factors may be the distance of a router (<a href="/facts/Round-trip_time/jYgNMK98">round-trip time</a>), data throughput of a link, or link availability and reliability, expressed as simple unitless numbers. This provides a dynamic process of traffic load balancing between routes of equal cost. </p><p>OSPF divides the network into routing <i>areas</i> to simplify administration and optimize traffic and resource utilization. Areas are identified by 32-bit numbers, expressed either simply in decimal, or often in the same octet-based <a href="/facts/Dot-decimal_notation/Tea5wKCB">dot-decimal notation</a> used for IPv4 addresses. By convention, area 0 (zero), or 0.0.0.0, represents the core or <i>backbone</i> area of an OSPF network. While the identifications of other areas may be chosen at will, administrators often select the IP address of a main router in an area as the area identifier. Each additional area must have a connection to the OSPF backbone area. Such connections are maintained by an interconnecting router, known as an area border router (ABR). An ABR maintains separate link-state databases for each area it serves and maintains <a href="/facts/Route_summarization/aC9L28rq">summarized routes</a> for all areas in the network. </p><p>OSPF runs over IPv4 and IPv6, but does not use a <a href="/facts/Transport_protocol/UmIGUCeK">transport protocol</a> such as <a href="/facts/User_Datagram_Protocol/dxLU0D6q">UDP</a> or <a href="/facts/Transmission_control_protocol/WW4sPrt9">TCP</a>. It encapsulates its data directly in IP packets with <a href="/facts/List_of_IP_protocol_numbers/lf9S6JCk">protocol number 89</a>. This is in contrast to other routing protocols, such as the <a href="/facts/Routing_Information_Protocol/xGeIuGk6">Routing Information Protocol</a> (RIP) and the <a href="/facts/Border_Gateway_Protocol/XfYgBzW3">Border Gateway Protocol</a> (BGP). OSPF implements its own transport error detection and correction functions. OSPF also uses <a href="/facts/Multicast/D9IspSfl">multicast</a> addressing for distributing route information within a broadcast domain. It reserves the <a href="/facts/Multicast_address/cIau2Hee">multicast addresses</a> <i>224.0.0.5</i> (IPv4) and <i>ff02::5</i> (IPv6) for all SPF/link state routers (AllSPFRouters) and <i>224.0.0.6</i> (IPv4) and <i>ff02::6</i> (IPv6) for all Designated Routers (AllDRouters).<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a>: 185 <a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a>: 57 For non-broadcast networks, special provisions for configuration facilitate neighbor discovery.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> OSPF multicast IP packets never traverse IP routers, they never travel more than one hop. The protocol may therefore be considered a link layer protocol, but is often also attributed to the application layer in the TCP/IP model. It has a virtual link feature that can be used to create an adjacency tunnel across multiple hops. OSPF over IPv4 can operate securely between routers, optionally using a variety of authentication methods to allow only trusted routers to participate in routing. OSPFv3 (IPv6) relies on standard IPv6 protocol security (<a href="/facts/IPsec/01MwcET1">IPsec</a>), and has no internal authentication methods. </p><p>For routing <a href="/facts/IP_multicast/YklMRaV5">IP multicast</a> traffic, OSPF supports the <a href="/facts/Multicast_Open_Shortest_Path_First/PACpGUHb">Multicast Open Shortest Path First</a> (MOSPF) protocol.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> Cisco does not include MOSPF in their OSPF implementations.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> <a href="/facts/Protocol_Independent_Multicast/cP3Tr4MA">Protocol Independent Multicast</a> (PIM) in conjunction with OSPF or other IGPs, is widely deployed. </p><p>OSPF version 3 introduces modifications to the IPv4 implementation of the protocol.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> Except for virtual links, all neighbor exchanges use IPv6 link-local addressing exclusively. The IPv6 protocol runs per link, rather than based on the <a href="/facts/Subnet/s1rQsNDv">subnet</a>. All IP prefix information has been removed from the link-state advertisements and from the <i>hello</i> discovery packet making OSPFv3 essentially protocol-independent. Despite the expanded IP addressing to 128 bits in IPv6, area and router Identifications are still based on 32-bit numbers. </p> <h2 id="router-relationships">Router relationships</h2> Network types (OSPFv2)<table><tbody><tr><th>Network type</th><th>Point to point (P2P)</th><th>Broadcast (default)</th><th>Non-broadcast multi-access (NBMA)</th><th>Point to multipoint</th><th>Point to multipoint non broadcast (P2MP-NB)</th><th>Passive</th></tr><tr><th>Max routers per network</th><td>2</td><td>Unlimited</td><td>Unlimited</td><td>Unlimited</td><td>Unlimited</td><td>na</td></tr><tr><th>Full mesh assumed</th><td>Yes</td><td>Yes</td><td>Yes</td><td>No</td><td>No</td><td>na</td></tr><tr><th>Hello (default Cisco)</th><td>10</td><td>10</td><td>30</td><td>30</td><td>30</td><td>na</td></tr><tr><th>Dead timers (default Cisco)</th><td>40</td><td>40</td><td>120</td><td>120</td><td>120</td><td>na</td></tr><tr><th>Wait timer:</th><td>0</td><td>equal to dead timer</td><td>equal to dead timer</td><td>0</td><td>0</td><td>na</td></tr><tr><th>Automatic neighbour discovery</th><td>Yes</td><td>Yes</td><td>No</td><td>Yes</td><td>No</td><td>na</td></tr><tr><th>Discovery and hellos are sent to</th><td>224.0.0.5</td><td>224.0.0.5</td><td>Neighbour IP</td><td>224.0.0.5</td><td>Neighbour IP</td><td>na</td></tr><tr><th>Neighbour communication is sent to</th><td>224.0.0.5</td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td>na</td></tr><tr><th>LSAs are sent to:</th><td>224.0.0.5</td><td>DR/BDR: 224.0.0.6All: 224.0.0.5</td><td>DR/BDR: 224.0.0.6All: 224.0.0.5</td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td><a href="/facts/Unicast/PHStTfFe">Unicast</a></td><td>na</td></tr><tr><th>Next-hop IP:</th><td>Peer</td><td>Original router</td><td>Original router</td><td>Hub</td><td>Hub</td><td>na</td></tr><tr><th>Imported in to OSPF as:</th><td>Stub and P2P</td><td>Transit</td><td>Transit</td><td>Stub and P2P</td><td>Stub and P2P</td><td>Stub</td></tr></tbody></table> <p>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 <a href="/facts/Broadcast_domain/yIC9czJ6">broadcast domain</a> or at each end of a <a href="/facts/Point-to-point_link/RmGgN1Pj">point-to-point link</a> communicate with each other via the OSPF protocol. Routers form <i>adjacencies</i> when they have detected each other. This detection is initiated when a router identifies itself in a <i>hello</i> protocol packet. Upon acknowledgment, this establishes a <i>two-way state</i> and the most basic relationship. The routers in an Ethernet or Frame Relay network select a <i>designated router</i> (DR) and a <i>backup designated router</i> (BDR) which act as a hub to reduce traffic between routers. OSPF uses both <a href="/facts/Unicast/PHStTfFe">unicast</a> and multicast transmission modes to send "hello" packets and link-state updates. </p><p>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 <i>adjacency database</i>. 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 – 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. </p> <h3>Operation modes</h3> <p>The OSPF can have different operation modes on the following setups on an interface or network: </p> <ul><li><a href="/facts/Point-to-point_(network_topology)/rBYE0kke">Point-to-point</a>. Each router advertises itself by periodically multicasting hello packets. No designated router is elected. The interface can be <a href="/facts/IPv4/bnQ5MEqm">IP unnumbered</a> (without a unique IP address assigned to it).</li> <li><a href="/facts/Broadcasting_(networking)/NRj7gHre">Broadcast</a> (default), each router advertises itself by periodically multicasting hello packets.</li> <li><a href="/facts/Non-broadcast_multiple-access_network/D7thEVhM">Non-broadcast multi-access</a>, with the use of designated routers. May need static configuration. Packets are sent as <a href="/facts/Unicast/PHStTfFe">unicast</a>.</li> <li><a href="/facts/Point-to-multipoint/6xWWhgdn">Point-to-multipoint</a>, 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.</li> <li>Point to Multipoint Non Broadcast (P2MP-NB), No designated router is elected. Separate hello packets are sent to each neighbor, Packets are sent as <a href="/facts/Unicast/PHStTfFe">unicast</a>.</li> <li>Passive, Only advertised to other neighbours. No adjacency is advertised on network.</li></ul> <h4>Indirect connections</h4> <p>Virtual link over Virtual links, <a href="/facts/Tunneling_protocol/jKaT1Czc">tunneling</a> and sham links, are a form of connections that goes over the routing engine, and is not a direct connection to the remote host. </p> <ul><li>Virtual links: The packets are sent as <a href="/facts/Unicast/PHStTfFe">unicast</a>. 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.</li> <li>Virtual link over <a href="/facts/Tunneling_protocol/jKaT1Czc">tunneling</a> (like <a href="/facts/Generic_Routing_Encapsulation/0TQRDUMK">GRE</a> and <a href="/facts/WireGuard/zSJv87LA">WireGuard</a>): Since OSPF does not support virtual links for areas other than the backbone, a workaround is the use of tunneling.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> If the same <a href="/facts/IPv4/bnQ5MEqm">IP</a> or <a href="/facts/IPv4/bnQ5MEqm">router ID</a> is used, the link creates two equal-cost routes to the destination.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a></li> <li>Sham link<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a>:<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a><a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> 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.</li></ul> <h3>Adjacency state machine</h3> <p>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 <i>conversation</i> identified by the pair of router IDs of the communicating neighbors. RFC 2328 specifies the protocol for initiating these conversations (<i>Hello Protocol</i>) and for establishing full adjacencies (<i>database description packets</i>, <i>link-state request packets</i>). During its course, each router conversation transitions through a maximum of eight conditions defined by a state machine:<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a><a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a> </p> <h4>Neighbor state changes</h4> <ol><li>Down: The state <i>down</i> represents the initial state of a conversation when no information has been exchanged and retained between routers with the Hello Protocol.</li> <li>Attempt: The <i>attempt</i> state is similar to the <i>down</i> state, except that a router is in the process of efforts to establish a conversation with another router, but is only used on <a href="/facts/Non-broadcast_multiple-access_network/D7thEVhM">non-broadcast multiple-access networks</a> (NBMAs).</li> <li>Init: The <i>init</i> state indicates that a hello packet has been received from a neighbor, but the router has not established a two-way conversation.</li> <li>Two-way: The <i>two-way</i> 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.</li></ol> <h4>Database exchange</h4> <ol><li>Exchange start (exstart): The <i>exstart</i> state is the first step of adjacency of two routers.</li> <li>Exchange: In the <i>exchange</i> 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.</li> <li>Loading: In the <i>loading</i> state, a router requests the most recent <a href="/facts/Link-state_advertisement/VkAdfMGC">link-state advertisements</a> (LSAs) from its neighbor discovered in the previous state.</li> <li>Full: The <i>full</i> 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.</li></ol> <h3>Broadcast networks</h3> <p>In broadcast multiple-access networks, neighbor adjacency is formed dynamically using multicast hello packets to <i>224.0.0.5</i>. </p> 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 <h3>Passive network</h3> <p>A network where OSPF adverts the network, but the OSPF will not start neighbour adjacency. </p> <h3>Non-broadcast networks</h3> <p>In a <a href="/facts/Non-broadcast_multiple-access/D7thEVhM">non-broadcast multiple-access</a> (NBMA) network, a neighbor adjacency is formed by sending <a href="/facts/Unicast/PHStTfFe">unicast</a> packets to another router. A non-broadcast network can have more than two routers, but broadcast is not supported. </p> 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 <p>Examples of non-broadcast networks: </p> <ul><li><a href="/facts/X.25/yaGPqw2Y">X.25</a> <a href="/facts/Public_data_network/sMYs1t3f">public data network</a></li> <li><a href="/facts/Wireguard/zSJv87LA">Wireguard</a></li> <li><a href="/facts/Serial_interface/VpcrH530">Serial interface</a></li></ul> <ul><li>Requires all routers to be able to communicate directly, on the same network.</li> <li>Designated Router is elected for the network.</li> <li>LSA is generated for the network.</li></ul> <h2 id="ospf-areas">OSPF areas</h2> <p>A network is divided into OSPF <i>areas</i> that are logical groupings of hosts and networks. An area includes its connecting router having an interface for each connected network link. Each router maintains a separate link-state database for the area whose information may be summarized towards the rest of the network by the connecting router. Thus, the topology of an area is unknown outside the area. This reduces the routing traffic between parts of an autonomous system. </p><p>OSPF can handle thousands of routers with more a concern of reaching capacity of the <a href="/facts/Forwarding_information_base/b3bo9LSD">forwarding information base</a> (FIB) table when the network contains lots of routes and lower-end devices.<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> Modern low-end routers have a full gigabyte of RAM,<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a> which allows them to handle many routers in an area 0. Many resources<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a> refer to OSPF guides from over 20 years ago where it was impressive to have 64 MB of RAM. </p><p>Areas are uniquely identified with 32-bit numbers. The area identifiers are commonly written in the dot-decimal notation, familiar from IPv4 addressing. However, they are not IP addresses and may duplicate, without conflict, any IPv4 address. The area identifiers for IPv6 implementations (OSPFv3) also use 32-bit identifiers written in the same notation. When dotted formatting is omitted, most implementations expand area <i>1</i> to the area identifier <i>0.0.0.1</i>, but some have been known to expand it as <i>1.0.0.0</i>. </p><p>Several vendors (Cisco, Allied Telesis, Juniper, Alcatel-Lucent, Huawei, Quagga), implement <i>totally stubby</i> and <i>NSSA totally stubby area</i> for stub and not-so-stubby areas. Although not covered by RFC standards, they are considered by many to be standard features in OSPF implementations. </p><p>OSPF defines several area types: </p> <ul><li>Backbone</li> <li>Non-backbone/regular</li> <li>Stub</li> <li>Totally stubby</li> <li>Not-so-stubby</li> <li>Totally not-so-stubby</li> <li>Transit</li></ul> <h3>Backbone area</h3> <p>The backbone area (also known as <i>area 0</i> or <i>area 0.0.0.0</i>) forms the core of an OSPF network. All other areas are connected to it, either directly or through other routers. OSPF requires this to prevent <a href="/facts/Routing_loop/ACljX675">routing loops</a>.<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a> Inter-area routing happens via routers connected to the backbone area and to their own associated areas. It is the logical and physical structure for the 'OSPF domain' and is attached to all nonzero areas in the OSPF domain. In OSPF the term <i>autonomous system boundary router</i> (ASBR) is historic, in the sense that many OSPF domains can coexist in the same Internet-visible autonomous system, RFC 1996.<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a><a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a> </p><p>All OSPF areas must connect to the backbone area. This connection, however, can be through a virtual link. For example, assume area 0.0.0.1 has a physical connection to area 0.0.0.0. Further assume that area 0.0.0.2 has no direct connection to the backbone, but this area does have a connection to area 0.0.0.1. Area 0.0.0.2 can use a virtual link through the <i>transit area</i> 0.0.0.1 to reach the backbone. To be a transit area, an area has to have the transit attribute, so it cannot be stubby in any way. </p> <h3>Regular area</h3> <p>A regular area is just a non-backbone (nonzero) area without specific feature, generating and receiving summary and external LSAs. The backbone area is a special type of such area. </p> <h3>Stub area</h3> In hello packets the E-flag is not <a href="/facts/Data_type/fcx5hgVL">high</a>, indicating "External routing: not capable" <p>A stub area is an area that does not receive route advertisements external to the AS and routing from within the area is based entirely on a default route. An ABR deletes type 4 and 5 LSAs from internal routers, sends them a default route of 0.0.0.0 and turns itself into a default gateway. This reduces LSDB and routing table size for internal routers. </p><p>Modifications to the basic concept of stub area have been implemented by systems vendors, such as the <i>totally stubby area</i> (TSA) and the <i>not-so-stubby area</i> (NSSA), both an extension in <a href="/facts/Cisco_Systems/ocDgQt6T">Cisco Systems</a> routing equipment. </p> <h4>Totally stubby area</h4> <p>A <i>totally stubby area</i> is similar to a stub area. However, this area does not allow <i>summary</i> routes in addition to not having <i>external</i> routes, that is, <i>inter-area</i> (IA) routes are not summarized into totally stubby areas. The only way for traffic to get routed outside the area is a default route which is the only Type-3 LSA advertised into the area. When there is only one route out of the area, fewer routing decisions have to be made by the route processor, which lowers system resource utilization. </p> Occasionally, it is said that a TSA can have only one ABR.<a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a> <h3>Not-so-stubby area</h3> In hello packets the N-flag is set <a href="/facts/Data_type/fcx5hgVL">high</a>, indicating "NSSA: supported" <p>A <i>not-so-stubby area</i> (NSSA) is a type of stub area that can import autonomous system external routes and send them to other areas, but still cannot receive AS-external routes from other areas.<a class="footnote-ref" id="fnref:24" href="#fn:24"><sup>24</sup></a> </p><p>NSSA is an extension of the stub area feature that allows the injection of external routes in a limited fashion into the stub area. A case study simulates an NSSA getting around the stub-area problem of not being able to import external addresses. It visualizes the following activities: the ASBR imports external addresses with a type 7 LSA, the ABR converts a type 7 LSA to type 5 and floods it to other areas, the ABR acts as an ASBR for other areas. The ASBRs do not take type 5 LSAs and then convert to type 7 LSAs for the area. </p> <h4>Totally not-so-stubby area</h4> <p>An addition to the standard functionality of an NSSA, the <i>totally stubby NSSA</i> is an NSSA that takes on the attributes of a TSA, meaning that type 3 and 4 summary routes are not flooded into this type of area. It is also possible to declare an area both totally stubby and not-so-stubby, which means that the area will receive only the default route from area 0.0.0.0, but can also contain an autonomous system boundary router (ASBR) that accepts external routing information and injects it into the local area, and from the local area into area 0.0.0.0. </p> Redistribution into an NSSA area creates a special type of LSA known as type 7, which can exist only in an NSSA area. An NSSA ASBR generates this LSA, and an NSSA ABR router translates it into a type 5 LSA, which gets propagated into the OSPF domain. <p>A newly acquired subsidiary is one example of where it might be suitable for an area to be simultaneously not-so-stubby and totally stubby if the practical place to put an ASBR is on the edge of a totally stubby area. In such a case, the ASBR does send externals into the totally stubby area, and they are available to OSPF speakers within that area. In Cisco's implementation, the external routes can be summarized before injecting them into the totally stubby area. In general, the ASBR should not advertise default into the TSA-NSSA, although this can work with extremely careful design and operation, for the limited special cases in which such an advertisement makes sense. </p><p>By declaring the totally stubby area as NSSA, no external routes from the backbone, except the default route, enter the area being discussed. The externals do reach area 0.0.0.0 via the TSA-NSSA, but no routes other than the default route enter the TSA-NSSA. Routers in the TSA-NSSA send all traffic to the ABR, except to routes advertised by the ASBR. </p> <h2 id="router-types">Router types</h2> <p>OSPF defines the following overlapping categories of routers: </p> Internal router (IR) An <i>internal router</i> has all its interfaces belonging to the same area. Area border router (ABR) An <i>area border router</i> is a router that connects one or more areas to the main backbone network. It is considered a member of all areas it is connected to. An ABR keeps multiple <a href="/facts/Instance_(computer_science)/5zPBGdX1">instances</a> of the link-state database in memory, one for each area to which that router is connected. Backbone router (BR) A <i>backbone router</i> has an interface to the backbone area. Backbone routers may also be area border routers, but do not have to be. Autonomous system boundary router (ASBR) An <i>autonomous system boundary router</i> is a router that is connected by using more than one routing protocol and that exchanges routing information with routers autonomous systems. ASBRs typically also run an exterior routing protocol (e.g., <a href="/facts/BGP/XfYgBzW3">BGP</a>), or use static routes, or both. An ASBR is used to <a href="/facts/Route_redistribution/nKc4mUSA">distribute routes</a> received from other, external ASs throughout its own autonomous system. An ASBR creates External LSAs for external addresses and floods them to all areas via ABR. Routers in other areas use ABRs as next hops to access external addresses. Then ABRs forward packets to the ASBR that announces the external addresses. <p>The router type is an attribute of an OSPF process. A given physical router may have one or more OSPF processes. For example, a router that is connected to more than one area, and which receives routes from a BGP process connected to another AS, is both an area border router and an autonomous system boundary router. </p><p>Each router has an identifier, customarily written in the dotted-decimal format (e.g., 1.2.3.4) of an IP address. This identifier must be established in every OSPF instance. If not explicitly configured, the highest logical IP address will be duplicated as the router identifier. However, since the router identifier is not an IP address, it does not have to be a part of any routable subnet in the network, and often isn't to avoid confusion. </p> <h2 id="non-point-to-point-network">Non-point-to-point network</h2> <p>On networks (same subnet) with networks type of: </p> <ul><li>Broadcast</li> <li>Non-Broadcast Multi-Access (NBMA)</li></ul> <p>A system of <i>designated router</i> (DR) and <i>backup designated router</i> (BDR), is used to reducing network traffic by providing a source for routing updates. This is done using multicast addresses: </p> <ul><li><a href="/facts/Multicast_address/cIau2Hee"><i>224.0.0.5</i></a>, all routers in the topology will listen on that multicast address.</li> <li><a href="/facts/Multicast_address/cIau2Hee"><i>224.0.0.6</i></a>, DR and BDR will listen on that multicast address.</li></ul> <p>The DR and BDR maintains a complete topology table of the network and sends the updates to the other routers via multicast. All routers in a multi-access network segment will form a leader/follower relationship with the DR and BDR. They will form adjacencies with the DR and BDR only. Every time a router sends an update, it sends it to the DR and BDR on the multicast address <i>224.0.0.6</i>. The DR will then send the update out to all other routers in the area, to the multicast address <i>224.0.0.5</i>. This way all the routers do not have to constantly update each other, and can rather get all their updates from a single source. The use of multicasting further reduces the network load. DRs and BDRs are always setup/elected on OSPF broadcast networks. DR's can also be elected on NBMA (Non-Broadcast Multi-Access) networks such as Frame Relay or ATM. DRs or BDRs are not elected on point-to-point links (such as a point-to-point WAN connection) because the two routers on either side of the link must become fully adjacent and the bandwidth between them cannot be further optimized. DR and non-DR routers evolve from 2-way to full adjacency relationships by exchanging DD, Request, and Update. </p> <h3>Designated router</h3> <p>A <i>designated router</i> (DR) is the router interface elected among all routers on a particular multiaccess network segment, generally assumed to be broadcast multiaccess. Special techniques, often vendor-dependent, may be needed to support the DR function on <a href="/facts/Non-broadcast_multiaccess/D7thEVhM">non-broadcast multiaccess</a> (NBMA) media. It is usually wise to configure the individual virtual circuits of an NBMA subnet as individual point-to-point lines; the techniques used are implementation-dependent. </p> <h3>Backup designated router</h3> <p>A <i>backup designated router</i> (BDR) is a router that becomes the designated router if the current designated router has a problem or fails. The BDR is the OSPF router with the second-highest priority at the time of the last election. </p><p>A given router can have some interfaces that are designated (DR) and others that are backup designated (BDR), and others that are non-designated. If no router is a DR or a BDR on a given subnet, the BDR is first elected, and then a second election is held for the DR.<a class="footnote-ref" id="fnref:25" href="#fn:25"><sup>25</sup></a>: 75 </p> <h3>DR Other</h3> <p>A router that has not been selected to be <i>designated router</i> (DR) or <i>backup designated router</i> (BDR). The router forms an adjacency to both the <i>designated router</i> (DR) and the <i>backup designated router</i> (BDR). </p><p>For other non (B)DR, the adjacency stops at <i>2-ways</i> State. </p> <h3>Designated router election</h3> <p>The DR is elected based on the following default criteria: </p> <ul><li>If the priority setting on an OSPF router is set to 0, that means it can NEVER become a DR or BDR.</li> <li>If no DR exists on the network, routes will wait until <i>Wait Timer</i> runs out.</li> <li>When a DR fails and the BDR takes over, there is another election to see who becomes the replacement BDR.</li> <li>The router sending the Hello packets with the highest priority wins the election.</li> <li>If two or more routers tie with the highest priority setting, the router sending the Hello with the highest RID (Router ID) wins. NOTE: a RID is the highest logical (loopback) IP address configured on a router, if no logical/loopback IP address is set then the router uses the highest IP address configured on its active interfaces (e.g. <i>192.168.0.1</i> would be higher than <i>10.1.1.2</i>).</li> <li>Usually the router with the second-highest priority number becomes the BDR.</li> <li>The priority values range between 0 – 255,<a class="footnote-ref" id="fnref:26" href="#fn:26"><sup>26</sup></a> with a higher value increasing its chances of becoming DR or BDR.</li> <li>If a higher priority OSPF router comes online after the election has taken place, it will not become DR or BDR until (at least) the DR and BDR fail.</li> <li>If the current DR 'goes down' the current BDR becomes the new DR and a new election takes place to find another BDR. If the new DR then 'goes down' and the original DR is now available, still previously chosen BDR will become DR.</li></ul> <h3>Routing update flow</h3> <h4>When DR has Routing update</h4> <ol><li>DR sends LSU to <i>224.0.0.5</i></li> <li>BDR sends LSUAck to <i>224.0.0.5</i></li> <li>DR Other sends LSUAck to <i>224.0.0.6</i></li></ol> <h4>When BDR has Routing update</h4> <ol><li>BDR sends LSU to <i>224.0.0.5</i></li> <li>DR sends LSUAck to <i>224.0.0.5</i></li> <li>DR Other sends LSUAck to <i>224.0.0.6</i></li></ol> <h4>When DR Other has Routing update</h4> <ol><li>DR Other sends LSU to <i>224.0.0.6</i></li> <li>DR sends LSA to <i>224.0.0.5</i></li> <li>BDR sends LSUAck to <i>224.0.0.5</i></li> <li>Non-source routers, DR Other sends LSUAck to <i>224.0.0.6</i></li></ol> <h2 id="protocol-messages">Protocol messages</h2> OSPF v2 header format, field lengths in bytes<table><tbody><tr><th>1</th><th>1</th><th>2</th><th>4</th><th>4</th><th>2</th><th>2</th><th>8</th></tr><tr><td>Version 2</td><td>Type</td><td>Packet length</td><td>Router ID</td><td>Area ID</td><td>Checksum</td><td>AuType</td><td>Authentication</td></tr></tbody></table> OSPF v3 header format, field lengths in bytes<table><tbody><tr><th>1</th><th>1</th><th>2</th><th>4</th><th>4</th><th>2</th><th>1</th><th>1</th></tr><tr><td>Version 3</td><td>Type</td><td>Packet length</td><td>Router ID</td><td>Area ID</td><td>Checksum</td><td>Instance ID</td><td>Reserved</td></tr></tbody></table> <p>Unlike other routing protocols, OSPF does not carry data via a transport protocol, such as the <a href="/facts/User_Datagram_Protocol/dxLU0D6q">User Datagram Protocol</a> (UDP) or the <a href="/facts/Transmission_Control_Protocol/WW4sPrt9">Transmission Control Protocol</a> (TCP). Instead, OSPF forms IP datagrams directly, packaging them using protocol number 89 for the <a href="/facts/List_of_IP_protocol_numbers/lf9S6JCk">IP Protocol field</a>. OSPF defines five different message types, for various types of communication. Multiple packets can be sent per frame. </p><p>OSPF uses 5 packet types: </p> <ul><li>Hello</li> <li>Database description</li> <li>Link state request</li> <li>Link state update</li> <li>Link state acknowledgement</li></ul> <h3>Hello Packet</h3> OSPF v2 hello packet, field lengths in bytes<table><tbody><tr><th>24</th><th>4</th><th>2</th><th>1</th><th>1</th><th>4</th><th>4</th><th>4</th><th>4</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>Network Mask</td><td>Hello Interval</td><td>Options</td><td>Router Priority</td><td>Router Dead Interval</td><td>Designated Router ID</td><td>Backup Designated Router ID</td><td>Neighbor ID</td></tr></tbody></table> OSPF v3 hello packet, field lengths in bytes<table><tbody><tr><th>16</th><th>4</th><th>1</th><th>3</th><th>2</th><th>2</th><th>4</th><th>4</th><th>4</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>Interface ID</td><td>Router Priority</td><td>Options</td><td>Hello Interval</td><td>Router Dead Interval</td><td>Designated Router ID</td><td>Backup Designated Router ID</td><td>Neighbor ID</td></tr></tbody></table> <p>OSPF's Hello messages are used as a form of greeting, to allow a router to discover other adjacent routers on its local links and networks. The messages establish relationships between neighboring devices (called adjacencies) and communicate key parameters about how OSPF is to be used in the autonomous system or area. During normal operation, routers send hello messages to their neighbors at regular intervals (the <i>hello interval</i>); if a router stops receiving hello messages from a neighbor, after a set period (the <i>dead interval</i>) the router will assume the neighbor has gone down. </p> <h3> Database description (DBD)</h3> OSPF v2 and v3 database description, field lengths in bytes<table><tbody><tr><th>16 or 24</th><th>2</th><th>1</th><th>1</th><th>1</th><th>4</th><th>Variable</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>Interface MTU</td><td>Hello Interval</td><td>Options</td><td>Flags</td><td>DD sequence number</td><td>LSA Headers</td></tr></tbody></table> <p><i>Database description</i> messages contain descriptions of the topology of the autonomous system or area. They convey the contents of the link-state database (LSDB) for the area from one router to another. Communicating a large LSDB may require several messages to be sent by having the sending device designated as a leader device and sending messages in sequence, with the follower (recipient of the LSDB information) responding with acknowledgments. </p> <h3>Link state packets</h3> <p class="note">Main article: <a href="/facts/Link-state_advertisement/VkAdfMGC">Link-state advertisement</a></p> OSPF v2 link state request, field lengths in bytes<table><tbody><tr><th>24</th><th>4</th><th>4</th><th>4</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>LS Type</td><td>Link State ID</td><td>Advertising Router</td></tr></tbody></table> OSPF v3 link state request, field lengths in bytes<table><tbody><tr><th>16</th><th>2</th><th>2</th><th>4</th><th>4</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>Reserved</td><td>LS Type</td><td>Link State ID</td><td>Advertising Router</td></tr></tbody></table> Link state request (<i>LSR</i>) <i>Link state request</i> messages are used by one router to request updated information about a portion of the LSDB from another router. The message specifies the link(s) for which the requesting device wants more current information. OSPF v2 and v3 link state update packet, field lengths in bytes<table><tbody><tr><th>24 or 16</th><th>4</th><th>Variable</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td># LSAs</td><td>List of LSAs</td></tr></tbody></table> Link state update (<i>LSU</i>) <i>Link-state update</i> messages contain updated information about the state of certain links on the LSDB. They are sent in response to a link state request message, and also broadcast or multicast by routers on a regular basis. Their contents are used to update the information in the LSDBs of routers that receive them. OSPF v2 and v3 link state acknowledgment, field lengths in bytes<table><tbody><tr><th>24 or 16</th><th>Variable</th></tr><tr><td rowspan="2" colspan="1">Header</td></tr><tr><td>List of LSAs</td></tr></tbody></table> Link state acknowledgment (<i>LSAck</i>) <i>Link-state acknowledgment</i> messages provide reliability to the link-state exchange process, by explicitly acknowledging receipt of a Link State Update message. OSPF link state advertisements<table><tbody><tr><th>LS type</th><th>LS name</th><th>Generated by</th><th>Description</th></tr><tr><td>1</td><td>Router-LSAs</td><td>Each internal router within an area</td><td><p>The link-state ID of the type 1 LSA is the originating router ID.Router-LSAs, describe the following types of interfaces:</p><ul><li>Point-to-point connection to another router</li><li>Connection to a transit network</li><li>Connection to a stub network (Reserved in v3)</li><li>Virtual link</li></ul></td></tr><tr><td>2</td><td>Network-LSAs</td><td>The DR</td><td>Originated for broadcasts and NBMA networks by the designated router. This LSA contains the list of routers connected to the network. The link-state ID of the type 2 LSA is the IP interface address of the DR.</td></tr><tr><td>3</td><td>Summary-LSAs</td><td>The ABR</td><td>Type 3 summary-LSAs describe routes to networks.<p>To inform other areas about inter-area routers. These routes can also be summarised.</p></td></tr><tr><td>4</td><td>ASBR-summary</td><td>The ABR</td><td>Type 4 describe routes to AS boundary routers beyond its area.<p>The area border router (ABR) generates this LSA to inform other routers in the OSPF domain, that the matching router is an autonomous system boundary router (ASBR), so that the external LSAs (Type 5 / Type 7) it sent may be properly resolved outside its own area.</p></td></tr><tr><td>5</td><td>AS-external-LSAs</td><td>The ASBR</td><td>Type 5 These describe routes advertised by the ASBR.<p>LSAs contain information imported into OSPF from other routing processes. Together with Type 4 they describe the way to an external route.</p></td></tr><tr><td>7</td><td>NSSA external link-state advertisements</td><td>The ASBR, within a not-so-stubby area</td><td>Type 7-LSAs are identical to type-5 LSAs. Type-7 LSAs are only flooded within the NSSA. At the area border router, selected type-7 LSAs are translated into type 5-LSAs and flooded into the backbone.</td></tr><tr><td>8</td><td>Link-LSA (v3)</td><td>Each internal router within a link</td><td>Provide it local router's link-local address to all other routers on the local network.</td></tr><tr><td>9</td><td>Intra-Area-Prefix-LSAs (v3)</td><td>Each internal router within an area</td><td>Replaces some of the functionality of Router-LSAs; stub network segment, or an attached transit network segment.</td></tr></tbody></table> <h4>OSPF v2 area types and accepted LSAs</h4> <p>Not all area types use all LSA. Below is a matrix of accepted LSAs. </p> Overview of OSPF area types and accepted LSAs:<a class="footnote-ref" id="fnref:27" href="#fn:27"><sup>27</sup></a><a class="footnote-ref" id="fnref:28" href="#fn:28"><sup>28</sup></a><table><tbody><tr><th></th><th colspan="3">Within a single area</th><th colspan="3">Inter area</th></tr><tr><td>Area type</td><td>LSA 1 - router</td><td>LSA 2 - network</td><td>LSA 7 - NSSA external</td><td>LSA 3 - network summary</td><td>LSA 4 - ASBR Summary</td><td>LSA 5 - AS external</td></tr><tr><td>Backbone</td><td>Yes</td><td>Yes</td><td>No, converted into a Type 5 by the ABR</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Non-backbone</td><td>Yes</td><td>Yes</td><td>No, converted into a Type 5 by the ABR</td><td>Yes</td><td>Yes</td><td>Yes</td></tr><tr><td>Stub</td><td>Yes</td><td>Yes</td><td>No, Default route</td><td>Yes</td><td>No, Default route</td><td>No, Default route</td></tr><tr><td>Totally stubby</td><td>Yes</td><td>Yes</td><td>No, Default route</td><td>No, Default route</td><td>No, Default route</td><td>No, Default route</td></tr><tr><td>Not-so-stubby</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No, Default route</td><td>No, Default route</td></tr><tr><td>Totally not-so-stubby</td><td>Yes</td><td>Yes</td><td>Yes</td><td>No, Default route</td><td>No, Default route</td><td>No, Default route</td></tr></tbody></table> <h2 id="routing-metrics">Routing metrics</h2> <p>OSPF uses <i>path cost</i> as its basic routing metric, which was defined by the standard not to equate to any standard value such as speed, so the network designer could pick a metric important to the design. In practice, it is determined by comparing the speed of the interface to a reference-bandwidth for the OSPF process. The cost is determined by dividing the reference bandwidth by the interface speed (although the cost for any interface can be manually overridden).<a class="footnote-ref" id="fnref:29" href="#fn:29"><sup>29</sup></a><a class="footnote-ref" id="fnref:30" href="#fn:30"><sup>30</sup></a> Here is an example table that shows the routing metric or 'cost calculation' on an interface. </p> <ul><li>Type-1 LSA has a size of 16-bit field (65,535 in decimal)<a class="footnote-ref" id="fnref:31" href="#fn:31"><sup>31</sup></a></li> <li>Type-3 LSA has a size of 24-bit field (16,777,216 in decimal)</li></ul> Calculation for reference speed<table><tbody><tr><th scope="col" rowspan="2">Interface speed</th><th scope="col" colspan="2">Link cost</th><th scope="col" rowspan="2">Uses</th></tr><tr><th scope="col">Default (100 Mbit/s)</th><th scope="col">200 Gbit/s</th></tr><tr><td>800 Gbit/s</td><td>1</td><td>1</td><td><a href="/facts/Small_form-factor_pluggable_transceiver/bp1RTekJ">QSFP-DD112</a></td></tr><tr><td>200 Gbit/s</td><td>1</td><td>1</td><td><a href="/facts/SFP-DD/bp1RTekJ">SFP-DD</a></td></tr><tr><td>40 Gbit/s</td><td>1</td><td>5</td><td><a href="/facts/Small_form-factor_pluggable_transceiver/bp1RTekJ">QSFP+</a></td></tr><tr><td>25 Gbit/s</td><td>1</td><td>8</td><td><a href="/facts/Small_form-factor_pluggable_transceiver/bp1RTekJ">SFP28</a></td></tr><tr><td>10 Gbit/s</td><td>1</td><td>20</td><td><a href="/facts/10_GigE/FvxUohpf">10 GigE</a>, common in data centers</td></tr><tr><td>5 Gbit/s</td><td>1</td><td>40</td><td><a href="/facts/2.5GBASE-T_and_5GBASE-T/REWNhYIf">NBase-T</a>, Wi-Fi routers</td></tr><tr><td>1 Gbit/s</td><td>1</td><td>200</td><td>common gigabit port</td></tr><tr><td>100 Mbit/s</td><td>1</td><td>2000</td><td>low-end port</td></tr><tr><td>10 Mbit/s</td><td>10</td><td>20000</td><td>1990's speed.</td></tr></tbody></table> <p>OSPF is a layer 3 protocol. If a layer 2 switch is between the two devices running OSPF, one side may negotiate a speed different from the other side. This can create an asymmetric routing on the link (Router 1 to Router 2 could cost '1' and the return path could cost '10'), which may lead to unintended consequences. </p><p>Metrics, however, are only directly comparable when of the same type. Four types of metrics are recognized. In decreasing preference (for example, an intra-area route is always preferred to an external route regardless of metric), these types are: </p> <ol><li>Intra-area</li> <li>Inter-area</li> <li>External Type 1, which includes both the external path cost and the sum of internal path costs to the ASBR that advertises the route,<a class="footnote-ref" id="fnref:32" href="#fn:32"><sup>32</sup></a></li> <li>External Type 2, the value of which is solely that of the external path cost,</li></ol> <h2 id="ospf-v3">OSPF v3</h2> <p>OSPF version 3 introduces modifications to the IPv4 implementation of the protocol.<a class="footnote-ref" id="fnref:33" href="#fn:33"><sup>33</sup></a> Despite the expansion of addresses to 128 bits in IPv6, area and router identifications are still 32-bit numbers. </p> <h3>High-level changes</h3> <ul><li>Except for virtual links, all neighbor exchanges use IPv6 link-local addressing exclusively. The IPv6 protocol runs per link, rather than based on the <a href="/facts/Subnet/s1rQsNDv">subnet</a>.</li> <li>All IP prefix information has been removed from the link-state advertisements and from the <i>hello</i> discovery packet, making OSPFv3 essentially protocol-independent.</li> <li>Three separate flooding scopes for LSAs: <ul><li>Link-local scope: LSA is flooded only on the local link and no further.</li> <li>Area scope: LSA is flooded throughout a single OSPF area.</li> <li>AS scope: LSA is flooded throughout the routing domain.</li></ul></li> <li>Use of IPv6 link-local addresses, for neighbor discovery, auto-configuration.</li> <li>Authentication has been moved to the <a href="/facts/IPsec/01MwcET1">IP Authentication Header</a></li></ul> <h3>Changes introduced in OSPF v3, then backported by vendors to v2</h3> <ul><li>Explicit support for multiple instances per link<a class="footnote-ref" id="fnref:34" href="#fn:34"><sup>34</sup></a></li></ul> <h3>Packet format changes</h3> <ul><li>OSPF version number changed to 3</li> <li>From the LSA header, the options field has been removed.</li> <li>In hello packets and database description, the options field is changed from 16 to 24 bits.</li> <li>In hello packet, the address information has been removed. The interface ID has been added.</li> <li>In router-LSAs, two options bits, the <i>R-bit</i> and the <i>V6-bit</i>, have been added. <ul><li><i>R-bit</i>: allows for multi-homed hosts to participate in the routing protocol.</li> <li><i>V6-bit</i>: specializes the R-bit.</li></ul></li> <li>Add <i>instance ID</i>, which allows multiple OSPF protocol instances on the same logical interface.</li></ul> <h3>LSA format changes</h3> <ul><li>The LSA type field is changed to 16 bits. <ul><li>Add support for handling unknown LSA types</li> <li>Three bits are used for encoding flooding scope.</li></ul></li> <li>With IPv6, addresses in LSAs are expressed as <a href="/facts/IPv6/d4dg7kIL">prefix</a> and prefix length.</li> <li>In router-LSAs and network-LSAs, the address information is removed.</li> <li>Router-LSAs and network-LSAs are made network-protocol independent.</li> <li>A new LSA type is added, link-LSA, which provides the router's link-local address to all other routers attached to the logical interface, provides a list of IPv6 prefixes to associate with the link, and can send information that reflect the router's capabilities.</li> <li>LSA Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs".</li> <li>LSA Type-4 summary LSAs have been renamed "inter-area-router-LSAs".</li> <li>Intra-area-prefix-LSA is added, an LSA that carries all IPv6 prefix information.</li></ul> <h2 id="ospf-over-mpls-vpn">OSPF over MPLS VPN</h2> <a href="/facts/Border_Gateway_Protocol/XfYgBzW3">BGP extended communities</a> transitive for OSPF<a class="footnote-ref" id="fnref:35" href="#fn:35"><sup>35</sup></a><table><tbody><tr><th>Type</th><th>Type field</th><th>sub value</th><th>name</th></tr><tr><td>Two-octet <a href="/facts/Autonomous_system_(Internet)/zIVqxPX1">AS</a></td><td>0x00</td><td>0x05</td><td>OSPF domain identifier</td></tr><tr><td>Four-octet <a href="/facts/Autonomous_system_(Internet)/zIVqxPX1">AS</a></td><td>0x02</td><td>0x05</td><td>OSPF domain identifier</td></tr><tr><td>IPv4 address</td><td>0x01</td><td>0x05</td><td>OSPF domain identifier</td></tr><tr><td>IPv4 address</td><td>0x01</td><td>0x07</td><td>OSPF route ID</td></tr><tr><td>Opaque</td><td>0x03</td><td>0x06</td><td>OSPF route type</td></tr></tbody></table> BGP extended communitiesAttribute for OSPF route type <table><tbody><tr><th>4 byte</th><th>1 byte</th><th>1 byte</th></tr><tr><td>Area number</td><td>Route type</td><td>Options</td></tr></tbody></table> <p>A customer can use OSPF over a <a href="/facts/MPLS/k7cx1PWw">MPLS</a> VPN, where the <a href="/facts/Network_service_provider/EUH6z0rc">service provider</a> uses BGP or RIP as their <a href="/facts/Interior_gateway_protocol/RDWHfeLE">interior gateway protocol</a>.<a class="footnote-ref" id="fnref:36" href="#fn:36"><sup>36</sup></a> When using OSPF over MPLS VPN, the VPN backbone becomes part of the OSPF backbone area 0. In all areas, isolated copies of the IGP are run. </p><p>Advantages: </p> <ul><li>The MPLS VPN is transparent to the customer's OSPF standard routing.</li> <li>Customer's equipment only needs to support OSPF.</li> <li>Reduce the need for tunnels (<a href="/facts/Generic_Routing_Encapsulation/0TQRDUMK">Generic Routing Encapsulation</a>, <a href="/facts/IPsec/01MwcET1">IPsec</a>, <a href="/facts/Wireguard/zSJv87LA">wireguard</a>) to use OSPF.</li></ul> <p>To achieve this, a modified OSPF-BGP redistribution is used. All OSPF routes retain the source LSA type and metric.<a class="footnote-ref" id="fnref:37" href="#fn:37"><sup>37</sup></a><a class="footnote-ref" id="fnref:38" href="#fn:38"><sup>38</sup></a> To prevent loops, an optional DN bit<a class="footnote-ref" id="fnref:39" href="#fn:39"><sup>39</sup></a> is set by the service provider in LSAs from the provider equipment to indicate that a route has already been sent to the customer's equipment. </p> <h2 id="ospf-extensions">OSPF extensions</h2> <h3>Traffic engineering</h3> <p>OSPF-TE is an extension to OSPF extending the expressivity to allow for traffic engineering and use on non-IP networks.<a class="footnote-ref" id="fnref:40" href="#fn:40"><sup>40</sup></a> Using OSPF-TE, more information about the topology can be exchanged using opaque LSA carrying <a href="/facts/Type%25E2%2580%2593length%25E2%2580%2593value/IMeVVbpK">type–length–value</a> elements. These extensions allow OSPF-TE to run completely out of band of the data plane network. This means that it can also be used on non-IP networks, such as optical networks. </p><p>OSPF-TE is used in <a href="/facts/GMPLS/raohjGyK">GMPLS</a> networks as a means to describe the topology over which GMPLS paths can be established. GMPLS uses its own path setup and forwarding protocols, once it has the full network map. </p><p>In the <a href="/facts/Resource_Reservation_Protocol/LpJwLb55">Resource Reservation Protocol</a> (RSVP), OSPF-TE is used for recording and flooding RSVP signaled bandwidth reservations for <a href="/facts/Label-switched_path/k7cx1PWw">label-switched paths</a> within the link-state database. </p> <h3>Optical routing</h3> <p><a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc3717">3717</a> documents work in optical routing for IP based on extensions to OSPF and IS-IS.<a class="footnote-ref" id="fnref:41" href="#fn:41"><sup>41</sup></a> </p> <h3>Multicast Open Shortest Path First</h3> <p>The Multicast Open Shortest Path First (MOSPF) protocol is an extension to OSPF to support multicast routing. MOSPF allows routers to share information about group memberships. </p> <h2 id="notable-implementations">Notable implementations</h2> <ul><li><a href="/facts/Allied_Telesis/SglP2MdH">Allied Telesis</a> implements OSPFv2 & OSPFv3 in Allied Ware Plus (AW+)</li> <li><a href="/facts/Arista_Networks/125qgMKV">Arista Networks</a> implements OSPFv2 and OSPFv3</li> <li><a href="/facts/Bird_Internet_routing_daemon/zuFMMlMf">BIRD</a> implements both OSPFv2 and OSPFv3</li> <li><a href="/facts/Cisco_IOS/jwcRuzX8">Cisco IOS</a> and <a href="/facts/NX-OS/PU2fVKXt">NX-OS</a></li> <li><a href="/facts/Cisco_Meraki/zW6fFl22">Cisco Meraki</a></li> <li><a href="/facts/D-Link/tmrcqckb">D-Link</a> implements OSPFv2 on Unified Services Router.</li> <li><a href="/facts/Force10_Networks/ufPhbpTl">Dell's FTOS</a> implements OSPFv2 and OSPFv3</li> <li><a href="/facts/ExtremeXOS/owQ5FICr">ExtremeXOS</a></li> <li><a href="/facts/FRRouting/TS9Xxt0B">FRRouting</a>, the successor of Quagga</li> <li><a href="/facts/GNU_Zebra/Wa8xmgfh">GNU Zebra</a>, a <a href="/facts/GPL/S75KhLSX">GPL</a> routing suite for <a href="/facts/Unix-like/YAKrAxzd">Unix-like</a> systems</li> <li><a href="/facts/Juniper_Junos/osUAt6qS">Juniper Junos</a></li> <li><a href="/facts/NetWare/cfnyxMzs">NetWare</a> implements OSPF in its Multi Protocol Routing module.</li> <li><a href="/facts/OpenBSD/xmPS9tek">OpenBSD</a> includes <a href="/facts/OpenOSPFD/nmebHCFc">OpenOSPFD</a>, an OSPFv2 implementation.</li> <li><a href="/facts/Quagga_(software)/qJy65FnE">Quagga</a>, a fork of <a href="/facts/GNU_Zebra/Wa8xmgfh">GNU Zebra</a> for <a href="/facts/Unix-like/YAKrAxzd">Unix-like</a> systems</li> <li><a href="/facts/Windows_NT_4.0/EcKYxrkx">Windows NT 4.0</a> Server, <a href="/facts/Windows_2000/amJIt9gz">Windows 2000</a> Server and <a href="/facts/Windows_Server_2003/3vIJam5L">Windows Server 2003</a> implemented OSPFv2 in the <a href="/facts/Routing_and_Remote_Access_Service/RXtkr5of">Routing and Remote Access Service</a>, although the functionality was removed in <a href="/facts/Windows_Server_2008/hrcPjTCH">Windows Server 2008</a>.</li> <li><a href="/facts/XORP/7TnbDlzv">XORP</a>, a routing suite implementing RFC2328 (OSPFv2) and RFC2740 (OSPFv3) for both IPv4 and IPv6</li></ul> <h2 id="applications">Applications</h2> <p>OSPF is a widely deployed routing protocol that can converge a network in a few seconds and guarantee loop-free paths. It has many features that allow the imposition of policies about the propagation of routes that it may be appropriate to keep local, for load sharing, and for selective route importing. IS-IS, in contrast, can be tuned for lower overhead in a stable network, the sort more common in ISP than enterprise networks. There are some historical accidents that made IS-IS the preferred IGP for ISPs, but ISPs today may well choose to use the features of the now-efficient implementations of OSPF,<a class="footnote-ref" id="fnref:42" href="#fn:42"><sup>42</sup></a> after first considering the pros and cons of IS-IS in service provider environments.<a class="footnote-ref" id="fnref:43" href="#fn:43"><sup>43</sup></a> </p><p>OSPF can provide better load-sharing on external links than other IGPs. When the default route to an ISP is injected into OSPF from multiple ASBRs as a Type I external route and the same external cost specified, other routers will go to the ASBR with the least path cost from its location. This can be tuned further by adjusting the external cost. If the default route from different ISPs is injected with different external costs, as a Type II external route, the lower-cost default becomes the primary exit and the higher-cost becomes the backup only. </p> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Fabric_Shortest_Path_First/056yVdBU">Fabric Shortest Path First</a></li> <li><a href="/facts/Mesh_networking/XnVSy5rK">Mesh networking</a></li> <li><a href="/facts/Route_analytics/zJxPUdVd">Route analytics</a></li> <li><a href="/facts/Routing/Ml6MVCaC">Routing</a></li> <li><a href="/facts/Shortest_path_problem/g4nsrswr">Shortest path problem</a></li></ul> <h2 id="further-reading">Further reading</h2> <ul><li>Colton, Andrew (October 2003). <i>OSPF for Cisco Routers</i>. Rocket Science Press. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0972286213.</li> <li>Doyle, Jeff; Carroll, Jennifer (2005). <a href="http://www.ciscopress.com/bookstore/product.asp?isbn=1587052024"><i>Routing TCP/IP</i></a>. Vol. 1 (2nd ed.). <a href="/facts/Cisco_Press/TJYbnzbH">Cisco Press</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-58705-202-6.</li> <li>Moy, John T. (1998). <i>OSPF: Anatomy of an Internet Routing Protocol</i>. <a href="/facts/Addison-Wesley/A7UFATEG">Addison-Wesley</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-0201634723.</li> <li>Parkhurst, William R. (2002). <i>Cisco OSPF Command and Configuration Handbook</i>. Cisco Press. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-58705-071-8.</li> <li>Basu, Anindya; Riecke, Jon (2001). "Stability issues in OSPF routing". <i>Proceedings of the 2001 conference on Applications, technologies, architectures, and protocols for computer communications</i>. <a href="/facts/SIGCOMM/NnTDrEjE">SIGCOMM '01</a>. pp. 225–236. <a href="/facts/CiteSeerX_(identifier)/SceDmd3c">CiteSeerX</a> <a href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.99.6393">10.1.1.99.6393</a>. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1145%2F383059.383077">10.1145/383059.383077</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-58113-411-7. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:7555753">7555753</a>.</li> <li>Valadas, Rui (2019). <i>OSPF and IS-IS: From Link State Routing Principles to Technologies</i>. CRC Press. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1201%2F9780429027543">10.1201/9780429027543</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 9780429027543. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:164731068">164731068</a>.</li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="https://datatracker.ietf.org/wg/ospf/charter/">IETF OSPF Working Group</a></li> <li><a href="https://www.cisco.com/c/en/us/products/ios-nx-os-software/open-shortest-path-first-ospf/index.html">Cisco OSPF</a></li> <li><a href="https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13703-8.html">Cisco OSPF Areas and Virtual Links</a></li> <li><a href="https://www.juniper.net/documentation/us/en/software/junos/ospf/ospf.pdf">Junos OSPF User Guide</a></li> <li><a href="https://www.freesoft.org/CIE/Topics/89.htm">Summary of OSPF v2</a></li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>J. Moy (April 1998). OSPF Version 2. Network Working Group. doi:10.17487/RFC2328. STD 54. RFC 2328. Internet Standard 54. Obsoletes RFC 2178. Updated by RFC 5709, 6549, 6845, 6860, 7474 and 8042. <a href="https://datatracker.ietf.org/doc/html/rfc2328" target="_blank">https://datatracker.ietf.org/doc/html/rfc2328</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>R. Coltun; D. Ferguson; J. Moy (July 2008). A. Lindem (ed.). OSPF for IPv6. Network Working Group. doi:10.17487/RFC5340. RFC 5340. Proposed Standard. Obsoletes RFC 2740. Updated by RFC 6845, 6860, 8362, 7503 and 9454 <a href="https://datatracker.ietf.org/doc/html/rfc5340" target="_blank">https://datatracker.ietf.org/doc/html/rfc5340</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>OSPF Convergence, August 6, 2009, archived from the original on August 5, 2016, retrieved June 13, 2016 <a href="https://web.archive.org/web/20160805141839/https://routing-bits.com/2009/08/06/ospf-convergence/" target="_blank">https://web.archive.org/web/20160805141839/https://routing-bits.com/2009/08/06/ospf-convergence/</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>J. Moy (April 1998). OSPF Version 2. Network Working Group. doi:10.17487/RFC2328. STD 54. RFC 2328. Internet Standard 54. Obsoletes RFC 2178. Updated by RFC 5709, 6549, 6845, 6860, 7474 and 8042. <a href="https://datatracker.ietf.org/doc/html/rfc2328" target="_blank">https://datatracker.ietf.org/doc/html/rfc2328</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>R. Coltun; D. Ferguson; J. Moy (July 2008). A. Lindem (ed.). OSPF for IPv6. Network Working Group. doi:10.17487/RFC5340. RFC 5340. Proposed Standard. Obsoletes RFC 2740. Updated by RFC 6845, 6860, 8362, 7503 and 9454 <a href="https://datatracker.ietf.org/doc/html/rfc5340" target="_blank">https://datatracker.ietf.org/doc/html/rfc5340</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>J. Moy (April 1998). OSPF Version 2. Network Working Group. doi:10.17487/RFC2328. STD 54. RFC 2328. Internet Standard 54. Obsoletes RFC 2178. Updated by RFC 5709, 6549, 6845, 6860, 7474 and 8042. <a href="https://datatracker.ietf.org/doc/html/rfc2328" target="_blank">https://datatracker.ietf.org/doc/html/rfc2328</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>J. Moy (March 1994). Multicast Extensions to OSPF. Network Working Group. doi:10.17487/RFC1584. RFC 1584. Historic. <a href="https://datatracker.ietf.org/doc/html/rfc1584" target="_blank">https://datatracker.ietf.org/doc/html/rfc1584</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>IP Routing: OSPF Configuration Guide, Cisco Systems, archived from the original on August 10, 2016, retrieved June 13, 2016, Cisco routers do not support LSA Type 6 Multicast OSPF (MOSPF), and they generate syslog messages if they receive such packets. <a href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/12-4t/iro-12-4t-book/iro-cfg.html" target="_blank">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/12-4t/iro-12-4t-book/iro-cfg.html</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>R. Coltun; D. Ferguson; J. Moy (July 2008). A. Lindem (ed.). OSPF for IPv6. Network Working Group. doi:10.17487/RFC5340. RFC 5340. Proposed Standard. Obsoletes RFC 2740. Updated by RFC 6845, 6860, 8362, 7503 and 9454 <a href="https://datatracker.ietf.org/doc/html/rfc5340" target="_blank">https://datatracker.ietf.org/doc/html/rfc5340</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>"[Junos] GRE Configuration Example - Juniper Networks". kb.juniper.net. Archived from the original on November 28, 2021. Retrieved November 28, 2021. <a href="https://kb.juniper.net/InfoCenter/index?page=content&id=KB19371" target="_blank">https://kb.juniper.net/InfoCenter/index?page=content&id=KB19371</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>"Generic Routing Encapsulation (GRE) | Interfaces User Guide for Switches | Juniper Networks TechLibrary". www.juniper.net. Archived from the original on November 28, 2021. Retrieved November 28, 2021. <a href="https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-gre.html" target="_blank">https://www.juniper.net/documentation/us/en/software/junos/interfaces-ethernet-switches/topics/topic-map/switches-interface-gre.html</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>E. Rosen; P. Psenak; P. Pillay-Esnault (June 2006). OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). Network Working Group. doi:10.17487/RFC4577. RFC 4577. Proposed Standard. Updates RFC 4364. <a href="https://datatracker.ietf.org/doc/html/rfc4577" target="_blank">https://datatracker.ietf.org/doc/html/rfc4577</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>"Understanding OSPF Sham Links - Technical Documentation - Support - Juniper Networks". www.juniper.net. Archived from the original on November 14, 2021. Retrieved November 14, 2021. <a href="https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ospf-sham-links-overview.html" target="_blank">https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/ospf-sham-links-overview.html</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>"IP Routing: OSPF Configuration Guide, Cisco IOS Release 15SY - OSPF Sham-Link Support for MPLS VPN [Cisco IOS 15.1SY]". Cisco. Archived from the original on November 1, 2021. Retrieved November 14, 2021. <a href="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" target="_blank">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</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>J. Moy (April 1998). OSPF Version 2. Network Working Group. doi:10.17487/RFC2328. STD 54. RFC 2328. Internet Standard 54. Obsoletes RFC 2178. Updated by RFC 5709, 6549, 6845, 6860, 7474 and 8042. <a href="https://datatracker.ietf.org/doc/html/rfc2328" target="_blank">https://datatracker.ietf.org/doc/html/rfc2328</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>"OSPF Neighbor States". Cisco. Archived from the original on October 26, 2018. Retrieved October 28, 2018. <a href="http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html" target="_blank">http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13685-13.html</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>"Show 134 – OSPF Design Part 1 – Debunking the Multiple Area Myth". Packet Pushers. Archived from the original on June 2, 2021. Retrieved February 2, 2021. podcast debunking 50-router advice on old Cisco article <a href="https://packetpushers.net/podcast/show-134-ospf-design-part-1-debunking-the-multiple-area-myth" target="_blank">https://packetpushers.net/podcast/show-134-ospf-design-part-1-debunking-the-multiple-area-myth</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Mikrotik RB4011 has 1 GB RAM for example Archived August 16, 2021, at the Wayback Machine, mikrotik.com, Retrieved Feb 1, 2021. <a href="https://mikrotik.com/product/rb4011igs_rm" target="_blank">https://mikrotik.com/product/rb4011igs_rm</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>"Stub Area Design Golden Rules". Groupstudy.com. Archived from the original on August 31, 2000. Retrieved November 30, 2011. 64 MB of RAM was a big deal in 2020 for OSPF. <a href="https://web.archive.org/web/20000831182105/http://www.groupstudy.com/bookstore/samples/thomas/" target="_blank">https://web.archive.org/web/20000831182105/http://www.groupstudy.com/bookstore/samples/thomas/</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Doyle, Jeff (September 10, 2007). "My Favorite Interview Question". Network World. Archived from the original on December 28, 2021. Retrieved December 28, 2021. <a href="https://www.networkworld.com/article/2348778/my-favorite-interview-question.html" target="_blank">https://www.networkworld.com/article/2348778/my-favorite-interview-question.html</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>(ASGuidelines 1996, p. 25) harv error: no target: CITEREFASGuidelines1996 (help) <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>J. Hawkinson; T. Bates (March 1996). Guidelines for creation, selection, and registration of an Autonomous System (AS). Network Working Group. doi:10.17487/RFC1930. BCP 6. RFC 1930. Best Current Practice 6. Updated by RFC 6996 and 7300. <a href="https://datatracker.ietf.org/doc/html/rfc1930" target="_blank">https://datatracker.ietf.org/doc/html/rfc1930</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>"Stub Area Design Golden Rules". Groupstudy.com. Archived from the original on August 31, 2000. Retrieved November 30, 2011.. This is not necessarily true. If there are multiple ABRs, as might be required for high availability, routers interior to the TSA will send non-intra-area traffic to the ABR with the lowest intra-area metric (the closest ABR) but that requires special configuration. <a href="https://web.archive.org/web/20000831182105/http://www.groupstudy.com/bookstore/samples/thomas/" target="_blank">https://web.archive.org/web/20000831182105/http://www.groupstudy.com/bookstore/samples/thomas/</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> <li id="fn:24"><p>P. Murphy (January 2001). The OSPF Not-So-Stubby Area (NSSA) Option. Network Working Group. doi:10.17487/RFC3101. RFC 3101. Proposed Standard. Obsoletes RFC 1587. <a href="https://datatracker.ietf.org/doc/html/rfc3101" target="_blank">https://datatracker.ietf.org/doc/html/rfc3101</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></p></li> <li id="fn:25"><p>J. Moy (April 1998). OSPF Version 2. Network Working Group. doi:10.17487/RFC2328. STD 54. RFC 2328. Internet Standard 54. Obsoletes RFC 2178. Updated by RFC 5709, 6549, 6845, 6860, 7474 and 8042. <a href="https://datatracker.ietf.org/doc/html/rfc2328" target="_blank">https://datatracker.ietf.org/doc/html/rfc2328</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></p></li> <li id="fn:26"><p>"Cisco IOS IP Routing: OSPF Command Reference" (PDF). Cisco Systems. April 2011. Archived from the original (PDF) on April 25, 2012. <a href="https://web.archive.org/web/20120425041808/http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_cr_book.pdf" target="_blank">https://web.archive.org/web/20120425041808/http://www.cisco.com/en/US/docs/ios/iproute_ospf/command/reference/iro_cr_book.pdf</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></p></li> <li id="fn:27"><p>"juniper configuring-ospf-areas". Juniper Networks. January 18, 2021. Archived from the original on October 23, 2021. Retrieved October 23, 2021. <a href="https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/topic-map/configuring-ospf-areas.html#id-ospf-designated-router-overview" target="_blank">https://www.juniper.net/documentation/us/en/software/junos/ospf/topics/topic-map/configuring-ospf-areas.html#id-ospf-designated-router-overview</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></p></li> <li id="fn:28"><p>"OSPF Area's Explained". Packet Coders. January 23, 2019. Archived from the original on October 23, 2021. Retrieved October 23, 2021. <a href="https://www.packetcoders.io/ospf-areas-explained/" target="_blank">https://www.packetcoders.io/ospf-areas-explained/</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></p></li> <li id="fn:29"><p>"reference-bandwidth (Protocols OSPF) | Junos OS | Juniper Networks". www.juniper.net. Retrieved March 26, 2025. <a href="https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/reference-bandwidth-edit-protocols-ospf.html" target="_blank">https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/reference-bandwidth-edit-protocols-ospf.html</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></p></li> <li id="fn:30"><p>Adjusting OSPF Costs Archived April 14, 2021, at the Wayback Machine, OReilly.com <a href="https://www.oreilly.com/library/view/cisco-ios-cookbook/0596527225/ch08s04.html" target="_blank">https://www.oreilly.com/library/view/cisco-ios-cookbook/0596527225/ch08s04.html</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></p></li> <li id="fn:31"><p>"OSPF Stub Router Advertisement". Ietf Datatracker. Internet Engineering Task Force. June 2001. Archived from the original on October 23, 2021. Retrieved October 23, 2021. <a href="https://datatracker.ietf.org/doc/html/rfc3137" target="_blank">https://datatracker.ietf.org/doc/html/rfc3137</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></p></li> <li id="fn:32"><p>Whether an external route is based on a Type-5 LSA or a Type-7 LSA (NSSA) does not affect its preference. See RFC 3101, section 2.5. <a href="#fnref:32" class="footnote-back-ref">↩</a></p></li> <li id="fn:33"><p>R. Coltun; D. Ferguson; J. Moy (July 2008). A. Lindem (ed.). OSPF for IPv6. Network Working Group. doi:10.17487/RFC5340. RFC 5340. Proposed Standard. Obsoletes RFC 2740. Updated by RFC 6845, 6860, 8362, 7503 and 9454 <a href="https://datatracker.ietf.org/doc/html/rfc5340" target="_blank">https://datatracker.ietf.org/doc/html/rfc5340</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></p></li> <li id="fn:34"><p>"secondary (Protocols OSPF) - TechLibrary - Juniper Networks". www.juniper.net. Archived from the original on November 7, 2021. Retrieved November 7, 2021. <a href="https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/secondary-edit-protocols-ospf.html" target="_blank">https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/secondary-edit-protocols-ospf.html</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></p></li> <li id="fn:35"><p>"Border Gateway Protocol (BGP) Extended Communities". www.iana.org. Archived from the original on November 28, 2021. Retrieved November 28, 2021. <a href="https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml" target="_blank">https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></p></li> <li id="fn:36"><p>E. Rosen; P. Psenak; P. Pillay-Esnault (June 2006). OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). Network Working Group. doi:10.17487/RFC4577. RFC 4577. Proposed Standard. Updates RFC 4364. <a href="https://datatracker.ietf.org/doc/html/rfc4577" target="_blank">https://datatracker.ietf.org/doc/html/rfc4577</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></p></li> <li id="fn:37"><p>"MPLS VPN OSPF PE and CE Support". Cisco. Archived from the original on November 28, 2021. Retrieved November 28, 2021. <a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16-10/mp-l3-vpns-xe-16-10-book/mpls-vpn-ospf-pe-and-ce-support.html" target="_blank">https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16-10/mp-l3-vpns-xe-16-10-book/mpls-vpn-ospf-pe-and-ce-support.html</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></p></li> <li id="fn:38"><p>Cisco. "Using OSPF in an MPLS VPN Environment" (PDF). Archived (PDF) from the original on October 10, 2022. Retrieved November 28, 2021. <a href="https://www.racf.bnl.gov/Facility/TechnologyMeeting/Archive/06-30-04-CISCO/Using-OSPF-in-MPLS-VPN-Environment.pdf" target="_blank">https://www.racf.bnl.gov/Facility/TechnologyMeeting/Archive/06-30-04-CISCO/Using-OSPF-in-MPLS-VPN-Environment.pdf</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></p></li> <li id="fn:39"><p>E. Rosen; P. Psenak; P. Pillay-Esnault (June 2006). Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs). Network Working Group. doi:10.17487/RFC4576. RFC 4576. Proposed Standard. <a href="https://datatracker.ietf.org/doc/html/rfc4576" target="_blank">https://datatracker.ietf.org/doc/html/rfc4576</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></p></li> <li id="fn:40"><p>Katz, D; D. Yeung (September 2003). Traffic Engineering (TE) Extensions to OSPF Version 2. The Internet Society. doi:10.17487/RFC3630. OSPF-TEextensions. Retrieved September 28, 2007. Archived February 14, 2012, at the Wayback Machine <a href="http://datatracker.ietf.org/doc/rfc3630/" target="_blank">http://datatracker.ietf.org/doc/rfc3630/</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></p></li> <li id="fn:41"><p>B. Rajagopalan; J. Luciani; D. Awduche (March 2004). IP over Optical Networks: A Framework. Internet Engineering Task Force. doi:10.17487/RFC3717. RFC 3717. <a href="https://datatracker.ietf.org/doc/html/rfc3717" target="_blank">https://datatracker.ietf.org/doc/html/rfc3717</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></p></li> <li id="fn:42"><p>Berkowitz, Howard (1999). OSPF Goodies for ISPs. North American Network Operators Group NANOG 17. Montreal. Archived from the original on June 12, 2016. <a href="https://web.archive.org/web/20160612140344/https://www.nanog.org/meetings/abstract?id=1149" target="_blank">https://web.archive.org/web/20160612140344/https://www.nanog.org/meetings/abstract?id=1149</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></p></li> <li id="fn:43"><p>Katz, Dave (2000). OSPF and IS-IS: A Comparative Anatomy. North American Network Operators Group NANOG 19. Albuquerque. Archived from the original on June 20, 2018. <a href="https://web.archive.org/web/20180620232619/https://www.nanog.org/meetings/abstract?id=1084" target="_blank">https://web.archive.org/web/20180620232619/https://www.nanog.org/meetings/abstract?id=1084</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></p></li> </ol>