RFC 1247
OSPF Version 2
RFC 1247: OSPF Version 2 🦋
Okay bestie, so this is RFC 1247, titled OSPF Version 2 💅. J. Moy from Proteon, Inc. wrote it, and it came out in July 1991. It's an IAB standards track protocol for the Internet community, and it obsoletes RFC 1131. It doesn't update anything else. 🌸
Status of this Memo ✨
This RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 🌈.
Abstract 💜
This memo documents version 2 of the OSPF protocol 🔥. OSPF is a link-state based routing protocol, and it's built to run inside a single Autonomous System. Every OSPF router keeps an identical database that describes the Autonomous System's topology, and from that database each router calculates a routing table by building a shortest-path tree 🧚.
OSPF recalculates routes quickly when the topology changes, and it does it while using a minimum of routing protocol traffic 😭. It supports equal-cost multipath, and it can calculate separate routes for each IP type of service. It also provides an area routing capability, which adds another level of routing protection and cuts down on routing protocol traffic. On top of all that, every OSPF routing protocol exchange is authenticated 🔒.
Version 1 of the OSPF protocol was documented in RFC 1131. The differences between the two versions are explained in Appendix F 🍓.
Please send comments to ospf@trantor.umd.edu 💌.
1. Introduction 🎀
This document is a specification of the Open Shortest Path First (OSPF) internet routing protocol 👑. OSPF is classified as an Internal Gateway Protocol (IGP), which means it distributes routing information between routers that belong to a single Autonomous System. OSPF is based on SPF, or link-state, technology. That's a departure from the Bellman-Ford base that traditional internet routing protocols use 🙈.
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It was designed specifically for the internet environment, with explicit support for IP subnetting, TOS-based routing, and tagging of externally-derived routing information ✨. OSPF also provides authentication of routing updates, and it uses IP multicast when sending and receiving those updates 📡. On top of that, a lot of work went into making it respond quickly to topology changes while still keeping routing protocol traffic small 🦋.
The author would like to thank Rob Coltun, Milo Medin, Mike Petry, and the rest of the OSPF working group for the ideas and support they gave to this project 🫶💖.
1.1 Protocol overview 🧚
OSPF routes IP packets based solely on the destination IP address and the IP Type of Service found in the IP packet header 🎯. IP packets are routed "as is," which means they aren't encapsulated in any further protocol headers as they transit the Autonomous System 💅. OSPF is a dynamic routing protocol. It quickly detects topological changes in the AS, such as router interface failures, and it calculates new loop-free routes after a period of convergence. That convergence period is short and involves a minimum of routing traffic ⭐.
In an SPF-based routing protocol, each router maintains a database that describes the Autonomous System's topology, and every participating router has an identical copy 👯. Each individual piece of this database is a particular router's local state, such as its usable interfaces and reachable neighbors. The router spreads its local state throughout the Autonomous System by flooding 🌊.
All routers run the exact same algorithm, in parallel. From the topological database, each router builds a tree of shortest paths with itself as the root. That shortest-path tree gives the route to every destination in the Autonomous System, and externally derived routing information shows up on the tree as leaves 🌳.
OSPF calculates separate routes for each Type of Service (TOS). When several equal-cost routes to a destination exist, traffic gets distributed equally among them. The cost of a route is described by a single dimensionless metric 📊.
OSPF lets sets of networks be grouped together, and that grouping is called an area 🏡. The topology of an area is hidden from the rest of the Autonomous System, and that information hiding cuts routing traffic down a lot. Routing within the area is determined only by the area's own topology, which protects the area from bad routing data 🛡️. An area is a generalization of an IP subnetted network 💜.
OSPF makes flexible IP subnet configuration possible 🎀. Each route OSPF distributes has a destination and a mask. Two different subnets of the same IP network number can have different sizes, meaning different masks. This is commonly called variable length subnets 🙌. A packet is routed to the best match, which means the longest or most specific one 🎯. Host routes are treated as subnets whose masks are "all ones" (0xffffffff) 💫.
All OSPF protocol exchanges are authenticated, which means only trusted routers can take part in the Autonomous System's routing 🔐. A variety of authentication schemes can be used, but a single authentication scheme is configured for each area. That means some areas can use much stricter authentication than others 💪.
Externally derived routing data, like routes learned from the Exterior Gateway Protocol (EGP), gets passed transparently throughout the Autonomous System 🌍. That external data is kept separate from OSPF's link state data. Each external route can also be tagged by the router that advertises it, which lets routers on the boundaries of the Autonomous System pass along extra information 🏷️.
1.2 Definitions of commonly used terms 📚
Here's a collection of definitions for terms that have a specific meaning to the protocol and show up all over the text 💅. If you're new to the Internet Protocol Suite, the document points you to [RS-85-153] for an intro to IP 🌸.
Router A level three Internet Protocol packet switch 🛣️. It used to be called a gateway in a lot of the IP literature.
Autonomous System A group of routers that exchange routing information through a common routing protocol. It's abbreviated as AS 🌈.
Internal Gateway Protocol The routing protocol spoken by the routers that belong to an Autonomous System. It's abbreviated as IGP. Each Autonomous System has a single IGP, but different Autonomous Systems can run different IGPs 🧩.
Router ID A 32-bit number assigned to each router running OSPF. It uniquely identifies the router within an Autonomous System 🆔.
Network In this paper, a network means an IP network or subnet. One physical network can be assigned multiple IP network/subnet numbers, and those count as separate networks. Point-to-point physical networks are the exception. They count as a single network no matter how many IP network/subnet numbers (if any) are assigned to them 🤓.
Network mask A 32-bit number that indicates the range of IP addresses on a single IP network/subnet. This specification displays network masks as hexadecimal numbers. For example, the network mask for a class C IP network is displayed as 0xffffff00. Elsewhere in the literature, that same mask is often displayed as 255.255.255.0 🎭.
Multi-access networks Physical networks that support the attachment of multiple (more than two) routers. Each pair of routers on such a network is assumed to be able to communicate directly, so multi-drop networks are excluded 🚫.
Interface The connection between a router and one of its attached networks. An interface holds state information that comes from the underlying lower level protocols and from the routing protocol itself. An interface to a network has a single IP address and mask associated with it, unless the network is an unnumbered point-to-point network. An interface is sometimes also called a link 🔗.
Neighboring routers Two routers that have interfaces to a common network. On multi-access networks, OSPF's Hello Protocol dynamically discovers neighbors 👋.
Adjacency A relationship formed between selected neighboring routers so they can exchange routing information. Not every pair of neighboring routers becomes adjacent 🤝.
Link state advertisement Describes the local state of a router or network, including the state of the router's interfaces and adjacencies. Every link state advertisement gets flooded throughout the routing domain, and all of them together form the protocol's topological database 📣.
Hello protocol The part of the OSPF protocol used to establish and maintain neighbor relationships. On multi-access networks, the Hello protocol can also dynamically discover neighboring routers 👂.
Designated Router Every multi-access network with at least two attached routers has a Designated Router. The Designated Router generates a link state advertisement for the multi-access network and has other special responsibilities in running the protocol. The Hello Protocol elects the Designated Router 👑.
The Designated Router concept reduces the number of adjacencies required on a multi-access network. That in turn cuts down on routing protocol traffic and shrinks the size of the topological database 📉.
Lower-level protocols The underlying network access protocols that provide services to the Internet Protocol and, in turn, to OSPF. Examples include the X.25 packet and frame levels for PDNs, and the ethernet data link layer for ethernets 🔌.
1.3 Brief history of SPF-based routing technology 🕰️
OSPF is an SPF-based routing protocol. In the literature, these protocols are also called link-state or distributed-database protocols 💅. This section gives a quick rundown of the SPF-based developments that influenced OSPF 🌟.
The first SPF-based routing protocol was developed for the ARPANET packet switching network. It's described in [McQuillan], and it became the starting point for all other SPF-based protocols 🥇. The homogeneous ARPANET environment, meaning single-vendor packet switches connected by synchronous serial lines, made the original protocol simpler to design and implement 🧸.
Modifications to this protocol were proposed in [Perlman] 🛠️. They focused on increasing the fault tolerance of the routing protocol by, among other things, adding a checksum to link state advertisements, which detects database corruption 🔍. The paper also described ways to reduce routing traffic overhead in an SPF-based protocol. It did this by introducing mechanisms that let the interval between link state advertisements increase by an order of magnitude 📈.
An SPF-based algorithm has also been proposed for use as the ISO IS-IS routing protocol, described in [DEC] 🌐. That protocol includes methods for cutting data and routing traffic when operating over broadcast networks. It does this by electing a Designated Router for each broadcast network, and that Designated Router then originates a link state advertisement for the network 🎉.
The OSPF subcommittee of the IETF extended this work to develop the OSPF protocol 💜. The Designated Router concept was greatly enhanced to cut routing traffic even more. Multicast capabilities are used to reduce routing bandwidth even further 📡. An area routing scheme has been developed, enabling...
Finally, the algorithm has been modified for efficient operation in the internet environment 🌐✨ it's giving glow-up energy.
1.4 Organization of this document 📚
okay so the first three sections give you the big-picture tour of what the protocol can do and how it works 🗺️. Sections 4-16 are where the mechanisms get explained in detail 🔍. The packet formats, protocol constants, configuration items and required management statistics all live in the appendices 📎.
Labels like HelloInterval that pop up in the text refer to protocol constants 🎀. They may or may not be configurable. The architectural constants are explained in Appendix B, and the configurable constants are explained in Appendix C 💖.
The detailed spec is written in terms of data structures, which makes the explanation way more precise 💅. Implementations are required to support the functionality described, but they don't need to use the exact data structures in this paper 🫶.
2. The Topological Database 🗺️
The database of the Autonomous System's topology describes a directed graph 🦋. The vertices of the graph are routers and networks. A graph edge connects two routers when they're attached via a physical point-to-point network. An edge connecting a router to a network means the router has an interface on that network 🔗.
The vertices can be typed further by function 🧚. Only some of these types carry transit data traffic, meaning traffic that is neither locally originated nor locally destined 🚦. Vertices that can carry transit traffic show up on the graph with both incoming and outgoing edges ➡️⬅️.
Vertex type Vertex name Transit?
_____________________________________
1 Router yes
2 Network yes
3 Stub network no
Table 1: OSPF vertex types.OSPF supports the following types of physical networks 🌈:
- Point-to-point networks: A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network.
- Broadcast networks: Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these nets using OSPF's Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The protocol makes further use of multicast capabilities, if they exist. An ethernet is an example of a broadcast network 📡.
- Non-broadcast networks: Networks supporting many (more than two) routers, but having no broadcast capability. Neighboring routers are also discovered on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information is necessary for the correct operation of the Hello Protocol. On these networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non-broadcast network 🙈.
The neighborhood of each network node in the graph depends on whether the network is multi-access (either broadcast or non-broadcast) and, if it is, how many routers have an interface to it 👀. The three cases are shown in Figure 1. Rectangles are routers. Circles and oblongs are multi-access networks. Router names start with RT and network names start with N. Router interface names start with I. Lines between routers mean point-to-point networks. The left side of the figure shows a network with its connected routers, and the resulting graph is on the right 🎀.
______________________________________
(Figure not included in text version.)
Figure 1: Network map components
______________________________________Two routers joined by a point-to-point network show up in the directed graph as directly connected by a pair of edges, one in each direction ↔️. Interfaces to physical point-to-point networks don't need IP addresses assigned to them. A point-to-point network like that is called unnumbered 🫠. The graph representation for point-to-point networks is designed so that unnumbered networks are supported naturally 💜. When interface addresses do exist, they're modelled as stub routes. Each router would then have a stub connection to the other router's interface address (see Figure 1) ✨.
When multiple routers are attached to a multi-access network, the directed graph shows all of them bidirectionally connected to the network vertex (again, see Figure 1) 🕸️. If only a single router is attached to a multi-access network, the network appears in the directed graph as a stub connection 🧸.
Each network (stub or transit) in the graph has an IP address and an associated network mask 🌸. The mask shows the number of nodes on the network. Hosts attached directly to routers (called host routes) show up on the graph as stub networks. The network mask for a host route is always 0xffffffff, which means there's a single node 🙌.
Figure 2 is a sample map of an Autonomous System 🗺️. The rectangle labelled H1 is a host with a SLIP connection to router RT12, so RT12 advertises a host route 🦋. Lines between routers mean physical point-to-point networks. The only point-to-point network that has interface addresses assigned is the one joining routers RT6 and RT10 🎀. Routers RT5 and RT7 have EGP connections to other Autonomous Systems 🌈. A set of EGP-learned routes is displayed for both of these routers 🔥.
______________________________________
(Figure not included in text version.)
Figure 2: A sample Autonomous System
______________________________________A cost is associated with the output side of each router interface 💰. The system administrator can configure it. The lower the cost, the more likely the interface is to be used to forward data traffic 🏃♀️. Costs are also associated with externally derived routing data (for example, the EGP-learned routes) 📬.
The directed graph from the Figure 2 map is shown in Figure 3 🧚. Arcs are labelled with the cost of the corresponding router output interface. Arcs with no labelled cost have a cost of 0. Arcs leading from networks to routers always have cost 0, but they still matter 🫶. The externally derived routing data shows up on the graph as stubs 🌿.
The topological database (the directed graph from above) is pieced together from link state advertisements generated by the routers 🧩. The neighborhood of each transit vertex is represented in a single, separate link state advertisement. Figure 4 shows the link state representation of the two kinds of transit vertices, routers and multi-access networks 💅. Router RT12 has an interface to two broadcast networks and a SLIP line to a host.
__________________________________________
(Figures not included in text version.)
Figure 3: The resulting directed graph
Figure 4: Individual link state components
__________________________________________Network N6 is a broadcast network with three attached routers. The cost of all links from network N6 to its attached routers is 0 💖. Note that the link state advertisement for network N6 is actually generated by one of the attached routers, namely the one elected Designated Router for the network 👑.
2.1 The shortest-path tree 🌳
When no OSPF areas are configured, each router in the Autonomous System has an identical topological database, which leads to an identical graphical representation 👯. A router generates its routing table from this graph by calculating a tree of shortest paths with the router itself as root. Obviously, the shortest-path tree depends on the router doing the calculation 🙃. The shortest-path tree for router RT6 in our example is shown in Figure 5.
The tree gives the entire route to any destination network or host. However, only the next hop to the destination is used in the forwarding process 🎯. The best route to any router also gets calculated. For processing external data, we note the next hop and distance to any router advertising external routes 📍. The resulting routing table for router RT6 is in Table 2. There's a separate route for each end of a numbered serial line (in this case, the serial line between routers RT6 and RT10) 💫.
______________________________________
(Figure not included in text version.)
Figure 5: The SPF tree for router RT6
______________________________________ Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
Table 2: The portion of router RT6's routing table listing local
destinations.Routes to networks belonging to other AS'es (like N12) show up as dashed lines on the shortest path tree in Figure 5 🪄. Using this externally derived routing information is covered in the next section 👀.
2.2 Use of external routing information 🔍
After the tree is created, the external routing information gets examined 🧐. This information may come from another routing protocol such as EGP, or be statically configured (static routes). Default routes can also be included as part of the Autonomous System's external routing information 🏠.
External routing information is flooded unaltered throughout the AS 🌊. In our example, every router in the Autonomous System knows that router RT7 has two external routes, with metrics 2 and 9 📊.
OSPF supports two types of external metrics 💁♀️. Type 1 external metrics are equivalent to the link state metric. Type 2 external metrics are greater than the cost of any path internal to the AS. Using Type 2 external metrics assumes that routing between AS'es is the major cost of routing a packet, and it eliminates the need to convert external costs to internal link state metrics 🧠.
Here's an example of Type 1 external metric processing 🎀. Suppose routers RT7 and RT5 in Figure 2 are advertising Type 1 external metrics. For each external route, the distance from Router RT6 is calculated as the sum of the external route's cost and the distance from Router RT6 to the advertising router 🧮. For every external destination, the router advertising the shortest route is discovered, and the next hop to that advertising router becomes the next hop to the destination 🏁.
Both Router RT5 and RT7 are advertising an external route to destination network N12. Router RT7 is preferred since it is advertising N12 at a
so RT7 gets a distance of 10 (8+2) to Router RT6, which is way better than RT5's 14 (6+8) 💅 Table 3 shows the entries that get added to the routing table when external routes are examined 🌸
Destination Next Hop Distance
__________________________________
N12 RT10 10
N13 RT5 14
N14 RT5 14
N15 RT10 17
Table 3: The portion of router RT6's routing table listing external
destinations.okay so Type 2 external metrics are lowkey way simpler 🧚 The AS boundary router advertising the smallest external metric wins, no matter how far away it is internally. So if RT5 and RT7 were both advertising Type 2 routes in our example, all the traffic for N12 would go to RT7, since 2 < 8 🎀 If several equal-cost Type 2 routes show up, the internal distance to the advertising routers breaks the tie ✨
Both Type 1 and Type 2 external metrics can exist in the AS at the same time 🦋 When that happens, Type 1 external metrics always take precedence 👑
This section has assumed that packets for external destinations always go through the advertising AS boundary router. ngl that's not always the move 🙈 For example, say there's an extra router attached to network N6 in Figure 2, called Router RTX. RTX doesn't participate in OSPF routing, but it does exchange EGP information with the AS boundary router RT7. Then RT7 would end up advertising OSPF external routes for every destination that should be routed to RTX. Sometimes that adds an extra hop, if packets for these destinations always have to go to RT7 first (the advertising router) 💀
To fix this, the OSPF protocol lets an AS boundary router specify a "forwarding address" in its external advertisements. In the example above, Router RT7 would specify RTX's IP address as the "forwarding address" for all the destinations whose packets should go straight to RTX 💖
The "forwarding address" has one other trick too 🧚♀️ It lets routers inside the Autonomous System act as "route servers". For instance, in Figure 2 the router RT6 could become a route server, getting external routing information through a combo of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router, and would originate a collection of OSPF external advertisements. In each external advertisement, router RT6 would specify the correct Autonomous System exit point to use for that destination, by setting the advertisement's "forwarding address" field appropriately 🫶
2.3 Equal-cost multipath 🌈
The discussion above has been simplified by only considering a single route to any destination 🙈 In reality, if multiple equal-cost routes to a destination exist, they are all discovered and used. This needs no conceptual changes to the algorithm, and we'll postpone its discussion until we look at the tree-building process in more detail 🍓
With equal cost multipath, a router can potentially have several available next hops toward any given destination 💜
2.4 TOS-based routing 🦋
OSPF can calculate a separate set of routes for each IP Type of Service 🎀 The IP TOS values are represented in OSPF exactly as they appear in the IP packet header. This means that, for any destination, there can potentially be multiple routing table entries, one for each IP TOS ✨
Up to this point, every example has assumed that routes don't vary on TOS. To differentiate routes based on TOS, separate interface costs can be configured for each TOS. For example, in Figure 2 there could be multiple costs (one for each TOS) listed for each interface. A cost for TOS 0 must always be specified 💅
When interface costs vary based on TOS, a separate shortest path tree is calculated for each TOS (see Section 2.1). External costs can vary based on TOS too 👑 For example, in Figure 2 router RT7 could advertise a separate type 1 external metric for each TOS. Then, when calculating the TOS X distance to network N15, the cost of the shortest TOS X path to RT7 would be added to the TOS X cost advertised by RT7 (see Section 2.2) 🌸
All OSPF implementations must be capable of calculating routes based on TOS. However, OSPF routers can be configured to route all packets on the TOS 0 path (see Appendix C), which eliminates the need to calculate non-zero TOS paths. This can be used to conserve routing table space and processing resources in the router 🧚 These TOS-0-only routers can be mixed with routers that do route based on TOS. TOS-0-only routers will be avoided as much as possible when forwarding traffic that requests a non-zero TOS 🫶
It may be the case that no path exists for some non-zero TOS, even if the router is calculating non-zero TOS paths. In that case, packets requesting that non-zero TOS are routed along the TOS 0 path (see Section 11.1) 💀
3. Splitting the AS into Areas 🗺️✨
OSPF lets collections of contiguous networks and hosts be grouped together 🎀 Such a group, together with the routers having interfaces to any one of the included networks, is called an area. Each area runs a separate copy of the basic SPF routing algorithm. That means each area has its own topological database and corresponding graph, as explained in the previous section 🦋
The topology of an area is invisible from outside the area. Conversely, routers internal to a given area know nothing of the detailed topology external to the area. This isolation of knowledge lets the protocol cut routing traffic by a marked amount, compared to treating the entire Autonomous System as a single SPF domain 🌈
With areas introduced, it's no longer true that all routers in the AS have an identical topological database. A router actually has a separate topological database for each area it's connected to. (Routers connected to multiple areas are called area border routers.) Two routers belonging to the same area have identical area topological databases for that area 💖
Routing in the Autonomous System happens on two levels, depending on whether the source and destination of a packet are in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used. This protects intra-area routing from the injection of bad routing information 🛡️ We'll discuss inter-area routing in Section 3.2 🧚
3.1 The backbone of the Autonomous System 🦴
The backbone consists of those networks not contained in any area, their attached routers, and those routers that belong to multiple areas. The backbone must be contiguous 👑
It's possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links 😭
Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area. Virtual links belong to the backbone. The protocol treats two routers joined by a virtual link as if they were connected by an unnumbered point-to-point network. On the graph of the backbone, two such routers are joined by arcs whose costs are the intra-area distances between the two routers. The routing protocol traffic that flows along the virtual link uses intra-area routing only 🫶
The backbone is responsible for distributing routing information between areas. The backbone itself has all of the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing of the topology of the areas 🌸
3.2 Inter-area routing 🚀
When routing a packet between two areas, the backbone is used 🎀 The path the packet travels can be broken into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost ✨
Looking at it another way, inter-area routing can be pictured as forcing a star configuration on the Autonomous System, with the backbone as hub and each of the areas as spokes 🌟
The topology of the backbone dictates the backbone paths used between areas. The topology of the backbone can be enhanced by adding virtual links. This gives the system administrator some control over the routes taken by inter-area traffic 💅
The correct area border router to use as the packet exits the source area is chosen in exactly the same way routers advertising external routes are chosen. Each area border router in an area summarizes for the area its cost to all networks external to the area. After the SPF tree is calculated for the area, routes to all other networks are calculated by examining the summaries of the area border routers 🧠
3.3 Classification of routers 🏷️
Before areas were introduced, the only OSPF routers with a specialized function were those advertising external routing information, such as router RT5 in Figure 2. When the AS is split into OSPF areas, the routers are further divided by function into the following four overlapping categories 🍓
- Internal routers: A router with all directly connected networks belonging to the same area. Routers with only backbone interfaces also belong to this category. These routers run a single copy of the basic routing algorithm. 🌱
- Area border routers: A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area and an additional copy for the backbone. Area border routers condense the topological information of their attached areas for distribution to the backbone. The backbone in turn distributes the information to the other areas. 🌉
- Backbone routers: A router that has an interface to the backbone. This includes all routers that interface to more than one area (i.e., area border routers). However, backbone routers do not have to be area border routers. Routers with all interfaces connected to the backbone are considered to be internal routers. 🦴
- AS boundary routers: A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router has AS external routes that are advertised throughout the Autonomous System. The path to each AS boundary router is known by every router in the AS. This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone. 🌍
3.4 A sample area configuration 🗂️
Figure 6 shows a sample area configuration. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7, RT8, RT10, RT11. The third area consists of networks N9-N11 and host H1, along with their attached routers RT9, RT11, RT12. The third area has been configured so that networks N9-N11 and host H1 will all be grouped into a single route when advertised external to the area (see Section 3.5 for more details) 🎀
In Figure 6, routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Finally, as before, routers RT5 and RT7 are AS boundary routers 🫶
Figure 7 shows the resulting topological database for the Area 1. The
figure completely describes that area's intra-area routing 💅 It also shows the complete view of the internet for the two internal routers RT1 and RT2, so it's literally the whole picture, bestie 😭✨. It's the job of the area border routers, RT3 and RT4, to advertise into Area 1 the distances to all destinations external to the area. Figure 7 shows these as the dashed stub routes 🦋. Also, RT3 and RT4 must advertise into Area 1 the location of the AS boundary routers RT5 and RT7. And finally, external advertisements from RT5 and RT7 get flooded throughout the entire AS, and in particular throughout Area 1 🌈. These advertisements live in Area 1's database and yield routes to networks N12-N15.
Routers RT3 and RT4 must also summarize Area 1's topology for distribution to the backbone 🎀. Their backbone advertisements are in Table 4. These summaries show which networks are contained in Area 1 (i.e., networks N1-N4), and the distance to those networks from RT3 and RT4 respectively.
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3Table 4: Networks advertised to the backbone by routers RT3 and RT4.
______________________________________
(Figure not included in text version.)
Figure 7: Area 1's Database
Figure 8: The backbone database
______________________________________The backbone topological database is shown in Figure 8 🧚. The routers pictured there are the backbone routers. Router RT11 is a backbone router because it belongs to two areas, which is so main character energy 👑. In order to make the backbone connected, a virtual link has been configured between routers R10 and R11 🔗.
Again, routers RT3, RT4, RT7, RT10 and RT11 are area border routers 🌸. Just like RT3 and RT4 did above, they've condensed the routing information of their attached areas for distribution via the backbone. These are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense networks N9-N11 and Host H1 into a single route, so there's one dashed line for N9-N11 and Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary routers, and their externally derived information shows up on the graph in Figure 8 as stubs too 🫶.
The backbone is how area border routers swap summary info with each other. Every area border router hears the area summaries from all the other area border routers. Then it builds a picture of the distance to all networks outside its own area by checking out those collected advertisements and adding in the backbone distance to each advertising router 💅.
Using RT3 and RT4 as an example again, here's the process 🍓. They first calculate the SPF tree for the backbone. This gives them the distances to all the other area border routers. They also note the distances to the networks (Ia and Ib) and the AS boundary routers (RT5 and RT7) that belong to the backbone. This calculation is shown in Table 5.
Area border dist from dist from
router RT3 RT4
______________________________________
to RT3 * 21
to RT4 22 *
to RT7 20 14
to RT10 15 22
to RT11 18 25
______________________________________
to Ia 20 27
to Ib 15 22
______________________________________
to RT5 14 8
to RT7 20 14Table 5: Backbone distances calculated by routers RT3 and RT4.
Next, by looking at the area summaries from these area border routers, RT3 and RT4 can work out the distance to every network outside their area ✨. Those distances then get advertised internally to the area by RT3 and RT4. The advertisements those routers make into Area 1 are shown in Table 6. Note that Table 6 assumes an area range has been configured for the backbone, grouping I5 and I6 into a single advertisement 🎀.
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 15 22
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 19 26
_________________________________
RT5 14 8
RT7 20 14Table 6: Destinations advertised into Area 1 by routers RT3 and RT4.
All of this info lets an internal router, like RT1, choose an area border router intelligently 🧠. RT1 would use RT4 for traffic to network N6 and RT3 for traffic to network N10, and it would load share between the two for traffic to network N8 💖.
RT1 can also figure out the shortest path to the AS boundary routers RT5 and RT7 in this same way 🌈. Then, by looking at the external advertisements from RT5 and RT7, RT1 can decide between RT5 or RT7 when sending to a destination in another Autonomous System (one of the networks N12-N15) 🦋.
Heads up, though: if the line between routers RT6 and RT10 fails, the backbone becomes disconnected 😭. Configuring another virtual link between routers RT7 and RT10 gives the backbone more connectivity and more resistance to failures like that 💪. A virtual link between RT7 and RT10 would also allow a much shorter path between the third area (containing N9) and router RT7, which is advertising a good route to external network N12 🚀.
3.5 IP subnetting support 🎀
OSPF attaches an IP address mask to each advertised route 🧩. The mask shows the range of addresses being described by that route. For example, a summary advertisement for the destination 128.185.0.0 with a mask of 0xffff0000 is actually describing a single route to the whole collection of destinations 128.185.0.0 - 128.185.255.255 🌸. Similarly, host routes are always advertised with a mask of 0xffffffff, which means there's only a single destination ✨.
Including the mask with each advertised destination is what makes variable-length subnet masks possible 💅. That means a single IP class A, B, or C network number can be broken up into many subnets of different sizes. For example, the network 128.185.0.0 could be broken up into 64 variable-sized subnets: 16 subnets of size 4K, 16 subnets of size 256, and 32 subnets of size 8 🍓. Table 7 shows some of the resulting network addresses together with their masks:
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8Table 7: Some sample subnet sizes.
There are lots of ways to divide a class A, B, or C network into variable-sized subnets 🧁. The exact procedure for doing so is beyond the scope of this specification. The spec does establish this guideline, though: when an IP packet is forwarded, it is always forwarded to the network that is the best match for the packet's destination 🎯. Here, "best match" is the same thing as the longest or most specific match. For example, the default route with destination 0.0.0.0 and mask 0x00000000 is always a match for every IP destination, but it's always less specific than any other match 🙈. Subnet masks must be assigned so that the best match for any IP destination is unambiguous 💜.
The OSPF area concept is modelled after an IP subnetted network 🦋. OSPF areas were loosely defined as a collection of networks. In reality, an OSPF area is specified as a list of address ranges (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Many separate networks can sit inside a single address range, just like a subnetted network is made up of many separate subnets 🫶. Area border routers then summarize the area contents (for distribution to the backbone) by advertising a single route for each address range. The cost of that route is the minimum cost to any of the networks in the specified range 💰.
For example, an IP subnetted network can be configured as a single OSPF area 🌈. In that case, the area is defined as a single address range: a class A, B, or C network number along with its natural IP mask. Inside the area, any number of variable-sized subnets could be defined. Outside the area, a single route for the entire subnetted network gets distributed, which hides even the fact that the network is subnetted at all 🙈. The cost of this route is the minimum of the set of costs to the component subnets ✨.
3.6 Supporting stub areas 🌷
In some Autonomous Systems, most of the topological database may be external advertisements 😵💫. An OSPF external advertisement is usually flooded throughout the entire AS. However, OSPF lets certain areas be configured as "stub areas" 🧸. External advertisements are not flooded into or throughout stub areas, so routing to AS external destinations in these areas is based on a (per-area) default only. This shrinks the topological database size, and therefore the memory requirements, for a stub area's internal routers 💖.
To take advantage of OSPF stub area support, default routing must be used in the stub area 🧭. Here's how it works: one or more of the stub area's area border routers must advertise a default route into the stub area via summary advertisements. These summary defaults are flooded throughout the stub area, but no further. (That's why these defaults only pertain to that particular stub area 🔒.) These summary default routes match any destination that isn't explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations) 🌍.
An area can be configured as stub when there's a single exit point from the area, or when the choice of exit point doesn't need to be made on a per-external-destination basis 🚪. For example, area 3 in Figure 6 could be configured as a stub area, because all external traffic has to travel through its single area border router RT11 🎯. If area 3 were configured as a stub, RT11 would advertise a default route for distribution inside area 3 (in a summary advertisement), instead of flooding the external advertisements for networks N12-N15 into or throughout the area 🌷.
The OSPF protocol makes sure all routers in an area agree on whether the area has been configured as a stub 🤝. That guarantees no confusion arises in the flooding of external advertisements 🙌.
There are a couple of restrictions on using stub areas 🚫. Virtual links cannot be configured through stub areas. And AS boundary routers cannot be placed internal to stub areas 😬.
3.7 Partitions of areas 🧩
OSPF doesn't actively try to repair area partitions 🛠️. When an area becomes partitioned, each component simply becomes a separate area. The backbone then does the routing between the new areas 🦋. Some destinations that were reachable via intra-area routing before the partition will now require inter-area routing 💅.
Okay so the first bit picks up right where 3.7 left off, bestie 💅 Any address range still has to sit completely inside ONE piece of a partitioned area 🧩 because that's how the area gets summarized to the backbone. And the backbone itself MUST NOT partition 🙅♀️ or whole chunks of the Autonomous System go unreachable 😭 Good news: backbone partitions can get patched with virtual links (see Section 15) 🩹
Here's a fun way to picture partitions 🌈 Grab the Autonomous System graph from Section 2 and think of Area IDs as COLORS on the edges 🎨[1] Every edge hooks up to a network, or IS a point-to-point network, and either way it gets painted with that network's Area ID.
All the edges that are the same color and linked together through vertices = one area 🦋 If the AS is intact, you'll see a few distinct color regions, one per Area ID 💜
When the AS topology changes and an area splits 💔 you get multiple regions of the SAME color. Routing keeps working as long as those same-colored chunks are all connected through the single backbone region 🔗
4. Functional Summary ✨
Each area gets its own copy of OSPF's basic routing algorithm running 🏃♀️ and routers touching multiple areas run multiple copies, which is very main character of them 👑 Here's the quick recap 🎀
When a router boots up, it sets up its routing protocol data structures first 🛠️ then it just waits for the lower-level protocols to say "yep, your interfaces work" 🔌
Next, it uses the OSPF Hello Protocol to make friends 🫶 It sends Hello packets to neighbors and gets theirs back. On broadcast and point-to-point networks, it finds neighbors automatically by sending Hellos to the multicast address AllSPFRouters 📡 On non-broadcast networks, you NEED some configuration info to find neighbors 🗺️ And on ALL multi-access networks (broadcast or non-broadcast), the Hello Protocol also picks a Designated Router for that network 👑
The router then tries to form adjacencies with some of its brand new neighbors 🤝 Topological databases get synced between adjacent pairs. On multi-access networks, the Designated Router decides who gets to be adjacent 💅
Adjacencies control who gets routing protocol packets 📬 Those packets only go out and come in over adjacencies. Database updates travel along adjacencies too 🛤️
A router keeps advertising its state (aka its link state) on a regular schedule 🗓️ and also whenever that state changes 🔄 Its adjacencies show up in its link state advertisements, and THAT's how the protocol catches dead routers quickly 💀
Link state advertisements get flooded through the whole area 🌊 The flooding is reliable, so every router in an area ends up with EXACTLY the same topological database 🥰 That database is basically all the link state advertisements from every router in the area. From it, each router builds a shortest-path tree with itself as the root 🌳 and that tree spits out the routing table 🎯
4.1 Inter-area routing
The stuff in the last section was all about one area 🏠 For intra-area routing, nothing else is needed 🙌 To reach places OUTSIDE the area though, the area border routers inject extra routing info into the area 💌 This extra info is basically a distilled version of the rest of the AS's topology 🧃
Here's how that distillation works 🧠 Every area border router is, by definition, connected to the backbone 🦴 Each one summarizes its attached areas and sends that summary out on the backbone, so every other area border router gets it too 📤 So an area border router ends up with complete topology info about the backbone PLUS the area summaries from all the other area border routers 🤯 From all that, it works out paths to every destination NOT inside its attached areas, then advertises those paths into its own attached areas 📣 This lets the internal routers pick the BEST exit router when they're sending traffic to other areas 🚪✨
4.2 AS external routes
Routers that know stuff about other Autonomous Systems can flood that info through the AS 🌍 The external routing info gets passed along verbatim to every participating router 📜 Just one exception 🙈: external routing info does NOT get flooded into "stub" areas (see Section 3.6) 🚫
To actually USE external routing info, the path to every router advertising it has to be known across the whole AS, except the stub areas 🗺️ That's why the locations of these AS boundary routers get summarized by the (non-stub) area border routers 📦
4.3 Routing protocol packets
OSPF runs straight over IP, using IP protocol 89 🧵 OSPF doesn't have its own fragmentation or reassembly 🙅♀️ so if fragmentation is needed, IP's fragmentation/reassembly handles it 🧩 OSPF packets were designed so big ones can usually get split into several smaller ones 🍰 That practice is RECOMMENDED, and IP fragmentation SHOULD be avoided whenever possible 🫠
Routing protocol packets SHOULD always be sent with the IP TOS field set to 0 🎀 If at all possible, they SHOULD get priority over regular IP data traffic, both when sending AND receiving 🏃♀️💨 To help with that, OSPF protocol packets SHOULD have their IP precedence field set to Internetwork Control (see [RFC 791]) 👑
Every OSPF protocol packet shares a common protocol header, described in Appendix A 📋 The OSPF packet types are listed in Table 8 below, and their formats are also in Appendix A 💅
Type Packet name Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
Table 8: OSPF packet types.OSPF's Hello protocol uses Hello packets to discover and maintain neighbor relationships 🤝 Database Description and Link State Request packets are used when forming adjacencies 🧱 And OSPF's reliable update mechanism runs on Link State Update and Link State Acknowledgment packets 🔁
Each Link State Update packet carries a set of new link state advertisements, one hop further from where they started 🏃♀️➡️ One Link State Update can hold advertisements from several routers 📦 Every advertisement is tagged with the ID of its originating router AND a checksum of its link state contents 🏷️ There are five types of OSPF link state advertisements, listed in Table 9 🌸
LS Advertisement Advertisement description
type name
____________________________________________________________________________
1 Router links advs. Originated by all routers. This
advs. advertisement describes the collected
states of the router's interfaces to an
area. Flooded throughout a single area
only.
____________________________________________________________________________
2 Network links Originated for multi-access networks by
advs. the Designated Router. This
advertisement contains the list of
routers connected to the network.
Flooded throughout a single area only.
LS Advertisement Advertisement description
type name
____________________________________________________________________________
____________________________________________________________________________
3,4 Summary link Originated by area border routers, and
advs. flooded throughout their associated
area. Each summary link advertisement
describes a route to a destination
outside the area, yet still inside the
AS (i.e., an inter-area route). Type 3
advertisements describe routes to
networks. Type 4 advertisements
describe routes to AS boundary routers.
____________________________________________________________________________
5 AS external Originated by AS boundary routers, and
link advs. flooded throughout the AS. Each external
advertisement describes a route to a
destination in another Autonomous
System. Default routes for the AS can
also be described by AS external advertisements.
Table 9: OSPF link state advertisements.Remember, OSPF routing packets (except Hellos) only go over adjacencies 🛣️ So every protocol packet travels a single IP hop, EXCEPT the ones sent over virtual adjacencies 🦄 The IP source address is one end of a router adjacency, and the IP destination is either the other end of that adjacency or an IP multicast address 🎯
4.4 Basic implementation requirements
To run OSPF, an implementation needs these pieces of system support 🧰
Timers
Two kinds of timers are REQUIRED 🔔 The first kind, single shot timers, fire once and kick off a protocol event 💥 The second kind, interval timers, fire at continuous intervals 🔁 Those are for sending packets on a regular schedule, like the regular broadcast of Hello packets on broadcast networks 📢 The granularity of BOTH kinds is one second ⏱️
Interval timers SHOULD be implemented to avoid drift 🌀 Some routers have packet processing that can mess with timer execution 😵💫 When multiple routers are attached to one network and ALL are broadcasting, this can cause synchronization of routing packets, which SHOULD be avoided 🙅♀️ If timers can't be implemented to avoid drift, small random amounts SHOULD be added to or subtracted from the timer interval at each firing 🎲
IP multicast
Certain OSPF packets use IP multicast 📡 Support for receiving and sending IP multicasts, along with the right lower-level protocol support, is REQUIRED 🫶 These IP multicast packets NEVER travel more than one hop 🛑 For more on IP multicast, see [RFC 1112] 📚
Lower-level protocol support
The lower-level protocols here are the network access protocols, like the Ethernet data link layer 🔌 Indications MUST be passed from these protocols up to OSPF whenever the network interface goes up and down ⬆️⬇️ For example, on an ethernet, it'd be super valuable to know when the transceiver cable gets unplugged 🔌😱
Okay so the Non-broadcast lower-level protocol support bit is about multi-access networks like an X.25 PDN 🌐 Remember those are non-broadcast networks, so the Hello Protocol can get a helping hand if OSPF is told when someone tries to send a packet to a dead or non-existent router 💀 On a PDN, a dead router might show up as a X.25 clear with an appropriate cause and diagnostic, and that info gets passed to OSPF 🦋
List manipulation primitives are giving main character energy 📜 A lot of OSPF is described in terms of operating on lists of link state advertisements. For example, the advertisements that get retransmitted to an adjacent router until it acknowledges them are described as a list 🔁 Any one advertisement can sit on lots of these lists, so an OSPF implementation needs to be able to manipulate them, adding and deleting advertisements as necessary 💅
Tasking support is so important ✨ Some procedures call other procedures. Sometimes those should run in-line, meaning before the current procedure is finished. The text marks this with instructions to execute a procedure ⚡ Other times, the other procedures only run once the current procedure has finished, and that's marked with instructions to schedule a task 🗓️
4.5 Optional OSPF capabilities ✨
OSPF defines several optional capabilities, and it's honestly iconic 🎀 A router shows which ones it supports in its OSPF Hello packets, its Database Description packets, and its link state advertisements. This lets routers with a mix of optional capabilities coexist in a single Autonomous System 🫶
Some capabilities must be supported by all routers attached to a specific area. In that case, a router will not accept a neighbor's Hello unless there is a match in reported capabilities. A capability mismatch prevents a neighbor relationship from forming 🚫 The external routing capability (see below) is an example of this.
Other capabilities can be negotiated during the database synchronization process. This happens by specifying the optional capabilities in Database Description packets. If there's a capability mismatch with a neighbor in this case, only a subset of link state advertisements gets exchanged between the two neighbors 🔄
The routing table build process can also be affected by whether optional capabilities are present or absent. Since optional capabilities are reported in link state advertisements, routers that are incapable of certain functions can be avoided when building the shortest path tree 🌳 The TOS routing capability (see below) is an example of this.
The current OSPF optional capabilities are listed below. See Section A.2 for more information 📖
External routing capability Entire OSPF areas can be configured as "stubs" (see Section 3.6). AS external advertisements will not be flooded into stub areas 🛑 This capability is represented by the E-bit in the OSPF options field (see Section A.2). To make sure stub areas are configured consistently, all routers interfacing to such an area must have the E-bit clear in their Hello packets (see Sections 9.5 and 10.5) 💖
TOS capability All OSPF implementations must be able to calculate separate routes based on IP Type of Service. But to save routing table space and processing resources, an OSPF router can be configured to ignore TOS when forwarding packets 🧠 In that case, the router calculates routes for TOS 0 only. This capability is represented by the T-bit in the OSPF options field (see Section A.2). TOS-capable routers will attempt to avoid non-TOS-capable routers when calculating non-zero TOS paths 🦄
5. Protocol Data Structures 🧩
OSPF is described in this specification in terms of its operation on various protocol data structures. The list below comprises the top-level OSPF data structures. Any initialization that needs to be done is noted. Areas, OSPF interfaces and neighbors also have associated data structures, which get described later in this specification 📋
Router ID A 32-bit number that uniquely identifies this router in the AS. One possible implementation strategy is to use the smallest IP interface address belonging to the router 🆔
Pointers to area structures Each one of the areas the router is connected to has its own data structure. This data structure describes the working of the basic algorithm. Remember that each area runs a separate copy of the basic algorithm 🔁
Pointer to the backbone structure The basic algorithm operates on the backbone as if it were an area, so the backbone is represented as an area structure 🦴
Virtual links configured The virtual links configured with this router as one endpoint. To have configured virtual links, the router itself must be an area border router. Virtual links are identified by the Router ID of the other endpoint, which is another area border router. These two endpoint routers must be attached to a common area, called the virtual link's transit area 🚇 Virtual links are part of the backbone and behave as if they were unnumbered point-to-point networks between the two routers. A virtual link uses the intra-area routing of its transit area to forward packets. Virtual links are brought up and down through the building of the shortest-path trees for the transit area 🌉
List of external routes These are routes to destinations external to the Autonomous System. They've been gained either through direct experience with another routing protocol (such as EGP), through configuration information, or through a combination of the two (e.g., dynamic external info to be advertised by OSPF with configured metric) 🌍 Any router having these external routes is called an AS boundary router. These routes are advertised by the router to the entire AS through AS external link advertisements 📣
List of AS external link advertisements Part of the topological database. These have originated from the AS boundary routers, and they comprise routes to destinations external to the Autonomous System. Note that if the router is itself an AS boundary router, some of these AS external link advertisements have been self originated 🪞
The routing table Derived from the topological database. Each destination that the router can forward to is represented by a cost and a set of paths. A path is described by its type and next hop. For more information, see Section 11 🗺️
TOS capability This item indicates whether the router will calculate separate routes based on TOS. It's a configurable parameter. For more information, see Sections 4.5 and 16.9 ⚙️
Figure 9 shows the collection of data structures present in a typical router. The router pictured is RT10, from the map in Figure 6. Router RT10 has a virtual link configured to router RT11, with Area 2 as the link's transit area. This is indicated by the dashed line in Figure 9. When the virtual link becomes active, through the building of the shortest path tree for Area 2, it becomes an interface to the backbone (see the two backbone interfaces depicted in Figure 9) 🎨
6. The Area Data Structure 🏡
The area data structure contains all the information used to run the basic routing algorithm. Remember that each area maintains its own topological database. Router interfaces and adjacencies belong to a
_______________________________________
(Figure not included in text version.)
Figure 9: Router RT10's Data Structures
_______________________________________single area.
The backbone has all the properties of an area, so it's also represented by an area data structure. Some items in the structure apply differently to the backbone than to areas 🦋
The area topological (or link state) database consists of the collection of router links, network links and summary links advertisements that have originated from the area's routers. This information is flooded throughout a single area only. The list of AS external advertisements is also considered part of each area's topological database 🌊
Area ID A 32-bit number identifying the area. 0 is reserved for the area ID of the backbone. If assigning subnetted networks as separate areas, the IP network number could be used as the Area ID 🪪
List of component address ranges The address ranges that define the area. Each address range is specified by an [address,mask] pair. Each network is then assigned to an area depending on the address range that it falls into (specified address ranges are not allowed to overlap). As an example, if an IP subnetted network is to be its own separate OSPF area, the area is defined to consist of a single address range: an IP network number with its natural (class A, B or C) mask 🧁
Associated router interfaces This router's interfaces connecting to the area. A router interface belongs to one and only one area (or the backbone). For the backbone structure, this list includes all the virtual adjacencies. A virtual adjacency is identified by the router ID of its other endpoint, and its cost is the cost of the shortest intra-area path that exists between the two routers 🔌
List of router links advertisements A router links advertisement is generated by each router in the area. It describes the state of the router's interfaces to the area 📡
List of network links advertisements One network links advertisement is generated for each transit multi-access network in the area. It describes the set of routers currently connected to the network 🕸️
List of summary links advertisements Summary link advertisements originate from the area's area border routers. They describe routes to destinations internal to the Autonomous System, yet external to the area 🧾
Shortest-path tree The shortest-path tree for the area, with this router itself as root. It's derived from the collected router links and network links advertisements by the Dijkstra algorithm 🌲
Authentication type The type of authentication used for this area. Authentication types are defined in Appendix E. All OSPF packet exchanges are authenticated, and different authentication schemes may be used in different areas 🔐
External routing capability Whether AS external advertisements will be flooded into or throughout the area. This is a configurable parameter. If AS external advertisements are excluded from the area, the area is called a "stub". Internal to stub areas, routing to external destinations will be based solely on a default summary route. The backbone cannot be configured as a stub area. Also, virtual links cannot be configured through stub areas. For more information, see Section 3.6 🚧
StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default summary link that the router should advertise into the area. There can be a separate cost configured for each IP TOS. See Section 12.4.3 for more information 💸
Unless otherwise specified, the remaining sections of this document refer to the operation of the protocol in a single area 🎯
7. Bringing Up Adjacencies 🤝
OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. Okay, so not every two neighboring routers will
become adjacent. okay so this section is the generalities tea ☕ it covers the basics of making adjacencies. for the full scoop go to Section 10 🫶
7.1 The Hello Protocol 👋
the Hello Protocol is responsible for establishing and maintaining neighbor relationships 💖 it also makes sure communication between neighbors is bidirectional ✨ Hello packets get sent periodically out all router interfaces 🦋 bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet 🙈
on multi-access networks, the Hello Protocol elects a Designated Router for the network 👑 among other things, the Designated Router controls what adjacencies will be formed over the network (see below) 💅
the Hello Protocol works differently on broadcast networks vs non-broadcast networks, ngl 🌈 on broadcast networks, each router advertises itself by periodically multicasting Hello Packets 📣 this lets neighbors get discovered dynamically 🧚 these Hello Packets contain the router's view of the Designated Router's identity, and the list of routers whose Hellos have been seen recently 🍓
on non-broadcast networks, some configuration info is necessary for the Hello Protocol to work 😭 each router that may potentially become Designated Router has a list of all other routers attached to the network 📋 a router with Designated Router potential sends hellos to all other potential Designated Routers when its interface to the non-broadcast network first becomes operational 🌸 this is an attempt to find the Designated Router for the network 🔍 if the router itself is elected Designated Router, it begins sending hellos to all other routers attached to the network 👑
after a neighbor has been discovered, bidirectional communication is ensured, and (if on a multi-access network) a Designated Router elected, a decision is made about whether or not an adjacency should be formed with the neighbor (see Section 10.4) 🤔 an attempt is always made to establish adjacencies over point-to-point networks and virtual links 💜 the first step in bringing up an adjacency is to synchronize the neighbors' topological databases 🧠 that's up next 👀
7.2 The Synchronization of Databases 🔄
in an SPF-based routing algorithm, it is very important for all routers' topological databases to stay synchronized 💕 OSPF simplifies this by requiring only adjacent routers to remain synchronized ✨ the synchronization process begins as soon as the routers attempt to bring up the adjacency 🚀 each router describes its database by sending a sequence of Database Description packets to its neighbor 📦 each Database Description Packet describes a set of link state advertisements belonging to the database 🗂️ when the neighbor sees a link state advertisement that is more recent than its own database copy, it makes a note that this newer advertisement should be requested 📝
this sending and receiving of Database Description packets is called the "Database Exchange Process" 🎀 during this process, the two routers form a master/slave relationship 👑🙇 each Database Description Packet has a sequence number 🔢 Database Description Packets sent by the master (polls) are acknowledged by the slave through echoing of the sequence number 🫶 both polls and their responses contain summaries of link state data 📊 the master is the only one allowed to retransmit Database Description Packets 🫡 it does so only at fixed intervals, the length of which is the configured constant RxmtInterval ⏰
each Database Description contains an indication that there are more packets to follow --- the M-bit 🚩 the Database Exchange Process is over when a router has received and sent Database Description Packets with the M-bit off 🏁
during and after the Database Exchange Process, each router has a list of those link state advertisements for which the neighbor has more up-to-date instances 📜 these advertisements are requested in Link State Request Packets 🙋 Link State Request packets that are not satisfied are retransmitted at fixed intervals of time RxmtInterval 🔁 when the Database Description Process has completed and all Link State Requests have been satisfied, the databases are deemed synchronized and the routers are marked fully adjacent 🎉 at this time the adjacency is fully functional and is advertised in the two routers' link state advertisements 📣
the adjacency is used by the flooding procedure as soon as the Database Exchange Process begins 🌊 this simplifies database synchronization, and guarantees that it finishes in a predictable period of time 💯
7.3 The Designated Router 👑
every multi-access network has a Designated Router 🏠 the Designated Router performs two main functions for the routing protocol:
- the Designated Router originates a network links advertisement on behalf of the network 🌐 this advertisement lists the set of routers (including the Designated Router itself) currently attached to the network 📋 the Link State ID for this advertisement (see Section 12.1.4) is the IP interface address of the Designated Router 🪪 the IP network number can then be obtained by using the subnet/network mask 🧮
- the Designated Router becomes adjacent to all other routers on the network 🤝 since the link state databases are synchronized across adjacencies (through adjacency bring-up and then the flooding procedure), the Designated Router plays a central part in the synchronization process 💫
the Designated Router is elected by the Hello Protocol 🗳️ a router's Hello Packet contains its Router Priority, which is configurable on a per-interface basis ⚙️ in general, when a router's interface to a network first becomes functional, it checks to see whether there is currently a Designated Router for the network 🔎 if there is, it accepts that Designated Router, regardless of its Router Priority 🤷♀️ (this makes it harder to predict the identity of the Designated Router, but ensures that the Designated Router changes less often. See below.) otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network 🥇 a more detailed (and more accurate) description of Designated Router election is presented in Section 9.4 📖
the Designated Router is the endpoint of many adjacencies 🎯 in order to optimize the flooding procedure on broadcast networks, the Designated Router multicasts its Link State Update Packets to the address AllSPFRouters, rather than sending separate packets over each adjacency 📡
Section 2 of this document discusses the directed graph representation of an area 🗺️ router nodes are labelled with their Router ID 🏷️ broadcast network nodes are actually labelled with the IP address of their Designated Router 🪧 it follows that when the Designated Router changes, it appears as if the network node on the graph is replaced by an entirely new node 🫠 this will cause the network and all its attached routers to originate new link state advertisements 🔄 until the topological databases again converge, some temporary loss of connectivity may result 💔 this may result in ICMP unreachable messages being sent in response to data traffic 🙈
for that reason, the Designated Router should change only infrequently 🛑 Router Priorities should be configured so that the most dependable router on a network eventually becomes Designated Router 🏆
7.4 The Backup Designated Router 🛟
in order to make the transition to a new Designated Router smoother, there is a Backup Designated Router for each multi-access network 🫂 the Backup Designated Router is also adjacent to all routers on the network, and becomes Designated Router when the previous Designated Router fails 🦸 if there were no Backup Designated Router, when a new Designated Router became necessary, new adjacencies would have to be formed between the router and all other routers attached to the network 😩 part of the adjacency forming process is the synchronizing of topological databases, which can potentially take quite a long time ⏳ during this time, the network would not be available for transit data traffic 🚫 the Backup Designated obviates the need to form these adjacencies, since they already exist 🙌 this means the period of disruption in transit traffic lasts only as long as it takes to flood the new link state advertisements (which announce the new Designated Router) 🌊
the Backup Designated Router does not generate a network links advertisement for the network 🙅♀️ (if it did, the transition to a new Designated Router would be even faster 🏎️ however, this is a tradeoff between database size and speed of convergence when the Designated Router disappears ⚖️)
the Backup Designated Router is also elected by the Hello Protocol 🗳️ each Hello Packet has a field that specifies the Backup Designated Router for the network 🏷️
in some steps of the flooding procedure, the Backup Designated Router plays a passive role, letting the Designated Router do more of the work 😌 this cuts down on the amount of local routing traffic 📉 see Section 13.3 for more information 📚
7.5 The graph of adjacencies 🕸️
an adjacency is bound to the network that the two routers have in common 🔗 if two routers have multiple networks in common, they may have multiple adjacencies between them 👯
one can picture the collection of adjacencies on a network as forming an undirected graph 🎨 the vertices consist of routers, with an edge joining two routers if they are adjacent 🫧 the graph of adjacencies describes the flow of routing protocol packets, and in particular Link State Updates, through the Autonomous System 🛣️
two graphs are possible, depending on whether the common network is multi-access 🤔 on physical point-to-point networks (and virtual links), the two routers joined by the network will be adjacent after their databases have been synchronized 🤝 on multi-access networks, both the Designated Router and the Backup Designated Router are adjacent to all other routers attached to the network, and these account for all adjacencies 🎀
these graphs are shown in Figure 10 🖼️ it is assumed that router RT7 has become the Designated Router, and router RT3 the Backup Designated Router, for the network N2 💁 the Backup Designated Router performs a lesser function during the flooding procedure than the Designated Router (see Section 13.3) 🫣 this is the reason for the dashed lines connecting the Backup Designated Router RT3 🌟
8. Protocol Packet Processing 📦
this section discusses the general processing of routing protocol packets 🧾 it is very important that the router topological databases remain synchronized 💗 for this reason, routing protocol packets should get preferential treatment over ordinary data packets, both in sending and receiving 🚦
routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies) 🔍 this means that all protocol packets travel a single IP hop, except those sent over virtual links 🛤️
all routing protocol packets begin with a standard header 🎁 the sections below give the details on how to fill in and verify this standard header 🔧 then, for each packet type, the section is listed that gives more details on that particular packet type's processing 📑
8.1 Sending protocol packets 📤
when a router sends a routing protocol packet, it fills in the fields of that standard header as follows 📝 for more details on the header format consult Section A.3.1 📖
- Version #: set to
2, the version number of the protocol as documented in this specification ✨ - Packet type: the type of OSPF packet, such as Link state Update or Hello Packet 📮
- Packet length: the length of the entire OSPF packet in bytes, including the standard header 📏
Router ID 🆔✨ okay bestie, this is the router's own identity, so it's basically the sender's name tag. It's whoever is originating the packet 💅
Area ID 🗺️ this one tells you which area the packet is being sent into 🌸
Checksum 🧮 it's the standard IP 16-bit one's complement checksum over the whole OSPF packet, but you LEAVE OUT the 64-bit authentication field 🙈 And the checksum SHOULD be calculated before the packet goes to the authentication procedure, because the order matters 💜
Autype and Authentication 🔐 every OSPF packet exchange gets authenticated, no exceptions 🫶 The auth types are assigned by the protocol and listed in Appendix E. Each OSPF area can use a different scheme, which is lowkey iconic. The 64-bit authentication field gets filled in by whichever procedure matches the Autype. That procedure SHOULD be the very last thing called when you're forming the packet. The value depends on the packet contents plus the authentication key, which you can set per interface 🎀
Okay so, where the packet actually goes 📬 On physical point-to-point networks, the IP destination is always AllSPFRouters, no thinking required 👑 On every other network type (virtual links included), most OSPF packets are unicast, meaning they go straight to the other end of the adjacency 🦋 For those, the IP destination is just the neighbor's IP address for that adjacency (see Section 10). The ONLY packets that aren't unicast are on broadcast networks 😭 There, Hello packets go to the multicast address AllSPFRouters. The Designated Router and its Backup send both Link State Update Packets and Link State Acknowledgment Packets to AllSPFRouters. Everyone else sends their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters 🧚
Retransmissions of Link State Update packets are ALWAYS unicast, no exceptions, periodt 💀🔥
Now the IP source address 🌈 It SHOULD be set to the IP address of the sending interface. Interfaces on unnumbered point-to-point networks don't have an IP address, so on those the IP source SHOULD be set to any other IP address that belongs to the router. That's why there MUST be at least one IP address assigned to the router 💖 Also, virtual links act basically the same as unnumbered point-to-point networks, mostly. The difference is each virtual link DOES have an interface IP address, which gets discovered while the routing table is being built, and that's the one used as the source for packets sent over the virtual link ✨
For more details on each packet type's format, check the sections in Table 10 🎀
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5
Table 10: Sections describing packet transmission.8.2 Receiving protocol packets 📥💜
When a router gets a protocol packet, it tags it with the interface it arrived on 🏷️ Here's the tricky part: if you've got virtual links configured, it's not always obvious which interface a packet belongs to 🥺 Say RT11 (from Figure 6) gets an OSPF packet on its interface to network N8. It could associate that packet with the interface to area 2, OR with the virtual link to RT10, which is part of the backbone. For the rest of this section, we're assuming the packet starts out associated with the non-virtual link 🫣[3]
Before OSPF even looks at the packet, it has to get past some IP-level checks. Think of it as the bouncer at the door 🚪 The packet:
- MUST have a correct IP checksum.
- MUST have an IP destination address that's either the IP address of the receiving interface, or one of the IP multicast addresses
AllSPFRoutersorAllDRouters. - MUST specify OSPF (
89) as its IP protocol. - SHOULD NOT be passed on to OSPF if it was locally originated. In other words, check the source IP address to make sure it's not a multicast packet the router itself made, because that would be awkward 🙃
Next up, the OSPF header gets verified 🔍 The fields in the header MUST match what's configured for the receiving interface. If they don't match, the packet SHOULD be discarded 💅
- The version number field MUST specify protocol version 2 ✨
- The 16-bit checksum of the OSPF packet's contents MUST be verified 🧮 Remember, the 64-bit authentication field MUST be excluded from that checksum calculation 🙈
- The Area ID in the OSPF header MUST be verified 🗺️ If both of the following cases fail, the packet SHOULD be discarded. The Area ID in the header MUST either:
- (1) Match the Area ID of the receiving interface. This means the packet came over a single hop, so the packet's IP source address MUST be on the same network as the receiving interface. To check, mask both the packet's IP source address and the interface's IP address with the interface mask, then compare the results 🔎
- (2) Indicate the backbone. This means the packet came over a virtual link 🌉 The receiving router MUST be an area border router, and the router ID in the packet (the source router) MUST be the other end of a configured virtual link. The receiving interface MUST also attach to the virtual link's configured transit area. If all of these checks pass, the packet is accepted and from then on it's associated with the virtual link (and the backbone area) 👑
- Packets whose IP destination is
AllDRoutersSHOULD only be accepted if the receiving interface is in the DR or Backup state (see Section 9.1) 🫶 - The Authentication type in the packet MUST match the authentication type specified for the associated area 🔐
Then the packet has to be authenticated 🔐 Which method you use depends on the authentication type (see Appendix E). The procedure might use an Authentication key, which you can configure per interface. If authentication fails, the packet SHOULD be discarded 💀
If the packet is a Hello, it SHOULD then go through the Hello Protocol (see Section 10.5) 💖 Every other packet type only gets sent and received over adjacencies, so the packet MUST have come from one of the router's active neighbors 🫂 On a multi-access network (broadcast or non-broadcast), the sender is identified by the IP source address in the IP header. On a point-to-point link or a virtual link, the sender is identified by the Router ID (source router) in the OSPF header 🆔 The interface's data structure keeps the list of active neighbors, and any packet that doesn't match an active neighbor is discarded 🗑️
At this point, every received protocol packet is tied to an active neighbor 🎀 For the rest of the input processing on each packet type, check the sections in Table 11 🌸
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7
Table 11: Sections describing packet reception.9. The Interface Data Structure 🧩🦋
An OSPF interface is the connection between a router and a network 🔌 Each attached network gets exactly one OSPF interface structure, and each one holds at most one IP interface address (more on that below). Supporting multiple addresses on a single network is something for the future 🔮
An OSPF interface can be considered part of the area that holds the attached network 🏡 Every routing protocol packet the router originates over this interface gets labelled with the interface's Area ID. One or more router adjacencies may form over an interface, and the router's link state advertisements reflect the state of its interfaces and their adjacencies 💜
Here are the data items associated with an interface. A bunch of these are really configuration for the attached network, and those items MUST be the same for all routers connected to that network 🤝
Type 🛣️ The kind of network the interface attaches to. Its value is broadcast, non-broadcast yet still multi-access, point-to-point, or virtual link 🌈
State 🚦 The functional level of an interface. State decides whether full adjacencies are allowed to form over the interface, and it's also reflected in the router's link state advertisements 👑
IP interface address 📍 The IP address for the interface. It shows up as the IP source address in every routing protocol packet originated over this interface. Interfaces on unnumbered point-to-point networks don't have one 🙃
IP interface mask 🎭 This shows which part of the IP interface address identifies the attached network. People often call it the subnet mask. Masking the IP interface address with this value gives you the IP network number of the attached network ✨
Area ID 🗺️ The Area ID the attached network belongs to. Every routing protocol packet coming from the interface gets labelled with this Area ID 🎀
HelloInterval ⏱️ How long, in seconds, between the Hello packets the router sends on the interface. It's advertised in Hello packets sent out this interface 📣
RouterDeadInterval 💀 The number of seconds before the router's neighbors declare it down, once they stop hearing its hellos. It's advertised in Hello packets sent out this interface 📢
InfTransDelay 🚚 The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. The link state advertisements in the update packet get their age increased by this amount before transmission. This value SHOULD take into account both transmission and propagation delays, and it MUST be greater than zero 💅
Router Priority 👑 An 8-bit unsigned integer. When two routers on a network both try to become Designated Router, the one with the highest Router Priority wins 🏆 A router whose Router Priority is set to 0 is ineligible to become Designated Router on that network 🙅 It's advertised in Hello packets sent out this interface 📣
Hello Timer ⏰ An interval timer that makes the interface send a Hello packet. It fires every HelloInterval seconds. Note that on non-broadcast networks, a separate Hello packet goes to each qualified neighbor 💌
Wait Timer ⏳ A single-shot timer that makes the interface leave the Waiting state. As a result, the interface selects a Designated Router on the network. The timer runs for RouterDeadInterval seconds 🫠
List of neighboring routers 💬 okay so this is the other routers attached to this network. On multi-access networks, the Hello Protocol builds this list. Adjacencies will form with some of these neighbors, and you can figure out which ones by checking every neighbor's state. 🫶
Designated Router 👑 the Designated Router is picked for the attached network, and on all multi-access networks the Hello Protocol does the picking. We keep two pieces of ID for it: its Router ID and its interface IP address on the network. The DR advertises link state for the network, and that network link state advertisement gets labelled with the DR's IP address. This item starts at 0, which means there's no Designated Router yet. 🌸
Backup Designated Router 🦋 the BDR also gets chosen on every multi-access network by the Hello Protocol. Every router on the attached network becomes adjacent to both the DR and the BDR. When the current DR fails, the BDR steps up and becomes the DR. It's initialized to 0, which means there's no Backup Designated Router. ✨
Interface output cost(s) 💅 this is the cost of sending a packet out the interface, expressed in the link state metric. It gets advertised as the link cost for this interface in the router links advertisement. There can be a separate cost for each IP Type of Service. The cost of an interface must be greater than zero. 🔥
RxmtInterval 🧚 this is the number of seconds between link state advertisement retransmissions, for adjacencies on this interface. It's also used when retransmitting Database Description and Link State Request Packets. 🍓
Authentication key 🔐 this is configured data that lets the authentication procedure generate and/or verify the authentication field in the OSPF header. The key can be configured per interface. For example, if the authentication type is simple password, the authentication key would be a 64-bit password. That key gets inserted directly into the OSPF header when routing protocol packets are originated, and there could be a separate password for each network. iykyk 💜
9.1 Interface states
The various states a router interface may attain are documented in this section, and they're listed in order of progressing functionality. So the inoperative state comes first, followed by the intermediate states, and then the final, fully functional state. The spec uses this ordering when it says things like "those interfaces in state greater than X". It's giving organized 🎀
Figure 11 shows the graph of interface state changes. The arcs are labelled with the event causing each state change, and those events are documented in Section 9.2. The interface state machine gets more detail in Section 9.3. 🌈
Down
This is the initial interface state. Here, the lower-level protocols have said the interface is unusable, so no protocol traffic at all gets sent or received on it. Interface parameters should be set to their initial values, all interface timers should be disabled, and there should be no adjacencies associated with the interface. Very quiet, very cozy 🙈
Loopback
In this state, the router's interface to the network is looped back. That loop can happen in hardware or in software. The interface is unavailable for regular data traffic, but it may still be useful to learn about the quality of this interface, like by sending ICMP pings to it or running something like a bit error test. That's why IP packets may still be addressed to an interface in Loopback state. To make that work, these interfaces get advertised in router links advertisements as single host routes, whose destination is the IP interface address.[4] main character energy 🦋
Waiting
In this state, the router is trying to figure out who the Backup Designated Router is for the network. To do that, it watches the Hellos it receives. The router isn't allowed to elect a Backup Designated Router or a Designated Router until it transitions out of Waiting state. This stops unnecessary changes of the (Backup) Designated Router. Patience is a whole vibe ⏳✨
Point-to-point
In this state, the interface is operational and connects either to a physical point-to-point network or to a virtual link. As soon as the router enters this state, it tries to form an adjacency with the neighboring router, and it sends Hellos to that neighbor every HelloInterval seconds. 💖
DR Other
The interface is attached to a multi-access network where another router has been selected as the Designated Router. The router itself hasn't been selected as the Backup Designated Router either. It forms adjacencies to both the Designated Router and the Backup Designated Router (if they exist). Supporting cast energy 🫶
Backup
Here the router itself is the Backup Designated Router on the attached network. It gets promoted to Designated Router when the present DR fails. It establishes adjacencies to all the other routers on the network. The BDR does slightly different things during the Flooding Procedure than the DR does (see Section 13.3), and Section 7.4 has more on what the Backup Designated Router does. ✨
DR
In this state, this router itself is the Designated Router on the attached network. Adjacencies get established to all the other routers on the network. The router must also originate a network links advertisement for the network node, and that advertisement contains links to all routers attached to the network, including the DR itself. See Section 7.3 for more on what the Designated Router does. She's the one in charge 👑💅
9.2 Events causing interface state changes
State changes can happen for a bunch of different reasons. These events are pictured as the labelled arcs in Figure 11, and the label definitions are listed below. If you want the detailed effect of each event on OSPF protocol operation, check out Section 9.3. 🦋
Interface Up
Lower-level protocols have said the network interface is operational. This lets the interface transition out of Down state. On virtual links, the interface operational indication actually comes from the shortest path calculation (see Section 16.7). 🌸
Wait Timer
The Wait timer has fired, which means the waiting period is over. That waiting period is required before electing a (Backup) Designated Router. ⏰
Backup seen
The router has detected whether a Backup Designated Router exists for the network, or whether one doesn't. There are two ways this happens. First, a Hello Packet may come in from a neighbor claiming to be the Backup Designated Router itself. Or second, a Hello Packet may come in from a neighbor claiming to be the Designated Router and indicating there's no Backup. Either way, there must be bidirectional communication with the neighbor, meaning the router must also appear in the neighbor's Hello Packet. This event signals the end of the Waiting state. 🎉
Neighbor Change
There's been a change in the set of bidirectional neighbors associated with the interface, so the (Backup) Designated Router needs to be recalculated. These neighbor changes all lead to the Neighbor Change event. For an explanation of neighbor states, see Section 10.1.
- Bidirectional communication has been established to a neighbor. In other words, the neighbor's state has transitioned to 2-Way or higher. 💜
- There is no longer bidirectional communication with a neighbor. In other words, the neighbor's state has transitioned to Init or lower. 💔
- One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This gets detected by examining that neighbor's Hello Packets. 👀
- One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. Again, this gets detected by examining that neighbor's Hello Packets. 🙃
- The advertised Router Priority for a bidirectional neighbor has changed. Yep, detected by examining that neighbor's Hello Packets too. 🍓
Loop Ind
An indication has come in that the interface is now looped back to itself. This indication can arrive either from network management or from the lower level protocols. 🔁
Unloop Ind
An indication has come in that the interface is no longer looped back. Just like the Loop Ind event, this can come either from network management or from the lower level protocols. 🌤️
Interface Down
The lower-level protocols indicate this interface is no longer functional. No matter what the current interface state is, the new interface state will be Down. Bye bye 💀
9.3 The Interface state machine
Here's the detailed rundown of interface state changes. Each state change is invoked by an event (Section 9.2), and the same event can produce different effects depending on the interface's current state. That's why this state machine is organized by current interface state and received event. Each entry describes the resulting new interface state and the required set of additional actions. 🧠💖
When an interface's state changes, it may be necessary to originate a new router links advertisement. See Section 12.4 for more details.
Some of the required actions below involve generating events for the neighbor state machine. For example, when an interface becomes inoperative, all neighbor connections associated with the interface must be destroyed. For more on the neighbor state machine, see Section 10.3. 🫧
State(s): Down
Event: Interface Up
New state: Depends on action routine
Action: Start the interval Hello Timer, enabling the periodic sending of Hello packets out the interface. If the attached network is a physical point-to-point network or virtual link, the interface state transitions to Point-to-Point. Else, if the router is not eligible to become Designated Router, the interface state transitions to DR other.
Otherwise, the attached network is multi-access and the router is eligible to become Designated Router. In this case, to try to discover the attached network's Designated Router, the interface state is set to Waiting and the single shot Wait Timer is started. If in addition the attached network is non-broadcast, examine the configured list of neighbors for this interface and generate the neighbor event Start for each neighbor that is also eligible to become Designated Router. ✨🚀
State(s): Waiting
Event: Backup Seen
New state: Depends upon action routine.
Action: Calculate the attached network's Backup Designated Router and Designated Router, as shown in Section 9.4. As a result of this calculation, the new state of the interface will be either DR other, Backup or DR. 🎀
State(s): Waiting
Event: Wait Timer
New state: Depends upon action routine.
Action: okay so this one is basically the router going "wait, who's the DR now?" 👀 Recalculate the attached network's Backup Designated Router and Designated Router, as shown in Section 9.4. After the math, the interface ends up as either DR other, Backup or DR. 💅
State(s): DR Other, Backup or DR
Event: Neighbor Change
New state: Depends upon action routine.
Action: same vibe as before, bestie. Recalculate the attached network's Backup Designated Router and Designated Router, as shown in Section 9.4. The new interface state will be either DR other, Backup or DR. 🦋
State(s): Any State
Event: Interface Down
New state: Down
Action: this is the full reset era 🫠 All interface variables get reset and the interface timers get disabled. All neighbor connections tied to the interface are destroyed too, by generating the event KillNbr on all associated neighbors (see Section 10.2). Gone, no cap. 💀
State(s): Any State
Event: Loop Ind
New state: Loopback
Action: the interface isn't connected to the attached network anymore, so the actions for the Interface Down event above get run. Main character energy but make it loopback 🔁
State(s): Loopback
Event: Unloop Ind
New state: Down
Action: no actions are necessary here 🧚 The interface variables were already reset when it entered the Loopback state. Also, the interface needs to receive an Interface Up event before it's fully functional again, so don't forget that part, periodt. 🌸
9.4 Electing the Designated Router ✨
okay so this section is the algorithm that works out a network's Designated Router and Backup Designated Router. 👑 The Interface state machine is the one that calls it. The very first time a router runs the election for a network, the network's Designated Router and Backup Designated Router both get set to 0.0.0.0, which just means "we have neither one yet" 🫶
Here's how the election goes. The router doing the calculation is called Router X. Next, look at the list of neighbors attached to the network that have established bidirectional communication with Router X. This list is exactly the collection of Router X's neighbors on this network whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself goes on the list too. Then discard every router on the list that is ineligible to become Designated Router. (Routers with a Router Priority of 0 are ineligible.) After that, run the following steps, looking only at the routers still left on the list. 💖
(1) Note the current values for the network's Designated Router and Backup Designated Router. You'll compare against these later. 📝
(2) Calculate the new Backup Designated Router. Only routers on the list that haven't declared themselves Designated Router are eligible. If one or more of them have declared themselves Backup Designated Router (meaning they list themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets), the one with the highest Router Priority is declared Backup Designated Router. If there's a tie, the one with the highest Router ID wins. If no routers have declared themselves Backup Designated Router, pick the router with the highest Router Priority (again leaving out anyone who has declared themselves Designated Router), and use the Router ID to break ties. 🎀
(3) Calculate the new Designated Router. If one or more routers have declared themselves Designated Router (they list themselves as Designated Router in their Hello Packets), the one with the highest Router Priority is declared Designated Router. Ties go to the highest Router ID. If no routers have declared themselves Designated Router, the new Backup Designated Router gets promoted to Designated Router. 🔥
(4) If Router X is now newly the Designated Router or newly the Backup Designated Router, or is now no longer the Designated Router or no longer the Backup Designated Router, repeat steps 2 and 3, then go on to step 5. For example, if Router X is now the Designated Router, then when step 2 is repeated, X is no longer eligible for Backup Designated Router election. Among other things, this makes sure no router ends up declaring itself both Backup Designated Router and Designated Router.[5] That's a whole vibe 😭
(5) Because of all this math, the router itself may now be the Designated Router or Backup Designated Router. See Sections 7.3 and 7.4 for the extra duties that come with that. The router's interface state should be set to match. If the router itself is now Designated Router, the new interface state is DR. If it's now Backup Designated Router, the new interface state is Backup. Otherwise, the new interface state is DR Other. ✨
(6) If the attached network is non-broadcast, and the router has just become either Designated Router or Backup Designated Router, it must start sending hellos to the neighbors that aren't eligible to become Designated Router (see Section 9.5.1). To do this, invoke the neighbor event Start for each neighbor with a Router Priority of 0. 🧚
(7) If the calculations above changed the identity of either the Designated Router or the Backup Designated Router, the set of adjacencies on this interface needs updating. Some adjacencies might need to form, and others might need to break. To handle that, invoke the event AdjOK? on all neighbors whose state is at least 2-Way. That makes them re-check their eligibility for adjacency (see Sections 10.3 and 10.4). 🫧
The reason this election is so complicated is that the designers wanted an orderly handoff from Backup Designated Router to Designated Router when the current Designated Router fails. The orderly handoff is guaranteed by adding hysteresis: no new Backup router can be picked until the old Backup has accepted its new Designated Router responsibilities. Honestly, it's giving careful planning 🌈
If Router X isn't eligible to become Designated Router itself, it's possible that neither a Backup Designated Router nor a Designated Router gets selected by the procedure above. Also, if Router X is the only attached router eligible to become Designated Router, it will pick itself as Designated Router, and the network won't have a Backup Designated Router. 🙈
9.5 Sending Hello packets 💌
Hello packets get sent out of every functioning router interface. They're used to discover and maintain neighbor relationships.[6] On multi-access networks, hellos also help elect the Designated Router and Backup Designated Router, which then decides which adjacencies should form. 🫶
The format of a Hello packet is detailed in Section A.3.2. The Hello packet carries the router's Router Priority (used when choosing the Designated Router) and the interval between Hello broadcasts (HelloInterval). It also says how often a neighbor must be heard from to stay active (RouterDeadInterval). HelloInterval and RouterDeadInterval must be the same for all routers attached to a common network. The Hello packet also includes the IP address mask of the attached network (Network Mask). On unnumbered point-to-point networks and on virtual links, this field should be set to 0. 💖
The Hello packet's Options field describes the router's optional OSPF capabilities. Two optional capabilities are defined right now (see Sections 4.5 and A.2). The T-bit of the Options field should be set if the router can calculate separate routes for each IP TOS. The E-bit should be set if and only if the attached area can process AS external advertisements (in other words, it isn't a stub area). If the E-bit is set incorrectly, the neighboring routers will refuse the Hello Packet (see Section 10.5). Everything else in the Options field should be set to zero. 🎀
To make sure two adjacent routers can communicate both ways, the Hello packet includes a list of all routers whose hellos have been seen recently. It also has the router's current choice for Designated Router and Backup Designated Router. A value of 0 in these fields means one hasn't been selected yet. 🌸
On broadcast networks and physical point-to-point networks, Hello packets are sent every HelloInterval seconds to the IP multicast address AllSPFRouters. On virtual links, Hello packets go out as unicasts (addressed directly to the other end of the virtual link) every HelloInterval seconds. On non-broadcast networks, sending Hello packets is more complicated, and the next section covers it. 😭
9.5.1 Sending Hello packets on non-broadcast networks 🦋
Static configuration is needed for the Hello Protocol to work on non-broadcast networks (see Section C.5). Every attached router that is eligible to become Designated Router has a configured list of all its neighbors on the network, and each listed neighbor is labelled with its Designated Router eligibility. 📝
The interface state must be at least Waiting before any hellos get sent. Hellos are then sent directly (as unicasts) to some subset of a router's neighbors. Sometimes a hello goes out on a timer, and other times it's sent in response to a received hello. How a router sends hellos depends on whether the router itself is eligible to become Designated Router. 💅
If the router is eligible to become Designated Router, it must periodically send hellos to all neighbors that are also eligible. And if the router is itself the Designated Router or Backup Designated Router, it must also send periodic hellos to all the other neighbors. So any two eligible routers are always exchanging hellos, which is needed for the Designated Router election algorithm to work correctly. To keep the number of hellos down, the number of eligible routers on a non-broadcast network should be kept small. 🧚
If the router isn't eligible to become Designated Router, it must periodically send hellos to both the Designated Router and the Backup Designated Router (if they exist). It must also send a hello in reply to a hello received from any eligible neighbor (other than the current Designated Router and Backup Designated Router). This is what sets up an initial bidirectional relationship with any potential Designated Router. 🫶
When periodic hellos go to any neighbor, the interval between them depends on the neighbor's state. If the neighbor is in state Down, hellos go out every PollInterval seconds. Otherwise, hellos go out every HelloInterval seconds. ⏰
10. The Neighbor Data Structure 🌟
An OSPF router chats with its neighboring routers, and each separate conversation is described by a "neighbor data structure". 💬 Each conversation is bound to a particular OSPF router interface, and it's identified either by the neighboring router's OSPF router ID or by its Neighbor IP address (see below). So if the OSPF router and another router share multiple attached networks, you get multiple conversations, each described by its own unique neighbor data structure. Each separate conversation is loosely called a separate "neighbor" in the text. 👑
The neighbor data structure holds everything about the adjacency that's forming or already formed between the two neighbors. 🫶 Heads up, though: not every neighbor becomes an adjacency, so don't panic if yours doesn't! ✨ Think of an adjacency as a super deep, highly developed conversation between two routers. 💬🎀
State 💖 The functional level of the neighbor conversation. We go deeper into this in Section 10.1 🌸
Inactivity Timer ⏰ A single shot timer. It fires when no Hello Packet has been seen from this neighbor recently. Its length is RouterDeadInterval seconds 💀
Master/Slave 👑 When two neighbors are swapping databases, they form a Master Slave relationship. The Master sends the first Database Description Packet, and it's the only one allowed to retransmit 🔥 The slave can only respond to the master's Database Description Packets. This master/slave relationship gets negotiated in state ExStart 🦋
Sequence Number 🔢 A 32-bit number that identifies individual Database Description packets. When the neighbor state ExStart is entered, the sequence number should be set to a value the neighboring router hasn't seen before ✨ One possible scheme is to use the machine's time of day counter 🕰️ The master increments the sequence number with each new Database Description packet it sends. The slave's sequence number tells you the last packet it received from the master. Only one packet is allowed outstanding at a time 🙈
Neighbor ID 🪪 The OSPF Router ID of the neighboring router. You learn it when Hello packets come in from the neighbor, or it gets configured if this is a virtual adjacency (see Section C.4) 🧚
Neighbor priority 🏆 The Router Priority of the neighboring router. It's in the neighbor's Hello packets, and it's used when picking the Designated Router for the attached network 👑
Neighbor IP address 🌐 The IP address of the neighboring router's interface to the attached network. It's the Destination IP address when protocol packets get sent as unicasts along this adjacency. It's also used in router links advertisements as the Link ID for the attached network if the neighboring router gets selected as Designated Router (see Section 12.4.1) 💅 You learn the neighbor IP address when Hello packets are received from the neighbor. For virtual links, it's learned during the routing table build process (see Section 15) 🦋
Neighbor Options ⚙️ The optional OSPF capabilities the neighbor supports. These are learned during the Database Exchange process (see Section 10.6). The neighbor's optional OSPF capabilities are also listed in its Hello packets. That's the lowkey genius part: received Hellos can get rejected (i.e., neighbor relationships won't even start to form) if there's a mismatch in certain crucial OSPF capabilities (see Section 10.5) 🙅♀️ The optional OSPF capabilities are documented in Section 4.5 📚
Neighbor's Designated Router 🎀 The neighbor's idea of who the Designated Router is. If this is the neighbor itself, it matters for the local calculation of the Designated Router. This is only defined on multi-access networks 🌈
Neighbor's Backup Designated Router 🌷 The neighbor's idea of who the Backup Designated Router is. If this is the neighbor itself, it matters for the local calculation of the Backup Designated Router. This is only defined on multi-access networks too 💜
The next set of variables are lists of link state advertisements. These lists describe subsets of the area topological database 🗺️ There can be five distinct types of link state advertisements in an area topological database: router links, network links, and type 3 and 4 summary links (all stored in the area data structure), plus AS external links (stored in the global data structure) 🧩
Link state retransmission list 🔁 The list of link state advertisements that have been flooded but not acknowledged on this adjacency. These get retransmitted at intervals until they're acknowledged, or until the adjacency is destroyed 😭
Database summary list 📋 The complete list of link state advertisements that make up the area topological database, at the moment the neighbor goes into Database Exchange state. This list gets sent to the neighbor in Database Description packets 🍓
Link state request list 📝 The list of link state advertisements that need to be received from this neighbor so the two neighbors' topological databases get synchronized. This list is created as Database Description packets come in, and then it's sent to the neighbor in Link State Request packets. The list gets depleted as the appropriate Link State Update packets are received 🫧
10.1 Neighbor states ✨
The state of a neighbor (really, the state of a conversation being held with a neighboring router) is documented in the following sections 🧚 The states are listed in order of progressing functionality. For example, the inoperative state comes first, followed by a list of intermediate states before the final, fully functional state is reached 🌸 The specification uses this ordering to make references like "those neighbors/adjacencies in state greater than X" 🎀 Figures 12 and 13 show the graph of neighbor state changes. The arcs of the graphs are labelled with the event causing each state change. The neighbor events are documented in Section 10.2 💅
The graph in Figure 12 shows the state changes effected by the Hello Protocol. The Hello Protocol handles neighbor acquisition and maintenance, and it makes sure two-way communication happens between neighbors 🫶
The graph in Figure 13 shows how an adjacency forms. Not every two neighboring routers become adjacent (see Section 10.4) 🙈 The adjacency starts forming when the neighbor is in state ExStart. After the two routers discover their master/slave status, the state moves to Exchange. At this point the neighbor starts being used in the flooding procedure, and the two routers begin synchronizing their databases 🔄 When that synchronization finishes, the neighbor is in state Full, and we say the two routers are fully adjacent 🥳 At this point, the adjacency gets listed in link state advertisements 📣
For a more detailed description of neighbor state changes, plus the extra actions involved in each change, see Section 10.3 🔍
_____________________________________________________
(Figures not included in text version.)
Figure 12: Neighbor state changes (Hello Protocol)
Figure 13: Neighbor state changes (Database Exchange)
_____________________________________________________Down 🌑 This is the initial state of a neighbor conversation. It means no recent information has been received from the neighbor. On non-broadcast networks, Hello packets may still be sent to "Down" neighbors, just at a reduced frequency (see Section 9.5.1) 🐢
Attempt 📞 This state is only valid for neighbors attached to non-broadcast networks. It means no recent information has been received from the neighbor, but a more concerted effort should be made to reach them 💪 This happens by sending the neighbor Hello packets at intervals of HelloInterval (see Section 9.5.1) ⏱️
Init 👋 In this state, a Hello packet has recently been seen from the neighbor. However, bidirectional communication hasn't been established yet (i.e., the router itself did not appear in the neighbor's Hello packet) 🙃 All neighbors in this state (or higher) are listed in the Hello packets sent from the associated interface 📇
2-Way 🤝 In this state, communication between the two routers is bidirectional. The Hello Protocol makes sure of this 💯 This is the most advanced state short of starting adjacency establishment 🚀 The (Backup) Designated Router gets selected from the set of neighbors in state 2-Way or greater 👑
ExStart 🏁 This is the first step in creating an adjacency between the two neighboring routers. The goal here is to decide which router is the master and to pick the initial sequence number 🎲 Neighbor conversations in this state or greater are called adjacencies 💖
Exchange 🗂️ In this state, the router describes its entire link state database by sending Database Description packets to the neighbor. Each Database Description Packet has a sequence number and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time 🙌 In this state, Link State Request Packets may also be sent to ask for the neighbor's more recent advertisements 📬 All adjacencies in Exchange state or greater are used by the flooding procedure. Honestly, these adjacencies are fully capable of transmitting and receiving all types of OSPF routing protocol packets 🔥
Loading 📥 In this state, Link State Request packets get sent to the neighbor asking for the more recent advertisements that were discovered (but not yet received) during the Exchange state 🛒
Full 🌟 In this state, the neighboring routers are fully adjacent. These adjacencies now appear in router links and network links advertisements. Main character energy, literally 👑✨
10.2 Events causing neighbor state changes 🎬
State changes can be triggered by a number of events. These events show up in the labels of the arcs in Figures 12 and 13. Here's what the labels mean 🏷️
Hello Received 👀 A Hello packet has been received from a neighbor 💌
Start 🚦 This signals that Hello Packets should now be sent to the neighbor at intervals of HelloInterval seconds. This event is generated only for neighbors associated with non-broadcast networks 📡
2-Way Received 🙋♀️ Bidirectional communication has been realized between the two neighboring routers. You can tell because this router sees itself in the other's Hello packet 🪞
NegotiationDone 🤜🤛 The Master/Slave relationship has been negotiated, and sequence numbers have been exchanged. This kicks off the sending and receiving of Database Description packets. For more info on how this event gets generated, check out Section 10.8 🔎
Exchange Done 🎉 Both routers have successfully transmitted a full sequence of Database Description packets. Each router now knows which parts of its link state database are out of date. For more info on how this event gets generated, check out Section 10.8 📖
BadLSReq 🚨 A Link State Request has been received for a link state advertisement that isn't in the database. This shows there's an error in the synchronization process 😬
Loading Done ✅ Link State Updates have been received for all the out-of-date portions of the database. You know it's done when the Link state request list is empty after the Database Description Process has completed 🥹
AdjOK? 🤔 A decision has to be made (again) about whether an adjacency should be established or maintained with the neighbor. This event can start some adjacencies forming and destroy others 💥
The following events cause well developed neighbors to revert to lesser states. Unlike the above events, these events can occur when the neighbor conversation is in any of several states 🙃
Seq Number Mismatch 🚫 A Database Description packet has been received that either a) has an unexpected sequence number, b) unexpectedly has the Init bit set, or c) has an Options field differing from the last Options field received in a Database Description packet. Any of these conditions means some error has occurred during adjacency establishment 😱
1-Way 👀 is the event that fires when a Hello packet shows up from the neighbor but doesn't mention this router at all. That's a clear sign the conversation isn't two-way (bidirectional) yet. 🥺
KillNbr is the "we are SO done" event 💀. All communication with the neighbor is now impossible, so the neighbor gets sent back to Down state.
Inactivity Timer ⏰ goes off when no Hello packets have been seen from the neighbor for a while. Ghosted. The neighbor drops back to Down state.
LLDown 📵 is a heads-up from the lower-level protocols that the neighbor is now unreachable. For example, on an X.25 network this could show up as an X.25 clear indication with appropriate cause and diagnostic fields. This event forces the neighbor into Down state.
10.3 The Neighbor state machine ✨
Okay bestie, this is the detailed breakdown of how the neighbor state changes. Every state change gets triggered by an event (Section 10.2). The same event can do different things depending on what state the neighbor is already in, so the state machine is organized by current neighbor state and received event. Each entry tells you the new neighbor state and the set of extra actions that are required. 📋
When a neighbor's state changes, it may be necessary to rerun the Designated Router election algorithm. Whether that happens depends on whether the interface Neighbor Change event is generated (see Section 9.2). Also, if the Interface is in DR state (the router is itself Designated Router), changes in neighbor state may cause a new network links advertisement to be originated (see Section 12.4). 🔁
When the neighbor state machine needs to invoke the interface state machine, it should be done as a scheduled task (see Section 4.4). This keeps things simple, since it makes sure neither state machine gets executed recursively. 🫶
State(s): Down Event: Start New state: Attempt Action: Send a hello to the neighbor (this neighbor is always associated with a non-broadcast network) and start the inactivity timer for the neighbor. If the timer fires later, that means communication with the neighbor was never reached. 📤
State(s): Attempt Event: Hello Received New state: Init Action: Restart the inactivity timer for the neighbor, since we've now heard from them. 👂
State(s): Down Event: Hello Received New state: Init Action: Start the inactivity timer for the neighbor. If that timer fires later, the neighbor is considered dead. ☠️
State(s): Init or greater Event: Hello Received New state: No state change. Action: Restart the inactivity timer for the neighbor, since they've been heard from again. 💖
State(s): Init Event: 2-Way Received New state: Depends upon action routine. Action: Figure out whether an adjacency should be established with the neighbor (see Section 10.4). If not, the new neighbor state is 2-Way. 🤔
Otherwise (an adjacency should be established), the neighbor state moves to ExStart. The moment we enter this state, the router increments the sequence number for this neighbor. If this is the very first time an adjacency has been attempted, the sequence number should get some unique value (like the time of day clock). ⏱️ Then the router declares itself master (sets the master/slave bit to master) and starts sending Database Description Packets, with the initialize (I), more (M) and master (MS) bits set. These packets should otherwise be empty. They should be retransmitted every RxmtInterval until the next state is entered (see Section 10.8). 🔄✨
State(s): ExStart Event: NegDone New state: Exchange Action: The router must list the contents of its entire area link state database in the neighbor Database summary list. 📝 The area link state database holds the router links, network links and summary links in the area structure, plus the AS external links in the global structure. AS external link advertisements are left out of a virtual neighbor's Database summary list. AS external advertisements are also left out of the Database summary list if the area has been configured as a stub (see Section 3.6). Advertisements whose age is equal to MaxAge get added to the neighbor's Link state retransmission list instead. 🗂️
A summary of the Database summary list will be sent to the neighbor in Database Description packets. Each one has a sequence number and gets explicitly acknowledged. Only one Database Description Packet is allowed to be outstanding at any one time. For more detail on sending and receiving these, check out Sections 10.8 and 10.6. 💅
State(s): Exchange Event: Exchange Done New state: Depends upon action routine. Action: If the neighbor Link state request list is empty, the new neighbor state is Full, and no other action is needed. This is the final state for an adjacency. 🎉
Otherwise, the new neighbor state is Loading. Start (or continue) sending Link State Request packets to the neighbor (see Section 10.9). These are requests for the neighbor's more recent advertisements, the ones that were discovered but not yet received in the Exchange state. Those advertisements are listed in the Link state request list associated with the neighbor. 📬
State(s): Loading Event: Loading Done New state: Full Action: No action required. This is the final state for an adjacency. 🏁
State(s): 2-Way Event: AdjOK? New state: Depends upon action routine. Action: Figure out whether an adjacency should be formed with the neighboring router (see Section 10.4). If not, the neighbor state stays at 2-Way. Otherwise, transition the neighbor state to ExStart and perform the actions tied to the Init state machine entry for the 2-Way Received event. 🔀
State(s): ExStart or greater Event: AdjOK? New state: Depends upon action routine. Action: Determine whether the neighboring router should still be adjacent. If yes, there's no state change and no further action is necessary. ✅
Otherwise, the (possibly partially formed) adjacency must be destroyed. The neighbor state transitions to 2-Way. The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. 🧹
⚠️ Heads up: this is the moment a half-built adjacency gets torn down, so every list gets wiped of link state advertisements. Don't skip it! 💀
State(s): Exchange or greater Event: Seq Number Mismatch New state: ExStart Action: The (possibly partially formed) adjacency is torn down, and then an attempt is made at reestablishment. 🔁 The neighbor state first transitions to ExStart. The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. Then the router increments the sequence number for this neighbor, declares itself master (sets the master/slave bit to master), and starts sending Database Description Packets, with the initialize (I), more (M) and master (MS) bits set. These packets should otherwise be empty (see Section 10.8). 🌸
State(s): Exchange or greater Event: BadLSReq New state: ExStart Action: The action for the BadLSReq event is exactly the same as for the neighbor event SeqNumberMismatch. The (possibly partially formed) adjacency is torn down, and then an attempt is made at reestablishment. For more info, check the neighbor state machine entry that gets invoked when SeqNumberMismatch is generated in state Exchange or greater. 🔍
State(s): Any state Event: KillNbr New state: Down Action: The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. Also, the inactivity timer is disabled. 🛑
State(s): Any state Event: LLDown New state: Down Action: The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. Also, the inactivity timer is disabled. 📵
State(s): Any state Event: Inactivity Timer New state: Down Action: The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. ⏰
State(s): 2-Way or greater Event: 1-Way Received New state: Init Action: The Link state retransmission list, Database summary list and Link state request list get cleared of link state advertisements. 🧼
State(s): 2-Way or greater Event: 2-Way received New state: No state change. Action: No action required. 😌
State(s): Init Event: 1-Way received New state: No state change. Action: No action required. 💅
10.4 Whether to become adjacent 🤝
Adjacencies are established with some subset of the router's neighbors. Routers connected by point-to-point networks and virtual links always become adjacent. On multi-access networks, all routers become adjacent to both the Designated Router and the Backup Designated Router. 🌐
The adjacency-forming decision happens in two places in the neighbor state machine. The first is when bidirectional communication is initially established with the neighbor. The second is when the identity of the attached network's (Backup) Designated Router changes. If the decision is to not attempt an adjacency, the state of the neighbor communication stops at 2-Way. 🛑
An adjacency should be established with a (bidirectional) neighbor when at least one of the following conditions holds:
- The underlying network type is point-to-point
- The underlying network type is virtual link
- The router itself is the Designated Router
- The router itself is the Backup Designated Router
- The neighboring router is the Designated Router
- The neighboring router is the Backup Designated Router
10.5 Receiving Hello packets 💌
This section explains the detailed processing of a received Hello packet. (See Section A.3.2 for the format of Hello packets.) The generic input processing of OSPF packets will have already checked the validity of the IP header and the OSPF packet header. ✅ Next, the values of the Network Mask, HelloInt, and DeadInt fields in the received Hello packet must be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped. In other words, those fields are really describing the attached network's configuration. 🧐 Note that the value of the Network Mask field should not be checked in Hellos received on unnumbered serial lines or on virtual links. 🫶
The receiving interface attaches to a single OSPF area (this could be the backbone). The setting of the E-bit found in the Hello Packet's option field must match this area's external routing capability. ✨ If AS external advertisements are not flooded into/throughout the area (i.e, the area is a "stub"), the E-bit must be clear in received hellos,
otherwise the E-bit must be set 💅 If it doesn't match, processing stops and the packet gets dropped, no debate 🙅♀️. The rest of the bits in the Hello Packet's option field should be ignored, so don't stress about them 🌸
Okay, now the router has to figure out who sent the Hello 👀 It tries to match the source to one of the receiving interface's neighbors. If the receiving interface is a multi-access network (either broadcast or non-broadcast), the source is identified by the IP source address in the Hello's IP header. If the receiving interface is a point-to-point link or a virtual link, the source is identified by the Router ID in the Hello's OSPF packet header. The interface's current list of neighbors lives in the interface's data structure 🗂️ If no matching neighbor structure can be found (aka this is the first time the neighbor has been detected), one gets created, and its initial state is set to Down 🫶
When a Hello comes in from a neighbor on a multi-access network (broadcast or non-broadcast), the neighbor structure's Neighbor ID gets set equal to the Router ID in the packet's OSPF header. When a Hello comes in on a point-to-point network (but not on a virtual link), the neighbor structure's Neighbor IP address gets set to the packet's IP source address 🦋
Now the rest of the Hello Packet gets examined, and that generates events for the neighbor and interface state machines. These state machines are specified to be either executed or scheduled (see Section 4.4). For example, by specifying below that the neighbor state machine be executed in line, several neighbor state transitions can happen off a single received Hello 🧚
- Each Hello Packet causes the neighbor state machine to be executed with the event Hello Received.
- Then the list of neighbors contained in the Hello Packet is examined. If the router itself appears in this list, the neighbor state machine should be executed with the event 2-Way Received. Otherwise, the neighbor state machine should be executed with the event 1-Way Received, and the processing of the packet stops 🛑
- Next, the Hello packet's Router Priority field is examined. If this field is different than the one previously received from the neighbor, the receiving interface's state machine is scheduled with the event NeighborChange. In any case, the Router Priority field in the neighbor data structure should be set accordingly 💜
- Next, the Designated Router field in the Hello Packet is examined. If the neighbor is both declaring itself to be Designated Router (Designated Router field = neighbor IP address) and the Backup Designated Router field in the packet is equal to
0.0.0.0and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Designated Router and it had not previously, or the neighbor is not declaring itself Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. In any case, the Designated Router item in the neighbor structure is set accordingly 🍓 - Finally, the Backup Designated Router field in the Hello Packet is examined. If the neighbor is declaring itself to be Backup Designated Router (Backup Designated Router field = neighbor IP address) and the receiving interface is in state Waiting, the receiving interface's state machine is scheduled with the event BackupSeen. Otherwise, if the neighbor is declaring itself to be Backup Designated Router and it had not previously, or the neighbor is not declaring itself Backup Designated Router where it had previously, the receiving interface's state machine is scheduled with the event NeighborChange. In any case, the Backup Designated Router item in the neighbor structure is set accordingly 🌈
10.6 Receiving Database Description Packets ✨
This section breaks down exactly how a received Database Description packet gets processed 🔍 The incoming packet has already been matched to a neighbor and receiving interface by the generic input packet processing (Section 8.2). After that, what happens next depends on the neighbor's state. If the neighbor's state is Down or Attempt, the packet should be ignored. Otherwise, here's what happens for each state:
Init: The neighbor state machine should be executed with the event 2-Way Received. This causes an immediate state change to either state 2-Way or state Exstart. Processing of the current packet should then continue in this new state 🌸
2-Way: The packet should be ignored. Database description packets are only used for bringing up adjacencies.[7]
ExStart: If the received packet matches one of the following cases, the neighbor state machine should be executed with the event NegotiationDone (causing the state to transition to Exchange), the packet's Options field should be recorded in the neighbor structure's Neighbor Options field, and the packet should be accepted as next in sequence and processed further (see below). Otherwise, the packet should be ignored 🎀
- The initialize(I), more (M) and master(MS) bits are set, the contents of the packet are empty, and the neighbor's Router ID is larger than the router's own. In this case the router is now Slave. Set the master/slave bit to slave, and set the sequence number to that specified by the master.
- The initialize(I) and master(MS) bits are off, the packet's sequence number equals the router's own sequence number (indicating acknowledgment), and the neighbor's Router ID is smaller than the router's own. In this case the router is Master.
Exchange: If the state of the MS-bit is inconsistent with the master/slave state of the connection, generate the neighbor event Seq Number Mismatch and stop processing the packet. Otherwise:
- If the initialize(I) bit is set, generate the neighbor event Seq Number Mismatch and stop processing the packet.
- If the packet's Options field indicates a different set of optional OSPF capabilities than were previously received from the neighbor (recorded in the Neighbor Options field of the neighbor structure), generate the neighbor event Seq Number Mismatch and stop processing the packet.
- If the router is master, and the packet's sequence number equals the router's own sequence number (this packet is the next in sequence), the packet should be accepted and its contents processed (below).
- If the router is master, and the packet's sequence number is one less than the router's sequence number, the packet is a duplicate. Duplicates should be discarded by the master 🙅♀️
- If the router is slave, and the packet's sequence number is one more than the router's own sequence number (this packet is the next in sequence), the packet should be accepted and its contents processed (below).
- If the router is slave, and the packet's sequence number is equal to the router's sequence number, the packet is a duplicate. The slave must respond to duplicates by repeating the last Database Description packet that it sent.
- Else, generate the neighbor event Seq Number Mismatch and stop processing the packet 💀
Loading or Full: In this state, the router has sent and received an entire sequence of Database Descriptions. The only packets received should be duplicates (see above). In particular, the packet's Options field should match the set of optional OSPF capabilities previously indicated by the neighbor (stored in the neighbor structure's neighbor Options field). Any other packets received, including the reception of a packet with the Initialize(I) bit set, should generate the neighbor event Seq Number Mismatch.[8] Duplicates should be discarded by the master. The slave must respond to duplicates by repeating the last Database Description packet that it sent 🫶
When the router accepts a received Database Description Packet as the next in sequence, the packet contents are processed as follows. For each link state advertisement listed, the advertisement's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS external advertisement (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event Seq Number Mismatch and stop processing the packet. Otherwise, the router looks up the advertisement in its database to see whether it also has an instance of the link state advertisement. If it does not, or if the database copy is less recent (see Section 13.1), the link state advertisement is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets 📝
When the router accepts a received Database Description Packet as the next in sequence, it also performs the following actions, depending on whether it is master or slave:
Master: Increments the sequence number. If the router has already sent its entire sequence of Database Descriptions, and the just accepted packet has the more bit (M) set to 0, the neighbor event Exchange Done is generated. Otherwise, it should send a new Database Description to the slave 👑
Slave: Sets the sequence number to the sequence number appearing in the received packet. The slave must send a Database Description in reply. If the received packet has the more bit (M) set to 0, and the packet to be sent by the slave will have the M-bit set to 0 also, the neighbor event Exchange Done is generated. Note that the slave always generates this event before the master 🧚
10.7 Receiving Link State Request Packets ✨
This section explains the detailed processing of received Link State Request packets. Received Link State Request Packets specify a list of link state advertisements that the neighbor wants to receive 🎀 Link State Request Packets should be accepted when the neighbor is in states Exchange, Loading, or Full. In all other states, Link State Request Packets should be ignored 🙈
Each link state advertisement specified in the Link State Request packet should be located in the router's database and copied into Link State Update packets for transmission to the neighbor. These link state advertisements should NOT be placed on the Link state retransmission list for the neighbor. If a link state advertisement cannot be found in the database, something has gone wrong with the synchronization procedure, and the neighbor event BadLSReq should be generated 😭
10.8 Sending Database Description Packets ✨
This section describes how Database Description Packets are sent to a neighbor 💌 The router's optional OSPF capabilities (see Section 4.5) are transmitted to the neighbor in the Options field of the Database Description packet. The router should maintain the same set of optional capabilities throughout the Database Exchange and flooding procedures. If for some reason the router's optional capabilities change, the Database Exchange procedure should be restarted by reverting to neighbor state ExStart. There are currently two optional capabilities defined. The T-bit should be set if and only if the router is capable of calculating separate routes for each IP TOS. The E-bit should be set if and only if the attached network belongs to a non-stub area. The rest of the Options field should be set to zero 🦋
The sending of Database Description packets depends on the neighbor's
In state ExStart, the router sends empty Database Description packets with the initialize (I), more (M) and master (MS) bits set ✨ These get retransmitted every RxmtInterval seconds, so the router keeps knocking until the handshake lands 🎀
In state Exchange, the Database Description Packets actually contain summaries of the link state information in the router's database 🦋 Each link state advertisement in the area's topological database (at the time the neighbor transitions into Exchange state) gets listed in the neighbor Database summary list. When a new Database Description Packet is to be sent, the packet's sequence number is incremented, and the (new) top of the Database summary list is described by the packet. Items get removed from the Database summary list once the previous packet is acknowledged 💅
In state Exchange, deciding when to send a packet depends on whether the router is master or slave 👑
Master Packets are sent when either a) the slave acknowledges the previous packet by echoing the sequence number or b) RxmtInterval seconds elapse without an acknowledgment, in which case the previous packet is retransmitted. main character energy, the master is driving the whole conversation 💖
Slave Packets are sent only in response to packets received from the master. If the packet received from the master is new, a new packet is sent. Otherwise the previous packet is resent 🫶
In states Loading and Full, the slave must resend its last packet in response to duplicate packets received from the master. For this reason, the slave must wait RouterDeadInterval seconds before freeing the last packet 🙈 Reception of a packet from the master after this interval will generate a Seq Number Mismatch neighbor event 💀
10.9 Sending Link State Request Packets ✨
In neighbor states Exchange or Loading, the Link state request list contains a list of those link state advertisements that need to be obtained from the neighbor. To request these advertisements, a router sends the neighbor the beginning of the Link state request list, packaged in a Link State Request packet 🦋
When the neighbor responds to these requests with the proper Link State Update packet(s), the Link state request list is truncated and a new Link State Request packet is sent. This process continues until the link state request list becomes empty. Unsatisfied Link State Requests are retransmitted at intervals of RxmtInterval. There should be at most one Link State Request packet outstanding at any one time 🌸
When the Link state request list becomes empty, and the neighbor state is Loading (i.e., a complete sequence of Database Description packets has been received from the neighbor), the Loading Done neighbor event is generated 🎀
10.10 An Example 🧚
Figure 14 shows an example of an adjacency forming. Routers RT1 and RT2 are both connected to a broadcast network. It is assumed that RT2 is the Designated Router for the network, and that RT2 has a higher Router ID than router RT1 👑
The neighbor state changes realized by each router are listed on the sides of the figure.
At the beginning of Figure 14, router RT1's interface to the network becomes operational. It begins sending hellos, although it doesn't know the identity of the Designated Router or of any other neighboring routers 🌈 Router RT2 hears this hello (moving the neighbor to Init state), and in its next hello indicates that it is itself the Designated Router and that it has heard hellos from RT1. This in turn causes RT1 to go to state ExStart, as it starts to bring up the adjacency ✨
RT1 begins by asserting itself as the master. When it sees that RT2 is indeed the master (because of RT2's higher Router ID), RT1 transitions to slave state and adopts its neighbor's sequence number. Database Description packets are then exchanged, with polls coming from the master (RT2) and responses from the slave (RT1). This sequence of Database Description Packets ends when both the poll and associated response have the M-bit off 💅
In this example, it is assumed that RT2 has a completely up to date database. In that case, RT2 goes immediately into Full state. RT1 will go into Full state after updating the necessary parts of its database. This is done by sending Link State Request Packets, and receiving Link State Update Packets in response. Note that, while RT1 has waited until a complete set of Database Description Packets has been received (from RT2) before sending any Link State Request Packets, this need not be the case. RT1 could have interleaved the sending of Link State Request Packets with the reception of Database Description Packets 🔥
11. The Routing Table Structure 🗺️
The routing table data structure contains all the information necessary to forward an IP data packet toward its destination. Each routing table entry describes the collection of best paths to a particular destination. When forwarding an IP data packet, the routing table entry providing the best match for the packet's IP destination is located 💖
________________________________________
(Figure not included in text version.)
Figure 14: An adjacency bring-up example
________________________________________The matching routing table entry then provides the next hop towards the packet's destination. OSPF also provides for the existence of a default route (Destination ID = DefaultDestination). When the default route exists, it matches all IP destinations (although any other matching entry is a better match). Finding the routing table entry that best matches an IP destination is further described in Section 11.1 🦋
There is a single routing table in each router. Two sample routing tables are described in Sections 11.2 and 11.3. The building of the routing table is discussed in Section 16 🌸
The rest of this section defines the fields found in a routing table entry. The first set of fields describes the routing table entry's destination 🎀
Destination Type The destination can be one of three types. Only the first type, Network, is actually used when forwarding IP data traffic. The other destinations are used solely as intermediate steps in the routing table build process 🧚
- Network: A range of IP addresses, to which IP data traffic may be forwarded. This includes IP networks (class A, B, or C), IP subnets, and single IP hosts. The default route also falls in this category.
- Area border router: Routers that are connected to multiple OSPF areas. Such routers originate summary link advertisements. These routing table entries are used when calculating the inter-area routes (see Section 16.2). These routing table entries may also be associated with configured virtual links.
- AS boundary router: Routers that originate AS external link advertisements. These routing table entries are used when calculating the AS external routes (see Section 16.4).
Destination ID The destination's identifier or name. This depends on the destination's type. For networks, the identifier is their associated IP address. For all other types, the identifier is the OSPF Router ID.[9] 👑
Address Mask Only defined for networks. The network's IP address together with its address mask defines a range of IP addresses. For IP subnets, the address mask is referred to as the subnet mask. For host routes, the mask is "all ones" (0xffffffff) 💅
Optional Capabilities When the destination is a router (either an area border router or an AS boundary router), this field indicates the optional OSPF capabilities supported by the destination router. The two optional capabilities currently defined by this specification are the ability to route based on IP TOS and the ability to process AS external advertisements. For a further discussion of OSPF's optional capabilities, see Section 4.5 🌈
The set of paths to use for a destination may vary based on IP Type of Service and the OSPF area to which the paths belong. This means that there may be multiple routing table entries for the same destination, depending on the values of the next two fields 🫶
Type of Service There can be a separate set of routes for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3 ✨
Area This field indicates the area whose link state information has led to the routing table entry's collection of paths. This is called the entry's associated area. For sets of AS external paths, this field is not defined. For destinations of type "area border router", there may be separate sets of paths (and therefore separate routing table entries) associated with each of several areas. This will happen when two area border routers share multiple areas in common. For all other destination types, only the set of paths associated with the best area (the one providing the shortest route) is kept 🔥
The rest of the routing table entry describes the set of paths to the destination. The following fields pertain to the set of paths as a whole. In other words, each one of the paths contained in a routing table entry is of the same path-type and cost (see below) 🌸
Path-type There are four possible types of paths used to route traffic to the destination, listed here in order of preference: intra-area, inter-area, type 1 external or type 2 external. Intra-area paths indicate destinations belonging to one of the router's attached areas. Inter-area paths are paths to destinations in other OSPF areas. These are discovered through the examination of received summary link advertisements. AS external paths are paths to destinations external to the AS. These are detected through the examination of received AS external link advertisements 🧚
Cost The link state cost of the path to the destination. For all paths except type 2 external paths, this describes the entire path's cost. For Type 2 external paths, this field describes the cost of the portion of the path internal to the AS. This cost is calculated as the sum of the costs of the path's constituent links 💖
Type 2 cost Only valid for type 2 external paths. For these paths, this field indicates the cost of the path's external portion. This cost has been advertised by an AS boundary router, and is the most significant part of the total path cost. For example, an external type 2 path with type 2 cost of 5 is always preferred over a path with type 2 cost of 10, regardless of the cost of the two paths' internal components 👑
Link State Origin Valid only for intra-area paths, this field indicates the link state advertisement (router links or network links) that directly references the destination. For example, if the destination is a transit network, this is the transit network's network links advertisement. If the destination is a stub network, this is the router links advertisement for the attached router. The advertisement is discovered during the shortest-path tree calculation (see Section 16.1). Multiple advertisements may reference the destination, however a tie-breaking scheme always reduces the choice to a single advertisement 🦋
This field is for informational purposes only. The advertisement could be used as a root for an SPF calculation when building a reverse path forwarding tree. This is beyond the scope of this specification 🌈
When multiple paths of equal path-type and cost exist to a destination (called elsewhere "equal-cost" paths), they are stored in a single routing table entry. Each one of the "equal-cost" paths is distinguished by the following fields:
Next hop 💖 okay so this is the outgoing router interface the router uses when it forwards traffic toward the destination. On multi-access networks, the next hop also includes the IP address of the next router (if any) in the path toward the destination. That next router will always be one of the adjacent neighbors 🦋
Advertising router ✨ this one only applies to inter-area and AS external paths. It tells you the Router ID of the router that advertised the summary link or AS external link that led to this path 🧚
11.1 Routing table lookup 🔍
okay bestie, so when an IP data packet shows up, an OSPF router has to find the routing table entry that best matches the packet's destination. That entry then hands over the outgoing interface and the next hop router to use for forwarding. This section walks through how the router finds that best match. It's a bunch of steps where the pile of routing table entries gets narrower and narrower, until only one is left, and that one is the best match 💅
ngl, the steps can sometimes fail to find a best match. Like, every single entry gets pruned for some reason. When that happens, the packet's IP destination counts as unreachable. So the packet shouldn't be forwarded. It should be dropped, and an ICMP destination unreachable message should go back to the packet's source 💀
(1) Select the complete set of "matching" routing table entries from the routing table. Each entry describes a (set of) path(s) to a range of IP addresses. If the packet's IP destination falls into an entry's range, that entry is called a match. (It's super likely that several entries will match the same packet. A default route, for example, matches every packet 🌈)
(2) Now, suppose the packet's IP destination falls into one of the router's configured area address ranges (see Section 3.5), and that particular area address range is active. That means there are one or more reachable (by intra-area paths) networks inside the area address range. The packet's IP destination is then required to belong to one of those constituent networks. So only matching entries with a path-type of intra-area get considered, and everything else is pruned. If no such matching entries exist, the destination is unreachable (see above). Otherwise, skip to step 4 ✨
(3) Reduce the set of matching entries to the ones with the most preferential path-type (see Section 11). OSPF has a four-level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, Type 1 external, and Type 2 external paths 👑
(4) Select the remaining routing table entry that gives the longest (most specific) match. Another way to say this is to choose the remaining entry that specifies the narrowest range of IP addresses.[10] For example, the entry for the address/mask pair of (128.185.1.0, 0xffffff00) is more specific than the entry for (128.185.0.0, 0xffff0000). The default route is the least specific match, since it matches all destinations 🎀
(5) At this point there might still be multiple routing table entries left. Each one specifies the same range of IP addresses, but with a different IP Type of Service. Select the entry whose TOS value matches the TOS in the packet header. If there's no routing table entry for that TOS, select the routing table entry for TOS 0. Put another way, packets requesting TOS X get routed along the TOS 0 path if a TOS X path doesn't exist 🫶
11.2 Sample routing table, without areas 🌸
Picture the Autonomous System in Figure 2. No OSPF areas have been configured here. A single metric is shown per outbound interface, which means routes won't vary based on TOS. The calculation router RT6 does its thing as described in Section 2.1, and the resulting routing table is Table 12. Destination types get abbreviated: Network is "N", area border router is "BR", and AS boundary router is "ASBR" 🍓
There are no instances of multiple equal-cost shortest paths in this example. Also, since there are no areas, there are no inter-area paths 🙈
Routers RT5 and RT7 are AS boundary routers. Intra-area routes have been calculated to both of them. This lets external routes be calculated to the destinations advertised by RT5 and RT7 (aka networks N12, N13, N14 and N15). All AS external advertisements originated by RT5 and RT7 are assumed to be advertising type 1 external metrics. So type 1 external paths get calculated to destinations N12-N15 🔥
11.3 Sample routing table, with areas 🗺️
Same vibe as the last example, except now we split everything into OSPF areas. An OSPF area configuration is pictured in Figure 6. Router RT4's routing table gets described for this area setup. RT4 has a connection to Area 1 and a backbone connection. That makes RT4 see the AS as the combo of the two graphs shown in Figures 7 and 8. The resulting routing table is shown in Table 13 💜
Again, routers RT5 and RT7 are AS boundary routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. Note that there are two routing entries (in this case with identical paths) for router RT7, since it's both an area border router and an AS boundary router. Also, there are two routing entries for area border router RT3, since it has two areas in common with RT4 (Area 1 and the backbone) 🧚
Backbone paths have been calculated to all area border routers (BR). These get used when working out the inter-area routes. Here's the routing table for Router RT6, the one with no configured areas, for reference. Note that all of
Type Dest Area Path Type Cost Next Hop(s) Adv. Router(s)
__________________________________________________________________________
N N1 0 intra-area 10 RT3 *
N N2 0 intra-area 10 RT3 *
N N3 0 intra-area 7 RT3 *
N N4 0 intra-area 8 RT3 *
N Ib 0 intra-area 7 * *
N Ia 0 intra-area 12 RT10 *
N N6 0 intra-area 8 RT10 *
N N7 0 intra-area 12 RT10 *
N N8 0 intra-area 10 RT10 *
N N9 0 intra-area 11 RT10 *
N N10 0 intra-area 13 RT10 *
N N11 0 intra-area 14 RT10 *
N H1 0 intra-area 21 RT10 *
ASBR RT5 0 intra-area 6 RT5 *
ASBR RT7 0 intra-area 8 RT10 *
__________________________________________________________________________
N N12 * type 1 external 10 RT10 RT7
N N13 * type 1 external 14 RT5 RT5
N N14 * type 1 external 14 RT5 RT5
N N15 * type 1 external 17 RT10 RT7Table 12: The routing table for Router RT6 (no configured areas).
the inter-area routes are associated with the backbone, and that's always the case when the router is itself an area border router. Routing information gets condensed at area boundaries 📦 In this example, we assume Area 3 has been defined so that networks N9-N11 and the host route to H1 all get condensed into a single route when advertised to the backbone (by router RT11). Note that the cost of this route is the minimum of the set of costs to its individual components 🌈
There's a virtual link configured between routers RT10 and RT11. Without this configured virtual link, RT11 would be unable to advertise a route for networks N9-N11 and host H1 into the backbone, and there wouldn't be an entry for these networks in router RT4's routing table 😭
In this example there are two equal-cost paths to network N12. However, they both use the same next hop (Router RT5) 💅
Router RT4's routing table would improve (i.e., some of the paths in the routing table would become shorter) if an additional virtual link were configured between router RT4 and router RT3. The new virtual link would itself be associated with the first entry for area border router RT3 in Table 13 (an intra-area path through Area 1). That would yield a cost of 1 for the virtual link. The routing table entry changes caused by adding this virtual link are shown in Table 14 🦋
12. Link State Advertisements ✨
Each router in the Autonomous System originates one or more link state advertisements. There are five distinct types of link state advertisements, described in Section 4.3. The collection of link state advertisements forms the link state or topological database. Each separate type of advertisement has its own function. Router links and network links advertisements describe how an area's routers and networks are interconnected. Summary link advertisements provide a way of condensing an area's routing information. AS external advertisements provide a way of transparently advertising externally-derived routing information throughout the Autonomous System 👑
Each link state advertisement begins with a standard 20-byte header. This link state header is discussed below 🎀
Type Dest Area Path Type Cost Next Hop(s) Adv. Router(s)
_______________________________________________________________________________
N N1 1 intra-area 4 RT1 *
N N2 1 intra-area 4 RT2 *
N N3 1 intra-area 1 * *
N N4 1 intra-area 3 RT3 *
BR RT3 1 intra-area 1 * *
_______________________________________________________________________________
N Ib 0 intra-area 22 RT5 *
N Ia 0 intra-area 27 RT5 *
BR RT3 0 intra-area 21 RT5 *
BR RT7 0 intra-area 14 RT5 *
BR RT10 0 intra-area 22 RT5 *
BR RT11 0 intra-area 25 RT5 *
ASBR RT5 0 intra-area 8 * *
ASBR RT7 0 intra-area 14 RT5 *
_______________________________________________________________________________
N N6 0 inter-area 15 RT5 RT7
N N7 0 inter-area 19 RT5 RT7
N N8 0 inter-area 18 RT5 RT7
N N9-N11,H1 0 inter-area 26 RT5 RT11
_______________________________________________________________________________
N N12 * type 1 external 16 RT5 RT5,RT7
N N13 * type 1 external 16 RT5 RT5
N N14 * type 1 external 16 RT5 RT5
N N15 * type 1 external 23 RT5 RT7Table 13: Router RT4's routing table in the presence of areas.
Type Dest Area Path Type Cost Next Hop(s) Adv. Router(s)
__________________________________________________________________________
N Ib 0 intra-area 16 RT3 *
N Ia 0 intra-area 21 RT3 *
BR RT3 0 intra-area 1 * *
BR RT10 0 intra-area 16 RT3 *
BR RT11 0 intra-area 19 RT3 *__________________________________________________________________________
N N9-N11,H1 0 inter-area 20 RT3 RT11Table 14: okay so this is the part where an additional virtual link changes things, and the table shows exactly which routes shift when it shows up 🦋
12.1 The Link State Header
bestie, the link state header is the ID card for every link state advertisement 🪪 The LS type, Link State ID, and Advertising Router fields together are what make each advertisement unique ✨
Here's the thing though: there can be several copies of the same advertisement floating around the Autonomous System all at once 🫣 So a router MUST figure out which copy is the newest. It does that by looking at the LS sequence, LS checksum, and LS age fields. Those three also live in that same 20-byte link state header 💅
When OSPF packets list link state advertisements, they usually just refer to each one by its LS type, Link State ID, and Advertising Router, unless the exact copy matters 🎀 If the exact copy does matter, the LS sequence number, LS age, and LS checksum fields have to get involved too 👀
Okay, let's break down each field in the link state header, one by one 🌸
12.1.1 LS age
This is the age of the advertisement in seconds ⏳ It SHOULD be processed as an unsigned 16-bit integer. It's set to 0 when the advertisement gets originated, and it MUST be incremented by InfTransDelay on every hop of the flooding procedure. Advertisements also keep aging while they sit in each router's database 🧓
The age never goes past MaxAge, and advertisements that have hit MaxAge aren't used in the routing table calculation 💀 The moment an advertisement's age first reaches MaxAge, it gets reflooded 🔁 Once it's no longer sitting on any neighbor's Link state retransmission list, it finally gets flushed from the database. That only happens after every adjacent neighbor has acknowledged it 🧹 For more on how aging works, check Section 14 🫶
Now, when a router gets two copies of an advertisement that have the same sequence numbers and checksums, the ages come into play 👑 A copy at MaxAge always wins as the most recent one, which is how old stuff gets flushed out of the routing domain super fast 🏃♀️💨 Otherwise, if the ages differ by more than MaxAgeDiff, the copy with the smaller age wins as most recent.[11] See Section 13.1 for the full tea ☕
12.1.2 Options
The options field tells you which optional capabilities go with the advertisement 🧩 OSPF's optional capabilities are covered in Section 4.5. Right now there are two of them, and they're the T-bit and the E-bit in the options field 🎀 Everything else in the options field SHOULD be set to zero.
The E-bit is for OSPF's external routing capability 🌍 It SHOULD be set in every advertisement tied to the backbone, and in every advertisement tied to non-stub areas (see Section 3.6). It SHOULD also be set in all AS external advertisements. In router links, network links, and summary link advertisements tied to a stub area, it SHOULD be reset 🙅♀️ For all link state advertisements, the E-bit is just for information, and it doesn't change the routing table calculation at all 🤷♀️
The T-bit is for OSPF's TOS routing capability 💜 In a router links advertisement, it SHOULD be set if and only if the router can calculate separate routes for each IP TOS (see Section 2.4). The T-bit SHOULD always be set in network links advertisements. In summary link and AS external link advertisements, it SHOULD be set if and only if the advertisement describes paths for all TOS values instead of only the TOS 0 path 🌈 Here's a plot twist: with the T-bit set, there MAY still be just one metric in the advertisement, which is the TOS 0 metric. That means non-zero TOS paths exist but work exactly the same as the TOS 0 path 🙈 A link state advertisement's T-bit gets checked when the routing table's non-zero TOS paths are calculated (see Section 16.9) ✨
12.1.3 LS type
The LS type field decides the format and function of the advertisement 🦋 Different types have different names, like router links or network links 💅 Every type except AS external link advertisements (LS type = 5) gets flooded throughout a single area only. AS external link advertisements get flooded across the entire Autonomous System, minus stub areas (see Section 3.6) 🌸 Here's the lineup, all of the types, in Table 15 👇
LS Type Advertisement description
__________________________________________________
1 These are the router links
advertisements. They describe the
LS Type Advertisement description
__________________________________________________
collected states of the router's
interfaces. For more information,
consult Section 12.4.1.
__________________________________________________
2 These are the network links
advertisements. They describe the set
of routers attached to the network. For
more information, consult
Section 12.4.2.
__________________________________________________
3 or 4 These are the summary link
advertisements. They describe
inter-area routes, and enable the
condensation of routing information at
area borders. Originated by area border
routers, the Type 3 advertisements
describe routes to networks while the
Type 4 advertisements describe routes to
AS boundary routers.
__________________________________________________
5 These are the AS external link
advertisements. Originated by AS
boundary routers, they describe routes
to destinations external to the
Autonomous System. A default route for
the Autonomous System can also be
described by an AS external link
advertisement.
Table 15: OSPF link state advertisements.12.1.4 Link State ID
This field identifies which piece of the routing domain the advertisement is describing 🗺️ What it holds depends on the LS type, and Table 16 has the full rundown 💖
LS Type Link State ID
______________________________________________________________________
1 The originating router's Router ID.
2 The IP interface address of the network's Designated Router.
3 The destination network's IP address.
4 The Router ID of the described AS boundary router.
5 The destination network's IP address.
Table 16: The advertisement's Link State ID.When the advertisement is about a network, the Link State ID is either the network's IP address (like in type 3 summary link advertisements and AS external link advertisements), or the IP address can be easily worked out from the Link State ID 🧠 Quick tip from the table: masking a network links advertisement's Link State ID with the network's subnet mask gives you the network's IP address 🎀 When the advertisement is about a router, the Link State ID is always that router's OSPF Router ID 🫶
When an AS external advertisement (LS Type = 5) describes a default route, its Link State ID gets set to DefaultDestination (0.0.0.0) 🌟
12.1.5 Advertising Router
This field tells you the OSPF Router ID of whoever originated the advertisement 🙋♀️ For router links advertisements, it's the same as the Link State ID field 👯♀️ Network link advertisements come from the network's Designated Router 📡 Summary link advertisements come from area border routers 🚪 And AS external link advertisements come from AS boundary routers 🌍
12.1.6 LS sequence number
The sequence number field is a signed 32-bit integer, and its whole job is catching old and duplicate advertisements 🕵️♀️ The sequence number space is linearly ordered, so the bigger the sequence number (compared as signed 32-bit integers), the more recent the advertisement 🆕 To get more precise about this space, let N stand for the constant 2**31 in the discussion below 🧮
Sequence number -N (0x80000000) is reserved and unused, so that leaves -N + 1 (0x80000001) as the smallest, and therefore oldest, sequence number 🕰️ A router uses that number the first time it originates any link state advertisement. After that, the sequence number goes up by one every time the router originates a new instance 📈 When an attempt to go past the maximum value of N - 1 (0x7fffffff) happens, the current instance MUST first be flushed from the routing domain 🧹 That's done by prematurely aging the advertisement (see Section 14.1) and reflooding it. Once every adjacent neighbor has acknowledged that flood, a new instance can be originated with sequence number -N + 1 (0x80000001) 🌈
Sometimes a router gets forced to promote the sequence number of one of its own advertisements, and that happens when a more recent instance of it shows up unexpectedly during flooding 😳 That SHOULD be a rare event. It MAY mean that an out-of-date advertisement, originated by the router itself before its last restart or reload, is still hanging around in the Autonomous System 👻 For more info, see Section 13.4 🫶
12.1.7 LS checksum
This field is the checksum of the complete contents of the advertisement, except for the age field 🧮 The age field gets skipped so an advertisement's age can go up without the checksum needing an update 💅 The checksum used is the same one used for ISO connectionless datagrams, and it's commonly called the Fletcher checksum. It's documented in Annex C of [RFC 994] 📚 The link state header also has the advertisement's length in bytes, so subtracting the two-byte age field gives you the amount of data to checksum 🎀
The checksum exists to catch data corruption in an advertisement 🛡️ That corruption can happen while the advertisement is being flooded, or while it's sitting in a router's memory 🧠 The LS checksum field can never be zero, so if it shows up as zero, that SHOULD be treated as a checksum failure. In other words, calculating the checksum is not optional 😤
The checksum gets verified in two situations: a) when it's received in a Link State Update Packet, and b) at times during the aging of the link state database ⏰ A checksum failure leads to different actions in each case, so check Sections 13 and 14 for the details 📖
Whenever the LS sequence number field says two instances of an advertisement are the same, the LS checksum field gets examined next 🔍 If the checksums differ, the instance with the larger checksum counts as most recent.[12] See Section 13.1 for more details 🌸
12.2 The link state database
A router keeps a separate link state database for every area it belongs to 🗂️ The link state database has been called the topological database elsewhere in the text. All routers in the same area have identical topological databases for that area 👯♀️
Each area's database is always handled separately 🙅♀️ The shortest path calculation runs separately for each area (see
Section 16). Okay so the area database has a very specific guest list 💅. Flooding of its components stays inside the area only 🦋, and when an adjacency (belonging to Area A) comes up, only the Area A database gets synced between the two routers 🫶. Bestie, that's giving tidy boundaries.
The area database is made of router links advertisements, network links advertisements, and summary link advertisements (all listed in the area data structure) 🌸. AS external advertisements (aka external routes) show up in every non-stub area database too, see Section 3.6 ✨.
An OSPF implementation must be able to get at individual pieces of an area database 🔥. The lookup is based on an advertisement's LS type, Link State ID and Advertising Router [13] 🧚. There's only ever one instance in the database (the most up-to-date one) of each link state advertisement, so no duplicates, periodt 👑. The lookup function gets called during link state flooding (Section 13) and the routing table calculation (Section 16) 💖. Using it, a router can also figure out whether it has ever originated a particular link state advertisement, and if so, what LS sequence number it used 🙈.
A link state advertisement gets added to a router's database when either a) it's received during flooding (Section 13) or b) the router originates it itself (Section 12.4) 🎀. It gets deleted when either a) a newer instance overwrites it during flooding (Section 13), or b) the router originates a newer instance of one of its self-originated advertisements (Section 12.4), or c) it ages out and gets flushed from the routing domain (Section 14) 💀. Whenever one gets deleted, it must also be removed from all neighbors' Link state retransmission lists (see Section 10) 🫶.
12.3 Representation of TOS ✨
Every OSPF link state advertisement except network links advertisements carries metrics 💜. In router links advertisements, the metrics are the costs of the interfaces being described 🌈. In summary link and AS external link advertisements, the metric is the cost of the described path 🍓. Across all of these, each IP TOS can get its own metric 💅. TOS gets encoded into an OSPF link state advertisement as a mapping of the Delay (D), Throughput (T) and Reliability (R) flags from the IP packet header's TOS field (see [RFC 791]) 🦋.
OSPF encoding D T R
_________________________
0 0 0 0
4 0 0 1
8 0 1 0
12 0 1 1
16 1 0 0
20 1 0 1
24 1 1 0
28 1 1 1Table 17: Representing TOS in OSPF.
Every OSPF link state advertisement must specify the TOS 0 metric 🌸. Other TOS metrics, if they show up, must appear in order of increasing TOS encoding 💖. For example, the TOS 8 (high throughput) metric must always come before the TOS 16 (low delay) metric when both are specified 🧚. If a metric for some non-zero TOS isn't specified, its cost defaults to the cost for TOS 0, unless the T-bit is reset in the advertisement's options field (see Section 12.1.2 for more details) ✨.
Also, if more TOS types get defined in a future IP architecture, OSPF's TOS encoding can be extended in a straightforward manner 🌈. Future-proof and iconic 👑.
12.4 Originating link state advertisements ✨
A router may originate many types of link state advertisements 🔥. Every router originates a router links advertisement for each area it belongs to 🎀. If the router is also the Designated Router for any of its attached networks, it'll originate a network links advertisement for that network too 🦋.
Area border routers originate a single summary links advertisement for each known inter-area destination 💜. AS boundary routers originate a single AS external links advertisement for each known AS external destination 🍓. Destinations get advertised one at a time 💅, so a change to any single route can be flooded without reflooding the entire collection of routes 🫶. During flooding, many link state advertisements can ride along in a single Link State Update packet 🌸.
Let's look at router RT4 in Figure 6 as an example 🧚. It's an area border router with a connection to Area 1 and the backbone 👑. RT4 originates 5 distinct link state advertisements into the backbone (one router links, and one summary link for each of the networks N1-N4) 💖. It also originates 8 distinct link state advertisements into Area 1 (one router links and seven summary link advertisements, as pictured in Figure 7) ✨. If RT4 has been selected as Designated Router for network N3, it'll also originate a network links advertisement for N3 into Area 1 🌈.
In that same figure, router RT5 will be originating 3 distinct AS external link advertisements (one for each of the networks N12-N14) 🙈. These get flooded throughout the entire AS, assuming none of the areas have been configured as stubs 🔥. But if area 3 has been configured as a stub area, the external advertisements for networks N12-N14 won't be flooded into area 3 (see Section 3.6) 💀. Instead, router RT11 would originate a default summary link advertisement that gets flooded throughout area 3 (see Section 12.4.3) 🎀. This tells all of area 3's internal routers to send their AS external traffic to RT11 🦋.
Whenever a new instance of a link state advertisement is originated, its LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the advertisement is added to the link state database and flooded out the appropriate interfaces 💜. See Section 13.2 for details on installing the advertisement into the link state database 🍓. See Section 13.3 for details on flooding newly originated advertisements 💅.
The eight events that cause a new instance of a link state advertisement to be originated are the following 🫶.
(1) The LS refresh timer firing. Each link state advertisement the router has originated gets its own LS refresh timer 🌸. It's an interval timer with length LSRefreshTimer 🧚. The LS refresh timer guarantees periodic originations no matter what other events cause new instances 👑. This periodic updating adds robustness to the link state algorithm 💖. Link state advertisements that solely describe unreachable destinations should not be refreshed, but should instead be flushed from the routing domain (see Section 14.1) ✨.
When whatever is being described by a link state advertisement changes, a new advertisement is originated 🌈. Two instances of the same link state advertisement may not be originated within the time period MinLSInterval 🙈. This may delay generation of the next instance by up to MinLSInterval 🔥. The following changes may cause a router to originate a new instance of an advertisement 💀. These changes should cause new originations only if the contents of the new advertisement would be different 🎀.
(2) An interface's state changes (see Section 9.1) 🦋. This may mean it's necessary to produce a new instance of the router links advertisement 💜.
(3) An attached network's Designated Router changes 🍓. A new router links advertisement should be originated 💅. Also, if the router itself is now the Designated Router, a new network links advertisement should be produced 🫶.
(4) One of the neighboring routers changes to or from the FULL state 🌸. This may mean it's necessary to produce a new instance of the router links advertisement 🧚. Also, if the router is itself the Designated Router for the attached network, a new network links advertisement should be produced 👑.
The next three events concern area border routers only 💖.
(5) An intra-area route has been added, deleted, or modified in the routing table ✨. This may cause a new instance of a summary links advertisement (for this route) to be originated in each attached area (this includes the backbone) 🌈.
(6) An inter-area route has been added, deleted, or modified in the routing table 🙈. This may cause a new instance of a summary links advertisement (for this route) to be originated in each attached area (but NEVER for the backbone) 🔥.
(7) The router becomes newly attached to an area 💀. The router must then originate summary link advertisements into the newly attached area for all pertinent intra-area and inter-area routes in its routing table 🎀. See Section 12.4.3 for more details 🦋.
The last event concerns AS boundary routers only 💜.
(8) An external route gained through direct experience with an external routing protocol (like EGP) changes 🍓. This will cause the AS boundary router to originate a new instance of an external links advertisement 💅.
The construction of each type of link state advertisement is explained below 🫶. In general, these sections describe the contents of the advertisement body (i.e., the part coming after the 20-byte advertisement header) 🌸. For info on building the link state advertisement header, see Section 12.1 🧚.
12.4.1 Router links ✨
A router originates a router links advertisement for each area that it belongs to 👑. Such an advertisement describes the collected states of the router's links to the area 💖. It's flooded throughout that particular area, and no further 🌈.
The format of a router links advertisement is shown in Appendix A (Section A.4.2) 🙈. The first 20 bytes of the advertisement consist of the generic link state header discussed in Section 12.1 🔥. Router links advertisements have LS type = 1 💀. The router indicates whether it's willing to calculate separate routes for each IP TOS by setting (or resetting) the T-bit of the link state advertisement's Options field 🎀.
A router also indicates whether it's an area border router or an AS boundary router by setting the appropriate bits in its router links advertisements 🦋. This lets paths to those types of routers get saved in the routing table, for later processing of summary link advertisements and AS external link advertisements 💜.
The router links advertisement then describes the router's working connections (links) to the area 🍓. Each link is typed according to the kind of attached network 💅.
_________________________________________
(Figure not included in text version.)
Figure 15: Area 1 with IP addresses shown
Figure 16: Forwarding address example
_________________________________________Each link is also labelled with its Link ID 🫶. This ID gives a name to the entity on the other end of the link 🌸. Table 18 summarizes the values used for the type and Link ID fields 🧚.
Link type Description Link ID
____________________________________________________________________________
1 Point-to-point link Neighbor Router ID
2 Link to transit network Interface address of Designated Router
3 Link to stub network IP network number
4 Virtual link Neighbor Router IDTable 18: Link descriptions in the router links advertisement.
In addition, the Link Data field is specified for each link 👑. This field gives 32 bits of extra information for the link 💖. For links to routers and transit networks, this field specifies the IP interface address of the associated router interface (this is needed by the routing table calculation, see Section 16.3) ✨. For links to stub networks, this field specifies the network's IP address mask 🌈.
Finally, the cost of using the link for output 💅 gets specified. It can be a different cost for each type of service, if you want. The output cost of a link is configurable ⚙️, and it MUST always be non-zero 🔢.
To walk through how the list of link records gets built 🧚, say a router wants to build a router links advertisement for an Area A. The router looks through its collection of interface data structures, and for each interface it does this:
- If the attached network does not belong to Area A, no links get added to the advertisement, and the next interface SHOULD be examined 🙈
- Else, if the state of the interface is Down, no links are added.
- Else, if the state of the interface is Point-to-Point, then add links according to the following:
- If the neighboring router is fully adjacent, add a Type 1 link (point-to-point) if this is an interface to a point-to-point network, or add a type 4 link (virtual link) if this is a virtual link. The Link ID SHOULD be set to the Router ID of the neighboring router, and the Link Data SHOULD specify the interface IP address 💖
- If this is a numbered point-to-point network (i.e, not a virtual link and not an unnumbered point-to-point network) and the neighboring router's IP address is known, add a Type 3 link (stub network) whose Link ID is the neighbor's IP address, whose Link Data is the mask
0xffffffffindicating a host route, and whose cost is the interface's configured output cost.
- Else if the state of the interface is Loopback, add a Type 3 link (stub network) as long as this is not an interface to an unnumbered serial line. The Link ID SHOULD be set to the IP interface address, the Link Data set to the mask
0xffffffff(indicating a host route), and the cost set to 0 🦋 - Else if the state of the interface is Waiting, add a Type 3 link (stub network) whose Link ID is the IP network number of the attached network and whose Link Data is the attached network's address mask ⏳
- Else, there has been a Designated Router selected for the attached network. If the router is fully adjacent to the Designated Router, or if the router itself is Designated Router and is fully adjacent to at least one other router, add a single Type 2 link (transit network) whose whose link ID is the IP interface address of the attached network's Designated Router (which may be the router itself) and whose Link Data is the interface IP address. Otherwise, add a link as if the interface state were Waiting (see above) 🌈
Unless otherwise specified, the cost of each link generated by the above procedure is equal to the output cost of the associated interface. Heads up though: on serial lines, one single interface can generate multiple links 🍓
After all the router interfaces have been considered, host links get added to the advertisement by checking the list of attached hosts 👀. A host route is represented as a Type 3 link (stub network) whose link ID is the host's IP address and whose Link Data is the mask of all ones (0xffffffff) ✨
As an example, let's look at the router links advertisements generated by router RT3, as pictured in Figure 6 🎀. The area containing RT3 (Area 1) has been redrawn, with actual network addresses, in Figure 15. Assume the last byte of all of RT3's interface addresses is 3, giving it the interface addresses 192.1.1.3 and 192.1.4.3, and that the other routers have similar addressing schemes. Also assume that all links are functional, and that Router IDs are assigned as the smallest IP interface address 🧠
RT3 originates two router links advertisements, one for Area 1 and one for the backbone 💅. Assume that router RT4 has been selected as the Designated router for network 192.1.1.0. RT3's router links advertisement for Area 1 is shown below. It shows that RT3 has two connections to Area 1: a link to the transit network 192.1.1.0 and a link to the stub network 192.1.4.0. The transit network is identified by the IP interface of its Designated Router (i.e., the Link ID = 192.1.1.4, which is the Designated Router RT4's IP interface to 192.1.1.0) 🌸. RT3 has also indicated that it is capable of calculating separate routes based on IP TOS, by setting the T-bit in the Options field. And it has indicated that it is an area border router 👑
; RT3's router links advertisement for Area 1
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
Link State ID = 192.1.1.3 ;RT3's Router ID
Advertising Router = 192.1.1.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;RT3 is an area border router
#links = 2
Link ID = 192.1.1.4 ;IP address of Designated Router
Link Data = 192.1.1.3 ;RT3's IP interface to net
Type = 2 ;connects to transit network
# other metrics = 0
TOS 0 metric = 1
Link ID = 192.1.4.0 ;IP Network number
Link Data = 0xffffff00 ;Network mask
Type = 3 ;connects to stub network
# other metrics = 0
TOS 0 metric = 2Next up is RT3's router links advertisement for the backbone 🌈. It shows that RT3 has a single attachment to the backbone, via an unnumbered point-to-point link to router RT6. RT3 has again indicated that it is TOS-capable, and that it is an area border router 🦋
; RT3's router links advertisement for the backbone
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
Link State ID = 192.1.1.3 ;RT3's router ID
Advertising Router = 192.1.1.3 ;RT3's router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;RT3 is an area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.0 ;Interface to unnumbered SL
Type = 1 ;connects to router
# other metrics = 0
TOS 0 metric = 8Even though RT3 has indicated that it is TOS-capable in the examples above, only a single metric (the TOS 0 metric) has been specified for each interface. Different metrics can be specified for each TOS 🎀. The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
As an example, suppose the point-to-point link between routers RT3 and RT6 in Figure 15 is a satellite link 🛰️. The AS administrator MAY want to encourage the use of the line for high bandwidth traffic. This would be done by setting the metric artificially low for that TOS. Router RT3 would then originate the following router links advertisement for the backbone (IP TOS 8 = high bandwidth) 🔥
; RT3's router links advertisement for the backbone
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 1 ;indicates router links
Link State ID = 192.1.1.3 ;RT3's Router ID
Advertising Router = 192.1.1.3
bit E = 0 ;not an AS boundary router
bit B = 1 ;RT3 is an area border router
#links = 1
Link ID = 18.10.0.6 ; Neighbor's Router ID
Link Data = 0.0.0.0 ;Interface to unnumbered SL
Type = 1 ;connects to router
# other metrics = 1
TOS 0 metric = 8
TOS = 8 ;High bandwidth
metric = 1 ;traffic preferred12.4.2 Network links ✨
A network links advertisement is generated for every transit multi-access network. (A transit network is a network having two or more attached routers 🌐.) The network links advertisement describes all the routers that are attached to the network.
The Designated Router for the network originates the advertisement. The Designated Router originates the advertisement only if it is fully adjacent to at least one other router on the network. The network links advertisement is flooded throughout the area that contains the transit network, and no further 🛑. The networks links advertisement lists those routers that are fully adjacent to the Designated Router, and each fully adjacent router is identified by its OSPF Router ID. The Designated Router includes itself in this list 💜.
The Link State ID for a network links advertisement is the IP interface address of the Designated Router. This value, masked by the network's address mask (which is also contained in the network links advertisement), yields the network's IP address 🧩.
A router that has formerly been the Designated Router for a network, but is no longer, SHOULD flush the network links advertisement that it had previously originated 🧹. This advertisement is no longer used in the routing table calculation. It gets flushed by prematurely incrementing the advertisement's age to MaxAge and reflooding (see Section 14.1).
As an example of a network links advertisement, again look at the area configuration in Figure 6 🗺️. Network links advertisements are originated for network N3 in Area 1, networks N6 and N8 in Area 2, and network N9 in Area 3. Assuming that router RT4 has been selected as the Designated Router for network N3, the following network links advertisement is generated by RT4 on behalf of network N3 (see Figure 15 for the address assignments) 💖
; network links advertisement for network N3
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 2 ;indicates network links
Link State ID = 192.1.1.4 ;IP address of Designated Router
Advertising Router = 192.1.1.4 ;RT4's Router ID
Network Mask = 0xffffff00
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID12.4.3 Summary links 🦋
Each summary link advertisement describes a route to a single destination. Summary link advertisements are flooded throughout a single area only 🫶. The destination described is one that is external to the area, yet still belongs to the Autonomous System.
The DefaultDestination can also be specified in summary link advertisements 🌟. This is used when implementing OSPF's stub area functionality (see Section 3.6). In a stub area, instead of importing external routes, each area border router originates a "default summary link" (Link State ID = DefaultDestination) into the area.
Summary link advertisements are originated by area border routers 👑. The precise summary routes to advertise into an area are determined by examining the routing table structure (see Section 11). Only intra-area routes are advertised into the backbone. Both intra-area and inter-area routes are advertised into the other areas. To determine which routes to advertise into an attached Area A, each
routing table entry gets run through these checks, in this exact order, bestie 🫶
- okay so ONLY Destination types of network and AS boundary router get advertised in summary link advertisements 🌸. If the routing table entry's Destination type is area border router, examine the next routing table entry, no drama 💅
- AS external routes are NEVER advertised in summary link advertisements 🚫. If the routing table entry has Path-type type 1 external or type 2 external, examine the next routing table entry 💀
- Else, if the area associated with this set of paths is the Area A itself, do not generate a summary link advertisement for the route.[14] 🙈
- Else, if the destination of this route is an AS boundary router, generate a Type 4 link state advertisement for the destination, with Link State ID equal to the AS boundary router's ID and metric equal to the routing table entry's cost. These advertisements SHOULD NOT be generated if area A has been configured as a stub area 😭
- Else, the Destination type is network. If this is an inter-area route, generate a Type 3 advertisement for the destination, with Link State ID equal to the network's address and metric equal to the routing table cost 🌈
- The one remaining case is an intra-area route to a network, which means the network lives in one of the router's directly attached areas ✨. In general, this information MUST be condensed before it shows up in summary link advertisements. Remember that an area is defined as a list of address ranges, each range being an [address,mask] pair. A single Type 3 advertisement MUST be made for each range, with Link State ID equal to the range's address and cost equal to the smallest cost of any of the component networks 🧚
If virtual links are being used to provide or increase connectivity of the backbone, routing information about the backbone networks SHOULD NOT be condensed before it gets summarized into the virtual links' transit areas. Put another way, the backbone ranges SHOULD be ignored when originating summary links into these areas. You can figure out whether virtual links exist during the shortest path calculation for the backbone (see Section 16.1) 🦋
In addition, if area A has been configured as a stub area and the router is an area border router, it SHOULD advertise a default summary link into Area A 🎀. The Link State ID for that advertisement SHOULD be set to DefaultDestination, and the metric gets set to the (per-area) configurable parameter StubDefaultCost 💜
If a router advertises a summary advertisement for a destination that then becomes unreachable, the router MUST then flush the advertisement from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Also, if the destination is still reachable but can no longer be advertised under the procedure above (for example, it's now an inter-area route when it used to be an intra-area route tied to some non-backbone area, so it's no longer advertisable to the backbone), the advertisement SHOULD also be flushed from the routing domain 🥀
For an example of summary link advertisements, think back to the area configuration in Figure 6. Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, so they're the ones originating summary links advertisements 👑. Let's zoom in on RT4 🔥. Its routing table was calculated as in the example in Section 11.3. RT4 originates summary link advertisements into both the backbone and Area 1. Into the backbone, RT4 sends separate advertisements for each of the networks N1-N4. Into Area 1, RT4 sends separate advertisements for networks N6-N8 and the AS boundary routers RT5,RT7. It also condenses host routes Ia and Ib into a single summary advertisement. Last but not least, the routes to networks N9,N10,N11 and host H9 get advertised by a single summary link. That condensation was originally done by the router RT11 🍓
These advertisements are illustrated graphically in Figures 7 and 8. Two of the summary link advertisements originated by router RT4 are below 🌸. The actual IP addresses for the networks and routers in question were assigned in Figure 15.
; summary link advertisement for network N1,
; originated by router RT4 into the backbone
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 3 ;indicates summary link to IP net
Link State ID = 192.1.2.0 ;N1's IP network number
Advertising Router = 192.1.1.4 ;RT4's ID
TOS = 0
metric = 4
; summary link advertisement for AS boundary router RT7
; originated by router RT4 into Area 1
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 4 ;indicates summary link to ASBR
Link State ID = router RT7's ID
Advertising Router = 192.1.1.4 ;RT4's ID
TOS = 0
metric = 14Summary link advertisements are about a single destination (an IP network or an AS boundary router) 💖. But for one destination there MAY be separate sets of paths, and therefore separate routing table entries, for each Type of Service 🎀. ALL of these entries MUST be considered when building the summary link advertisement for that destination, and a single advertisement MUST specify the separate costs (if they exist) for each TOS 🫶. The encoding of TOS in OSPF link state advertisements is described in Section 12.3 ✨
Clearing the T-bit in the Options field of a summary link advertisement means there's a TOS 0 path to the destination but no paths for non-zero TOS 🙈. This can happen when non-TOS capable routers exist in the routing domain (see Section 2.4) 🦋
12.4.4 AS external links 🌈
AS external link advertisements describe routes to destinations outside the Autonomous System 🌍. Most of them describe routes to specific external destinations. But a default route for the Autonomous System can be described in an AS external advertisement by setting the advertisement's Link State ID to DefaultDestination (0.0.0.0) 💅. AS external link advertisements are originated by AS boundary routers. An AS boundary router originates a single AS external link advertisement for each external route it has learned, either through another routing protocol (such as EGP) or through configuration information 🧚
In general, AS external link advertisements are the only type of link state advertisement that gets flooded throughout the entire Autonomous System 👑. Every other type is specific to a single area. HOWEVER, AS external advertisements are not flooded into or throughout stub areas (see Section 3.6). That's how the link state database gets smaller for routers inside stub areas 🥀
The metric advertised for an external route can be one of two types 💜. Type 1 metrics are comparable to the link state metric. Type 2 metrics are assumed to be larger than the cost of any intra-AS path. Just like with summary link advertisements, if separate paths exist based on TOS, separate TOS costs can be included in the AS external link advertisement. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. If the T-bit of the advertisement's Options field is clear, no non-zero TOS paths to the destination exist 🫧
If a router advertises an AS external link advertisement for a destination that then becomes unreachable, the router MUST then flush the advertisement from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1) 😭
For an example of AS external link advertisements, look at the AS pictured in Figure 6 one more time 🎀. There are two AS boundary routers: RT5 and RT7. RT5 originates three external link advertisements, for networks N12-N14. RT7 originates two external link advertisements, for networks N12 and N15. Say RT7 learned its route to N12 via EGP, and it wants to advertise a Type 2 metric to the AS. RT7 would then originate the following advertisement for N12 🍓
; AS external link advertisement for network N12,
; originated by router RT7
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 5 ;indicates AS external link
Link State ID = N12's IP network number
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
TOS = 0
metric = 2
Forwarding address = 0.0.0.0In that example, the forwarding address field is set to 0.0.0.0, which means packets for the external destination should be forwarded to the advertising OSPF router (RT7). That's not always desirable 🙃. Check out the example in Figure 16. There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of them, RTA, is exchanging EGP information with the non-OSPF router RTX 👀. So RTA has to originate AS external link state advertisements for the destinations it learned from RTX. By using the AS external advertisement's forwarding address field, RTA can say that packets for those destinations get forwarded directly to RTX ✨. Without this feature, RTB and RTC would take an extra hop to reach those destinations 🌸
Note that when the forwarding address field is non-zero, it SHOULD point to a router belonging to another Autonomous System 🫶
A forwarding address can also be specified for the default route 💖. For example, in Figure 16, RTA MAY want to say that all externally-destined packets SHOULD by default be forwarded to its EGP peer RTX. The resulting AS external link advertisement is below. Notice the Link State ID is set to DefaultDestination 🧚
; Default route, originated by router RTA
; Packets forwarded through RTX
LS age = 0 ;always true on origination
Options = (T-bit|E-bit) ;TOS-capable
LS type = 5 ;indicates AS external link
Link State ID = DefaultDestination ; default route
Advertising Router = Router RTA's ID
bit E = 1 ;Type 2 metric
TOS = 0
metric = 1
Forwarding address = RTX's IP addressNow, in Figure 16, imagine instead that both RTA and RTB exchange EGP information with RTX 🔥. In that case, RTA and RTB would originate the same set of external advertisements. If those advertisements specify the same metric, they'd be functionally equivalent, since they'd name the same destination and forwarding address (RTX). That's a clear duplication of effort 🙈. If only one of RTA or RTB originated the set, the routing would stay the same and the link state database would shrink 🌈. But it MUST be unambiguously defined which router originates the advertisements (otherwise neither MAY, or the identity of the originator MAY oscillate) 😭. So the following rule is established: if two routers, both reachable from one another, originate functionally equivalent AS external advertisements (meaning same destination, cost and non-zero forwarding address), then the advertisement originated by the router with the highest OSPF Router ID is the one used. The router with the lower OSPF Router ID can then flush its advertisement. Flushing a link state advertisement is discussed in Section 14.1 💅
13. The Flooding Procedure ✨
Link State Update packets are the mechanism for flooding link state advertisements 🦋. A Link State Update packet MAY contain several distinct advertisements, and floods each advertisement one hop further from its
13. The Flooding Procedure ✨
okay so, Link State Update packets are the thing that actually carries link state advertisements around the network 📦. A single Link State Update packet can hold several distinct advertisements, and each one gets flooded one hop further away from its point of origination. To make the flooding procedure reliable, each advertisement MUST be acknowledged separately 🫶. Acknowledgments go out in Link State Acknowledgment packets, and lots of separate acknowledgments can be bundled into one packet.
The flooding procedure kicks off when a Link State Update packet has been received. Before the packet even gets handed to flooding, it goes through a bunch of consistency checks (see Section 8.2) 🔍. Two things are already settled by then: the packet has been tied to a particular neighbor, and to a particular area. If the neighbor is in a state lesser than Exchange, the packet SHOULD be dropped without any further processing 🙅♀️.
Every link state advertisement is tied to a specific area, except AS external links 🌍. The catch is that link state advertisements don't actually have an area field. So the advertisement's area MUST be deduced from the Link State Update packet header 🕵️♀️.
For each link state advertisement inside the packet, these steps happen:
(1) Validate the advertisement's link state checksum. If the checksum is invalid, toss the advertisement and grab the next one from the Link State Update packet 🗑️.
(2) Check the advertisement's LS type. If the LS type is unknown, toss it and grab the next one from the Link State Update Packet. This specification defines LS Types 1-5 (see Section 4.3) 📋.
(3) Else if this is an AS external advertisement (LS type = 5), and the area has been configured as a stub area, toss it and grab the next one from the Link State Update Packet. AS external advertisements are not flooded into/throughout stub areas (see Section 3.6) 🚫.
(4) Else if the advertisement's age is equal to MaxAge, and there is currently no instance of the advertisement in the router's link state database, then:
- (a) Acknowledge receipt of the advertisement by sending a Link State Acknowledgment packet back to the sending neighbor (see Section 13.5) 💌.
- (b) Purge all outstanding requests for equal or previous instances of the advertisement from the sending neighbor's Link State Request list (see Section 10) 🧹.
- (c) If the sending neighbor is in state Exchange or in state Loading, install the MaxAge advertisement in the link state database. Otherwise, just discard it. Either way, look at the next advertisement (if any) listed in the Link State Update packet ➡️.
(5) Otherwise, find the instance of this advertisement that's currently in the router's link state database. If there is no database copy, or the received advertisement is more recent than the database copy (see Section 13.1 below for how "more recent" gets decided) then the following steps MUST be performed 🆕:
- (a) If there is already a database copy, and it was installed less than MinLSInterval seconds ago, discard the new advertisement (without acknowledging it) and look at the next advertisement (if any) listed in the Link State Update packet ⏳.
- (b) Otherwise, immediately flood the new advertisement out some subset of the router's interfaces (see Section 13.3). In some cases (e.g., the state of the receiving interface is DR and the advertisement was received from a router other than the Backup DR) the advertisement will get flooded right back out the receiving interface. This occurrence should be noted for later use by the acknowledgment process (Section 13.5) 📝.
- (c) Remove the current database copy from all neighbors' Link state retransmission lists 🧽.
- (d) Install the new advertisement in the link state database, replacing the current database copy. This may cause the routing table calculation to be scheduled. Also, timestamp the new advertisement with the current time (i.e., the time it was received). The flooding procedure cannot overwrite the newly installed advertisement until MinLSInterval seconds have passed. The installation process is covered further in Section 13.2 🛠️.
- (e) Possibly acknowledge receipt of the advertisement by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5 📬.
- (f) If this new link state advertisement says it was originated by this router itself, the router MUST advance the advertisement's link state sequence number and issue a new instance of the advertisement (see Section 13.4) 🪞.
(6) Else, if there is an instance of the advertisement on the sending neighbor's Link state request list, then an error has happened in the Database Description process 😬. In this case, restart the Database Description process by generating the neighbor event BadLSReq for the sending neighbor, and stop processing the Link State Update packet 🔄.
(7) Else, if the received advertisement is the same instance as the database copy (i.e., neither one is more recent), the following two steps SHOULD be performed:
- (a) If the advertisement is listed in the Link state retransmission list for the receiving adjacency, the router itself is waiting on an acknowledgment for this advertisement. The router SHOULD treat the received advertisement as an acknowledgment by removing it from the Link state retransmission list. This is called an "implied acknowledgment" ✨. Its occurrence should be noted for later use by the acknowledgment process (Section 13.5).
- (b) Possibly acknowledge receipt of the advertisement by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5 💕.
(8) Else, the database copy is more recent. Note an unusual event to network management, discard the advertisement, and process the next link state advertisement contained in the packet 🚨.
13.1 Determining which link state is newer
When a router runs into two instances of a link state advertisement, it MUST figure out which one is more recent 👀. This came up above when comparing a received advertisement to the database copy. The same comparison MUST also be done during the database exchange procedure that happens when adjacencies come up 🤝.
A link state advertisement is identified by its LS type, Link State ID and Advertising Router. For two instances of the same advertisement, the LS sequence number, LS age and LS checksum fields decide which one is newer:
- The advertisement with the newer LS sequence number is more recent. See Section 12.1.6 for an explanation of the LS sequence number space. If both instances have the same LS sequence number, then:
- If the two instances have different LS checksums, the instance with the larger LS checksum (read as a 16-bit unsigned integer) is considered more recent 🔢.
- Else, if only one of the instances is of age MaxAge, the MaxAge instance is considered more recent ⌛.
- Else, if the ages of the two instances differ by more than MaxAgeDiff, the instance with the smaller (younger) age is considered more recent 🍼.
- Else, the two instances are considered identical 👯.
13.2 Installing link state advertisements in the database
Installing a new link state advertisement in the database, whether it came from flooding or was just self-originated, may cause the routing table structure to be recalculated 🧮. The contents of the new advertisement SHOULD be compared to the old instance, if one is present. If there's no difference, there's no need to recalculate the routing table 🙌. (Note that even if the contents are the same, the LS checksum will probably be different, since the checksum covers the LS sequence number.)
If the contents are different, the following pieces of the routing table MUST be recalculated, depending on the LS type field 🗺️:
Router links, network links: The entire routing table MUST be recalculated, starting with the shortest path calculations for each area (not just the area whose topological database has changed). The reason the shortest path calculation can't be limited to the one changed area is that AS boundary routers may belong to multiple areas. A change in the area currently providing the best route may force the router to use an intra-area route provided by a different area.[15]
Summary link: The best route to the destination described by the summary link advertisement MUST be re-examined (see Section 16.5). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS external link advertisements 🔎.
AS external link: The best route to the destination described by the AS external link advertisement MUST be re-examined (see Section 16.6) 🧭.
Also, any old instance of the advertisement MUST be removed from the database when the new advertisement is installed 🗑️. That old instance MUST also be removed from all neighbors' Link state retransmission lists (see Section 10).
13.3 Next step in the flooding procedure
When a new (and more recent) advertisement has been received, it MUST be flooded out some set of the router's interfaces 📤. This section covers the second half of the flooding procedure (the first half being the processing in Section 13). It's all about picking the outgoing interfaces and adding the advertisement to the right neighbors' Link state retransmission lists. This part also handles keeping the neighbors' Link state request lists up to date 🗂️.
This section applies just as much to an advertisement the router itself has just originated (see Section 12.4). For those, this section is the entire flooding procedure. Section 13 doesn't run at all, since the advertisement never came from a neighbor and so doesn't need to be acknowledged 🙅♀️.
Depending on the advertisement's LS type, it can only be flooded out certain interfaces. These are called the eligible interfaces 🎯:
AS external links (LS Type = 5): AS external links get flooded throughout the entire AS, except for stub areas (see Section 3.6). The eligible interfaces are all of the router's interfaces, excluding virtual links and any interfaces attaching to stub areas 🌐.
All other types: All other types are specific to a single area (Area A). The eligible interfaces are all the interfaces attaching to Area A. If Area A is the backbone, this includes all the virtual links 🦋.
Link state databases MUST remain synchronized over all adjacencies associated with the eligible interfaces above 💞. This is done by running the following steps on each eligible interface. It's worth knowing that this procedure MAY decide not to flood a link state advertisement out a particular interface, if there's a high probability the attached neighbors already received it. However, in those cases the flooding procedure MUST be absolutely sure the neighbors eventually do receive the advertisement, so the advertisement is still added to each adjacency's Link state retransmission list 🫶. For each eligible interface:
(1) okay so first, we check every neighbor attached to this interface and figure out whether they must receive the new advertisement 👀 The following steps run for each neighbor:
- (a) If the neighbor is in a lesser state than Exchange, it doesn't take part in flooding, so we skip to the next neighbor 🙅♀️
- (b) Else, if the adjacency is not yet full (neighbor state is Exchange or Loading), we check the Link state request list tied to this adjacency. If the new advertisement is on that list, the neighbor already has an instance of it 🧐 Then we compare the new advertisement to the neighbor's copy:
- If the new advertisement is less recent, we try the next neighbor.
- If the two copies are the same instance, we delete the advertisement from the Link state request list and try the next neighbor. [16]
- Else, the new advertisement is more recent. We delete it from the Link state request list.
- (c) If the new advertisement was received from this neighbor, we try the next neighbor.
- (d) At this point we're not positive the neighbor has an up-to-date instance of the new advertisement, so we add it to the Link state retransmission list for the adjacency 🔁 This is what makes flooding reliable: the advertisement keeps getting retransmitted at intervals until an acknowledgment comes back from the neighbor.
(2) The router must now decide whether to flood the new link state advertisement out this interface. If in the previous step the advertisement was NOT added to any of the Link state retransmission lists, there's no need to flood it, so we examine the next interface 🙈
(3) If the new advertisement was received on this interface, and it came from either the Designated Router or the Backup Designated Router, chances are all the neighbors have already got it. So we examine the next interface 💅
(4) If the new advertisement was received on this interface, and the interface state is Backup (i.e., the router itself is the Backup Designated Router), we examine the next interface. The Designated Router does the flooding on this interface. If the Designated Router fails, this router ends up retransmitting the updates 🫶
(5) If this step is reached, the advertisement must be flooded out the interface. Send a Link State Update packet (with the new advertisement as contents) out the interface. The advertisement's LS age must be incremented by InfTransDelay (which must be > 0) when it's copied into the outgoing packet, until the LS age field reaches its maximum value of MaxAge ⏰
On broadcast networks, Link State Update packets are multicast. The destination IP address depends on the state of the interface. If the interface state is DR or Backup, use the address AllSPFRouters. Otherwise, use AllDRouters 📡
On non-broadcast, multi-access networks, separate Link State Update packets must be sent, as unicasts, to each adjacent neighbor (i.e., those in state Exchange or greater). The destination IP addresses for these packets are the neighbors' IP addresses 💌
13.4 Receiving self-originated link state ✨
It's a super common occurrence to receive a self-originated link state advertisement via the flooding procedure 🙃 If the advertisement received is a newer instance than the last instance the router actually originated, the router must take special action 🚨
Getting one of these means there are link state advertisements in the routing domain that were originated before the last time the router was restarted. In this case, the router must advance the sequence number for the advertisement to one past the received sequence number, and originate a new instance of the advertisement 🔢
Also, if the type of the advertisement is Summary link or AS external link, the router may no longer have an (advertisable) route to the destination. In that case, the advertisement should be flushed from the routing domain by incrementing its LS age to MaxAge and reflooding it (see Section 14.1) 🗑️
13.5 Sending Link State Acknowledgment packets 🎀
Each newly received link state advertisement must be acknowledged. This is usually done by sending Link State Acknowledgment packets. However, acknowledgments can also be accomplished implicitly by sending Link State Update packets (see step 7a of Section 13) 🫧
Many acknowledgments can be grouped together into a single Link State Acknowledgment packet. Such a packet is sent back out the interface that received the advertisements. It can be sent in one of two ways: delayed and sent on an interval timer, or sent directly (as a unicast) to a particular neighbor. Which strategy gets used depends on the circumstances surrounding the receipt of the advertisement 🧠
Delayed acknowledgments are lowkey genius because they facilitate packaging multiple acknowledgments in a single packet 📦 They let a single packet acknowledge several neighbors at once (through multicasting), and they randomize the acknowledgment packets sent by the various routers attached to a multi-access network 🎲 The fixed interval between a router's delayed transmissions must be short (less than RxmtInterval), or needless retransmissions will ensue 😬
Direct acknowledgments are sent to a particular neighbor in response to receiving duplicate link state advertisements. They're sent as unicasts, and they go out immediately when the duplicate is received ⚡
The precise procedure for sending Link State Acknowledgment packets is described in Table 19. The circumstances surrounding the receipt of the advertisement are listed in the left column. The acknowledgment action then taken is listed in one of the two right columns. This action depends on the state of the concerned interface, and interfaces in state Backup behave differently from interfaces in all other states 📋
Action taken in state
Circumstances Backup All other states
______________________________________________________________
Action taken in state
Circumstances Backup All other states
______________________________________________________________
Advertisement has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
______________________________________________________________
Advertisement is Delayed ack- Delayed ack-
more recent than nowledgment sent nowledgment sent.
database copy, but if advertisement
was not flooded received from DR,
back out receiving otherwise do noth-
interface ing
______________________________________________________________
Advertisement is a Delayed ack- No acknowledgment
duplicate, and was nowledgment sent sent.
treated as an im- if advertisement
plied acknowledg- received from DR,
ment (see Section otherwise do noth-
13, step 7a). ing
______________________________________________________________
Advertisement is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
______________________________________________________________
Advertisement's age Direct acknowledg- Direct acknowledg-
is equal to MaxAge, ment sent. ment sent.
and there is no
current instance of
the advertisement in
the link state
database (see
Section 13, step 4).
Table 19: Sending link state acknowledgements.Delayed acknowledgments must be delivered to all adjacent routers associated with the interface 📬 On broadcast networks, this is done by sending the delayed Link State Acknowledgment packets as multicasts. The Destination IP address depends on the state of the interface. If the state is DR or Backup, the destination AllSPFRouters is used. In other states, the destination AllDRouters is used. On non-broadcast networks, delayed acks must be unicast separately over each adjacency (neighbor whose state is >= Exchange) 💌
The reasoning behind sending these packets as multicasts is best explained by an example 🧩 Consider the network configuration depicted in Figure 15. Suppose RT4 has been elected as DR, and RT3 as Backup for the network N3. When router RT4 floods a new advertisement to network N3, it's received by routers RT1, RT2, and RT3. These routers won't flood the advertisement back onto net N3, but they still must make sure their topological databases stay synchronized with their adjacent neighbors 👯 So RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3. Likewise, RT4 and RT3 are both waiting to see acknowledgments from RT1 and RT2. This is best achieved by sending the acknowledgments as multicasts 📣
The reason the acknowledgment logic for Backup DRs is slightly different is that they behave differently during the flooding of link state advertisements (see Section 13.3, step 4) 🤓
13.6 Retransmitting link state advertisements 🔁
Advertisements flooded out an adjacency are placed on the adjacency's Link state retransmission list. To make sure flooding is reliable, these advertisements are retransmitted until they're acknowledged 💪 The length of time between retransmissions is a configurable per-interface value, RxmtInterval. If this is set too low for an interface, needless retransmissions will ensue 🙄 If it's set too high, the speed of the flooding, in the face of lost packets, may be affected 🐢
Several retransmitted advertisements may fit into a single Link State Update packet. When advertisements are to be retransmitted, only the number fitting in a single Link State Update packet should be transmitted. Another packet of retransmissions can be sent when some of the advertisements are acknowledged, or on the next firing of the retransmission timer ⏱️
Link State Update packets carrying retransmissions are always sent as unicasts (directly to the physical address of the neighbor). They are never sent as multicasts 🚫 Each advertisement's LS age must be incremented by InfTransDelay (which must be > 0) when copied into the outgoing packet, until the LS age field reaches its maximum value of MaxAge 🕰️
If the adjacent router goes down, retransmissions may occur until the adjacency is destroyed by OSPF's Hello Protocol. When the adjacency is destroyed, the Link state retransmission list is cleared 🧹
13.7 Receiving link state acknowledgments 💖
Many consistency checks have been made on a received Link State Acknowledgment packet before it's handed to the flooding procedure. In particular, it has been associated with a particular neighbor. If this neighbor is in a lesser state than Exchange, the packet is discarded 🗑️
Otherwise, for each acknowledgment in the packet, the following steps are performed:
- Does the advertisement acknowledged have an instance on the Link state retransmission list for the neighbor? If not, examine the next acknowledgment. Otherwise:
- If the acknowledgment is for the same instance that is contained on the list, remove the item from the list and examine the next acknowledgment. Otherwise:
- Log the questionable acknowledgment, and examine the next one 📝
14. Aging The Link State Database 🕰️
okay so every link state advertisement has an age field ⏳, and it's measured in seconds. The age goes up while the advertisement is chilling in a router's database. And when a copy gets packed into a Link State Update Packet to flood out a particular interface, the age also gets bumped by InfTransDelay 💅
An advertisement's age never goes past MaxAge, no cap 🙅♀️. Advertisements sitting at MaxAge are not used in the routing table calculation. As a router ages its database, an advertisement's age can reach MaxAge[17]. When that happens, the router must attempt to flush the advertisement from the routing domain. The move is honestly simple: it reflloods the MaxAge advertisement as if it were a newly originated one (see Section 13.3) 🦋
When a Database summary list gets formed for a newly adjacent neighbor, any MaxAge advertisements in the link state database get added to the neighbor's Link state retransmission list instead of its Database summary list. See Section 10.3 for more details 🌸
A MaxAge advertisement is removed entirely from the router's link state database when a) it's no longer on any neighbor's Link state retransmission list, and b) none of the router's neighbors are in states Exchange or Loading. Bestie, that's the whole cleanup check 🧹
When the router is aging its link state database and an advertisement's age hits a multiple of CheckAge, its checksum should be verified. If the checksum is incorrect, a program or memory error has been detected, and at the very least the router itself should be restarted 🚨
Yikes, that last part is serious. A bad checksum means something inside the router is broken, not just a little hiccup.
14.1 Premature aging of advertisements ✨
A link state advertisement can be flushed from the routing domain by setting its age to MaxAge and then reflooding it. This procedure follows the same course as flushing an advertisement whose age has naturally reached MaxAge (see Section 14). In particular, the MaxAge advertisement is removed from the router's link state database as soon as a) it's no longer on any neighbor Link state retransmission list, and b) none of the router's neighbors are in states Exchange or Loading. We call setting an advertisement's age to MaxAge premature aging 💜
Premature aging is used when it's time for a self-originated advertisement's sequence number field to wrap 🌀. At that point, the current advertisement instance (with LS sequence number 0x7fffffff) must be prematurely aged and flushed from the routing domain before a new instance with sequence number 0x80000001 can be originated. See Section 12.1.6 for more information.
Premature aging can also be used when, for example, one of the router's previously advertised external routes is no longer reachable 🧭. In that situation, the router can flush its external advertisement from the routing domain via premature aging. This is preferable to the alternative, which is to originate a new advertisement for the destination specifying a metric of LSInfinity 🙈
A router may only prematurely age its own (self-originated) link state advertisements. These are the advertisements that have the router's own OSPF Router ID in the Advertising Router field 👑
15. Virtual Links 🌈
The single backbone area (Area ID = 0) can't be disconnected, or some areas of the Autonomous System become unreachable 😭. To establish and maintain backbone connectivity, virtual links can be configured through non-backbone areas. Virtual links serve to connect separate pieces of the backbone 🧩. Their two endpoints are area border routers, and the virtual link must be configured in both routers. Each router's configuration holds the other virtual endpoint (the other area border router) and the non-backbone area the two routers share, which is called the transit area. Virtual links cannot be configured through stub areas (see Section 3.6) 🚫
The virtual link gets treated as if it were an unnumbered point-to-point network (belonging to the backbone) joining the two area border routers. An attempt is made to establish an adjacency over the virtual link. Once that adjacency is up, the virtual link gets included in backbone router links advertisements, and OSPF packets for the backbone area flow over the adjacency. This is called a "virtual adjacency" 🦋
In each endpoint router, the cost and viability of the virtual link are discovered by looking at the routing table entry for the other endpoint router. (That entry's associated area must be the configured transit area.) There may actually be a separate routing table entry for each Type of Service, and these are called the virtual link's corresponding routing table entries 🍓. The Interface Up event happens for a virtual link when its corresponding TOS 0 routing table entry becomes reachable. Conversely, the Interface Down event happens when that TOS 0 entry becomes unreachable[18]. So in other words, the virtual link's viability depends on whether there's an intra-area path between the two endpoints through the transit area. Here are the other details, bestie:
- AS external links are NEVER flooded over virtual adjacencies. That would be duplicate work, since the same AS external links are already flooded throughout the virtual link's transit area. For this same reason, AS external link advertisements are not summarized over virtual adjacencies during the database exchange process 🙅
- The cost of a virtual link is NOT configured. Instead it's defined to be the cost of the intra-area path between the two defining area border routers. That cost shows up in the virtual link's corresponding routing table entry. When the cost of a virtual link changes, a new router links advertisement should be originated for the backbone area 💸
- Just like the cost and viability, the IP interface address for the virtual interface and the virtual neighbor's IP address are determined by the routing table build process (through construction of the routing table entry for the other endpoint). Those addresses are used when sending protocol packets over the virtual link 📬
- In each endpoint's router links advertisement for the backbone, the virtual link is represented as a link of link type
4, with Link ID set to the virtual neighbor's OSPF Router ID and Link Data set to the virtual interface's IP address. See Section 12.4.1 for more information. Also, it's possible there's a TOS 0 path but no non-zero TOS paths to the other endpoint router. In that case, non-zero TOS costs must be set toLSInfinityin the router links advertisement 💅 - When virtual links are configured for the backbone, information about backbone networks should not be condensed before being summarized for the transit areas. In other words, each backbone network should be advertised in a separate summary link advertisement, regardless of the backbone's configured area address ranges. See Section 12.4.3 for more information 🌷
- The time between link state retransmissions,
RxmtInterval, is configured for a virtual link. It should be well over the expected round-trip delay between the two routers. This can be hard to estimate for a virtual link, so it's better to err on the side of making it too large 🫶
16. Calculation Of The Routing Table 🧮
This section details the OSPF routing table calculation 🔥. Using its attached areas' link state databases as input, a router runs the following algorithm, building its routing table step by step. At each step, the router must access individual pieces of the link state databases (for example, a router links advertisement originated by a certain router). That access is done by the lookup function discussed in Section 12.2. The lookup process may return a link state advertisement whose LS age is equal to MaxAge. Such an advertisement should not be used in the routing table calculation, and it's treated just as if the lookup process had failed 💀
The OSPF routing table's organization is explained in Section 11. Two examples of the routing table build process are presented in Sections 11.2 and 11.3. This process can be broken into the following steps:
- The present routing table is invalidated. The routing table is built again from scratch. The old routing table is saved so that changes in routing table entries can be identified 🧼
- The intra-area routes are calculated by building the shortest path tree for each attached area. In particular, all routing table entries whose Destination type is "area border router" are calculated in this step. This step is described in two parts. First, the tree is constructed by only considering those links between routers and transit networks. Then the stub networks are incorporated into the tree 🌳
- The inter-area routes are calculated, through examination of summary link advertisements. If the router is attached to multiple areas (that is, it is an area border router), only backbone summary link advertisements are examined 🌉
- For those routing entries whose next hop is over a virtual link, a real (physical) next hop is calculated. The real next hop will be on one of the router's directly attached networks. This step only concerns routers having configured virtual links 🛣️
- Routes to external destinations are calculated, through examination of AS external link advertisements. The location of the AS boundary routers (which originate the AS external link advertisements) has been determined in steps 2-4 👑
Steps 2-5 are explained in more detail below. The explanations describe the calculations for TOS 0 only. It may also be necessary to perform each step (separately) for each of the non-zero TOS values[19]. For more information about building non-zero TOS routes, see Section 16.9 💖
Changes made to routing table entries as a result of these calculations can cause the OSPF protocol to take further actions. For example, a change to an intra-area route will cause an area border router to originate new summary link advertisements (see Section 12.4). See Section 16.7 for a complete list of the OSPF protocol actions resulting from routing table changes 🔁
16.1 Calculating the shortest-path tree for an area 🌲
This calculation yields the set of intra-area routes associated with an area (called Area A from here on). A router calculates the shortest-path tree using itself as the root[20]. The tree gets formed in two stages. In the first stage, only links between routers and transit networks are considered. Using the Dijkstra algorithm, a tree is formed from this subset of the link state database. In the second stage, leaves are added to the tree by considering the links to stub networks ✨
The procedure is explained using the graph terminology introduced in Section 2. The area's link state database is represented as a directed graph. The graph's vertices are routers, transit networks and stub networks. The first stage of the procedure concerns only the transit vertices (routers and transit networks) and their connecting links. Throughout the shortest path calculation, the following data is also associated with each transit vertex 🧠
Vertex (node) ID A 32-bit number uniquely identifying the vertex. For router vertices, this is the OSPF Router ID. For network vertices, this is the IP address of the network's Designated Router 🎀
16.1 Shortest-path tree calculation, but make it cute 🎀
A link state advertisement 💌 Every transit vertex comes with its own link state advertisement 🫶. For router vertices, that's a router links advertisement. For transit networks, it's a network links advertisement, which is actually originated by the network's Designated Router 👑. Either way, the advertisement's Link State ID is always equal to the above Vertex ID ✨.
- List of next hops 🦋 This is the list of next hops for the current shortest paths from the root to this vertex. There can be several shortest paths thanks to equal-cost multipath, which is literally so iconic 🌈. Each next hop tells you which outgoing router interface to use when forwarding traffic to the destination. On multi-access networks, the next hop also includes the IP address of the next router (if there is one) on the path toward the destination 🧚.
- Distance from root 📏 This is the link state cost of the current shortest path(s) from the root to the vertex. The link state cost of a path is the sum of the costs of its constituent links, as advertised in router links and network links advertisements 💅. One path is called "shorter" than another if it has a smaller link state cost 🍓.
okay so the first stage can be summed up like this 💖. At each iteration of the algorithm, there's a list of candidate vertices 🌸. The shortest paths from the root to these vertices haven't (necessarily) been found yet 🙈. The candidate vertex closest to the root gets added to the shortest-path tree, removed from the candidate list, and its adjacent vertices get checked for possible addition to or modification of the candidate list ✨. Then the algorithm goes again 🔁. It stops when the candidate list is empty 🫧.
Here's the first stage in detail 🎀. Remember, we're computing the shortest path tree for Area A, so every link state database lookup below is from Area A's database 💜.
(1) Set up the algorithm's data structures 🧚. Clear the candidate list. Start the shortest-path tree with only the root, which is the router doing the calculation 👑.
(2) Call the vertex that was just added to the tree vertex V 🦋. Check the link state advertisement for vertex V. This is a lookup in the area link state database by Vertex ID. Each link in the advertisement gives the cost to an adjacent vertex 💌. For each link described (say it joins vertex V to vertex W) 😭:
- (a) If it's a link to a stub network, move on to the next link in V's advertisement. Stub network links get handled in the second stage of the shortest path calculation 🌈.
- (b) Otherwise, W is a transit vertex (a router or transit network). Look up W's link state advertisement (router links or network links) in Area A's link state database 🔍. If that advertisement doesn't exist, or its age is equal to
MaxAge, or it doesn't have a link back to vertex V, move on to the next link in V's advertisement 💀. Both ends of a link must advertise it before it can be used for data traffic 🫶.[21] - (c) If vertex W is already on the shortest-path tree, move on to the next link in the advertisement 🍓.
- (d) If the cost of the link (from V to W) is
LSInfinity, the link should not be used for data traffic 🙅. In that case, move on to the next link in the advertisement 🌸. - (e) Work out the link state cost D of the resulting path from the root to vertex W 🧮. D is the sum of the link state cost of the already-calculated shortest path to vertex V and the advertised cost of the link between V and W. Then, depending on how D compares to it ✨:
- If D is greater than the value already on the candidate list for vertex W, examine the next link 💅.
- If D is equal to the value on the candidate list for vertex W, calculate the set of next hops that results from using the advertised link 🦋. The input to this calculation is the destination (W) and its parent (V). This calculation is shown in Section 16.1.1. This set of hops should be added to the next hop values already listed for W on the candidate list 🎀.
- If D is less than the value on the candidate list for vertex W, or if W isn't on the candidate list yet, set W's entry on the candidate list to a distance of D from the root 🚀. Also calculate the list of next hops that results from using the advertised link, and set the next hop values for W accordingly. The next hop calculation is described in Section 16.1.1. It takes the destination (W) and its parent (V) as input 🧚.
(3) If the candidate list is empty at this step, the shortest-path tree (of transit vertices) is completely built and this stage of the algorithm stops 🎉. Otherwise, pick the candidate vertex closest to the root, add it to the shortest-path tree, and remove it from the candidate list while you're at it 💖.
(4) Maybe modify the routing table 🗺️. For any routing table entries that get modified, the associated area is set to Area A, the path type is set to intra-area, and the cost is set to the newly discovered shortest path's calculated distance ✨.
If the newly added vertex is an area border router, add a routing table entry whose destination type is "area border router" 🌉. Copy the Options field from the associated router links advertisement into the routing table entry's Optional capabilities field 🫧.
If the newly added vertex is an AS boundary router, find the routing table entry of type "AS boundary router" for that destination 🛰️. Routers can belong to more than one area, so there may be several sets of intra-area paths to the AS boundary router, each using a different area 😵💫. But that routing table entry has to indicate a set of paths that all use a single area 💜. The area is picked like this: a set of intra-area paths with no virtual next hops is always preferred over a set where some virtual next hops appear[22] 🥇. If everything else is equal, the set with the lower cost wins 💅. Also, whenever an AS boundary router's routing table entry is added or modified, copy the Options from the associated router links advertisement into the entry's Optional capabilities field 🎀.
If the newly added vertex is a transit network, find the routing table entry for that network 🔎. The entry's destination ID is the IP network number, which you get by masking the Vertex ID (Link State ID) with its subnet mask (found in the associated network links advertisement) 🧠. If the routing table entry already exists (meaning there's already an intra-area route to that destination in the table), then several vertices have mapped to the same IP network 👯. This can happen when a new Designated Router is being set up, for example 👑. In that case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current entry's Link State Origin has a smaller Link State ID than the newly added vertex's link state advertisement 🫶.
If there's no routing table entry for the network (the usual case 🥰), add one for the IP network. Set the routing table entry's Link State origin to the newly added vertex's link state advertisement 🌷.
(5) Iterate the algorithm by going back to Step 2 🔁.
The stub networks get added to the tree in the second stage 🌳. In this stage, every router vertex is examined again 👀. The ones determined to be unreachable in the first phase get thrown out 🗑️. For each reachable router vertex (call it V), find its router links advertisement in the link state database 📜. Then check each stub network link in that advertisement and run these steps 💅:
(1) If the cost of the stub network link is LSInfinity, the link should not be used for data traffic 🙅. In that case, move on to the next stub network link in the advertisement 🌸.
(2) Otherwise, calculate the distance D of the stub network from the root 📐. D is the distance from the root to the router vertex (calculated in stage 1) plus the stub network link's advertised cost ➕. Compare this distance to the current best cost to the stub network 🔍. You do this by looking up the network's current routing table entry. If the calculated distance D is larger, move on to the next stub network link in the advertisement 🙃.
(3) If you reach this step, the stub network's routing table entry must be updated 🌟. Calculate the set of next hops that would result from using the stub network link. This calculation is shown in Section 16.1.1. The input is the destination (the stub network) and the parent vertex (the router vertex) 🧚. If D is the same as the current routing table cost, just add this set of next hops to the entry's list of next hops 🫧. In this case, the routing table already has a Link State origin. If that Link State origin is a router links advertisement whose Link State ID is smaller than V's Router ID, reset the Link State origin to V's router links advertisement 👑.
Otherwise D is smaller than the routing table cost 🚀. Overwrite the current routing table entry: set its cost to D and its list of next hops to the newly calculated set 💖. Set the entry's Link State origin to V's router links advertisement. Then move on to the next stub network link 🎀.
For all routing table entries added or modified in the second stage, the associated area is set to Area A and the path type is set to intra-area 🗺️. Once the list of reachable router links runs out, the second stage is done 🎉. At that point, all intra-area routes associated with Area A have been determined 💜.
The specification doesn't require that this two-stage method be used to calculate the shortest path tree 🙌. But if another algorithm is used, it has to produce an identical tree 👯. That's why it's important to note that links between transit vertices must be bidirectional in order to be included in the above tree ⚠️. It's also worth mentioning that algorithms exist for incrementally updating the shortest-path tree (see [BBN]) 🦋.
16.1.1 The next hop calculation 🧭
This section explains how to calculate the current set of next hops to use for a destination 💌. Each next hop is made up of the outgoing interface to use when forwarding packets to the destination, together with the next hop router (if there is one) 🫶. The next hop calculation gets invoked every time a shorter path to the destination is discovered 🔁. That can happen in either stage of the shortest-path tree calculation (see Section 16.1) 🌳. In stage 1, a shorter path is found when the destination is added to the candidate list, or when the destination's entry on the candidate list gets modified (Step 2e of Stage 1) 🍓. In stage 2, a shorter path is discovered each time the destination's routing table entry is modified (Step 3 of Stage 2) 🌈.
The set of next hops to use for the destination may get recalculated several times during the shortest-path tree calculation, as shorter and
shorter paths are discovered. ✨ In the end, the destination's routing table entry will always reflect the next hops from the absolute shortest path(s), bestie. 💅
Input to the next hop calculation is a) the destination and b) its parent in the current shortest path between the root (the calculating router, aka you) and the destination. The parent is always a transit vertex (i.e., always a router or a transit network). 🦋
If there is at least one intervening router in the current shortest path between the destination and the root, the destination just inherits the set of next hops from the parent. 🌸 Otherwise there are two cases:
In the first case, the parent vertex is the root (the calculating router itself). So the destination is either a directly connected network or a directly connected router. The next hop here is simply the OSPF interface connecting to the network/router, and no next hop router is required. 🧚
In the second case, the destination is a router and its parent vertex is a network. The list of next hops is then figured out by checking the destination's router links advertisement. For each link in that advertisement that points back to the parent network, the link's Link Data field gives you the IP address of a next hop router. 🎀 The outgoing interface can then be derived from that next hop IP address (or it can be inherited from the parent network). Iconic. 👑
16.2 Calculating the inter-area routes ✨
The inter-area routes are calculated by examining summary link advertisements. If the router has active attachments to multiple areas, only backbone summary link advertisements get examined. Routers attached to a single area examine that area's summary links instead. Either way, the summary links examined below are all part of a single area's link state database (call it Area A). 🫶
Summary link advertisements are originated by the area border routers. Each summary link advertisement in Area A is considered in turn. Remember that the destination described by a summary link advertisement is either a network (type 3 summary link advertisements) or an AS boundary router (type 4 summary link advertisements). For each summary link advertisement:
- If the cost specified by the advertisement is
LSInfinity, then examine the next advertisement. 🙈 - If the advertisement was originated by the calculating router itself, examine the next advertisement. 💀
- If the collection of destinations described by the summary link falls into one of the router's configured area address ranges (see Section 3.5) and that particular area address range is active, the summary link should be ignored. 🌈 "Active" means there are one or more reachable (by intra-area paths) networks contained in the area range. In this case, all addresses in the area range are assumed to be either reachable via intra-area paths, or else unreachable by any other means. Main character energy. ✨
- Else, call the destination described by the advertisement N, and the area border originating the advertisement BR. Look up the routing table entry for BR having A as its associated area. If no such entry exists for router BR (i.e., BR is unreachable in Area A), do nothing with this advertisement and consider the next one in the list. 🥀 Else, this advertisement describes an inter-area path to destination N, whose cost is the distance to BR plus the cost specified in the advertisement. Call the cost of this inter-area path IAC. 🔥
- Next, look up the routing table entry for the destination N. (The entry's Destination type is either Network or AS boundary router.) If no entry exists for N, or if the entry's path type is "AS external", install the inter-area path to N, with associated area A, cost IAC, next hop equal to the list of next hops to router BR, and advertising router equal to BR. 💖
- Else, if the paths present in the table are intra-area paths, do nothing with the advertisement. Intra-area paths are always preferred, no debate. 👑
- Else, the paths present in the routing table are also inter-area paths. Install the new path through BR if it is cheaper, overriding the paths in the routing table. Otherwise, if the new path is the same cost, add it to the list of paths that appear in the routing table entry. 🍓
16.3 Resolving virtual next hops 🦋
This step is only necessary in area-border routers that have configured virtual links. 🫧 In these routers, some of the routing table entries may have virtual next hops. That means one or more of the next hops installed in Sections 16.1 and 16.2 may be over a virtual link. However, when forwarding data traffic to a destination, the next hops must always be on a directly attached network. 🙅♀️
So in this section, each virtual next hop gets replaced by a real next hop. In the process a new routing table distance is calculated that may be smaller than the previously calculated distance. In that case, the list of next hops is pruned so that only the ones giving rise to the new shortest distance are included, and the routing table entry's distance is updated to match. 💅
______________________________________
(Figure not included in text version.)
Figure 17: Resolving virtual next hops
______________________________________This resolution of virtual next hops is only done for Destination types Network or AS Boundary router. Suppose one of a routing table entry's next hops is a virtual link. That's determined by the following combination: the routing table entry's path type is either intra-area or inter-area, the area associated with the routing table entry must be the backbone, yet the next hop belongs to a different area (the virtual link's transit area). 🌸
Let N be the above entry's destination, and A the virtual link's transit area. The real next hop (and new distance) is calculated as follows. Let D be a distance counter, and set the real next hop NH to null. Then, look up all the summary link advertisements for N in area A's database, and perform the following steps for each advertisement:[23]
- Call the border router that originated the advertisement BR. If there is no routing table entry for BR having A as its associated area (i.e., BR is unreachable through Area A), examine the next advertisement. 🙃
- Else, let X be the distance to BR via Area A. If the cost advertised by BR (call it Y) to the destination is
LSInfinity, examine the next summary link advertisement. Else, the cost to destination N through area border router BR is X+Y. 🧮 - If next hop NH is null, or X+Y is smaller than D, set D to X+Y and set the next hop NH to the next hop specified in router BR's routing table entry. 🎯
At this point the real next hop NH should be set, and the distance D calculated should be less than or equal to the cost originally specified in destination N's routing table entry. This same calculation should be done for all of N's virtual next hops. Then N's new cost gets set to the minimum calculated distance, with its new set of next hops being the combination of non-virtual and recalculated next hops that correspond to this (possibly same as original) distance. 🫶
Okay, real talk, resolving virtual next hops may produce unexpected results. ⚠️ After the virtual next hops are resolved, traffic that was originally scheduled to go over the virtual link may instead take a different path through the virtual link's transit area. In other words, virtual links allow transit traffic to be forwarded through an area, but do not dictate the precise path that the traffic will take. 🙈
Plot twist energy: the virtual link gets the traffic into the transit area, but the path inside it is whatever is actually shortest. 🦋
Let's look at an example. Consider the Autonomous System pictured in Figure 17. There is a single non-backbone area (Area 1) that physically divides the backbone into two separate pieces. To keep the backbone connected, a virtual link has been configured between routers RT1 and RT4. On the right side of the figure, network N1 belongs to the backbone. The dotted lines show that there is a much shorter intra-area backbone path between router RT5 and network N1 (cost 20) than there is between router RT4 and network N1 (cost 100). Both router RT4 and router RT5 will inject summary link advertisements for network N1 into Area 1. 🌈
After the shortest-path tree has been calculated for the backbone, router RT1 (one end of the virtual link) will have selected router RT4 as the virtual next hop for all data traffic destined for network N1. However, since router RT5 is so much closer to network N1, all routers internal to Area 1 (e.g., routers RT2 and RT3) will forward their network N1 traffic towards router RT5, instead of RT4. And indeed, after resolving the virtual next hop with the calculation above, router RT1 will also forward network N1 traffic towards RT5. 💖 So in this example the virtual link lets network N1 traffic be forwarded through the transit Area 1, but the actual path the data traffic takes does not follow the virtual link. Iykyk. 💅
16.4 Calculating AS external routes 🌟
AS external routes are calculated by examining AS external link advertisements. Each of the AS external link advertisements is considered in turn. Most AS external advertisements describe routes to specific IP destinations. An AS external advertisement can also describe a default route for the Autonomous System (destination = DefaultDestination). For each AS external link advertisement:
- If the cost specified by the advertisement is
LSInfinity, then examine the next advertisement. 🥹 - If the advertisement was originated by the calculating router itself, examine the next advertisement. 🙅♀️
- Call the destination described by the advertisement N. Look up the routing table entry for the AS boundary router (ASBR) that originated the advertisement. If no entry exists for router ASBR (i.e., ASBR is unreachable), do nothing with this advertisement and consider the next one in the list.
Else, this advertisement describes an AS external path to destination N. Examine the forwarding address specified in the external advertisement. This indicates the IP address to which packets for the destination should be forwarded. If the forwarding address is set to 0.0.0.0, packets should be sent to the ASBR itself. Otherwise, look up the forwarding address in the routing table.[24] An intra-area or inter-area path must exist to the forwarding address. If no such path exists, do nothing with the advertisement and consider the next one in the list. 🧭
Call the routing table distance to the forwarding address X (when the forwarding address is set to 0.0.0.0, this is the distance to the ASBR itself), and the cost specified in the advertisement Y. X is in terms of the link state metric, and Y is a Type 1 or 2 external metric. ✨
- Next, look up the routing table entry for the destination N. If no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. If the external metric type is 1, then the path-type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, then the path-type is set to type 2 external, the link state component of the route's cost is X, and the Type 2 cost is Y. 🎀
- Else, if the paths present in the table are not type 1 or type 2 external paths, do nothing. AS external paths have the lowest priority, so they just wait their turn. 🥺
(6) Okay so if the path isn't a match for anything we already have, we gotta compare its cost against the paths already in the table 🧐. Type 1 external paths are always shorter than Type 2 external paths, so that's the first check 💅. Type 1 paths get compared by adding the distance to the forwarding address to the advertised Type 1 metric, which is X+Y ✨. Type 2 paths get compared by their advertised Type 2 metrics first, and only if those are tied do we look at the distance to the forwarding addresses 🌸.
If the new path is shorter, it replaces the present paths in the routing table entry 🦋. If it costs the same, it just gets added to the entry's list of paths. Two best friends sharing the spotlight, iconic 👑.
16.5 Incremental updates --- summary links 🎀
When a new summary link advertisement shows up, we don't have to recalculate the whole routing table, bestie 🙌. Call the destination described by that summary link advertisement N, and let A be the area the advertisement belongs to.
Next, look up the routing table entry for N. If the next hop to N is a virtual link through Area A (so the entry's associated area is the backbone, but the listed next hop belongs to Area A and not the backbone 🌀), the real next hop has to be resolved again. That means running the algorithm in Section 16.3 for destination N only 🔁.
Otherwise, if there's already an intra-area route to destination N, nothing needs to be done, because intra-area routes always take precedence 👑. If that's not the case, and Area A is the router's sole attached area or Area A is the backbone, then the procedure in Section 16.2 has to run again, but only for the summary link advertisements whose destination is N 💜. Before that happens, the present routing table entry for N gets invalidated (but kept around for comparison purposes 👀). If this leads to a virtual next hop, the algorithm in Section 16.3 has to run once more to calculate the real next hop.
If N's routing table entry changes and N is an AS boundary router, the AS external links need to be reexamined (Section 16.4) 🔍.
16.6 Incremental updates --- AS external links ✨
Same energy as before: when a new AS external link advertisement comes in, we don't have to rebuild everything 🫶. Call the destination described by that AS external link advertisement N. If there's already an intra-area or inter-area route to that destination, no recalculation is needed, since those routes take precedence 💅.
Otherwise, the procedure in Section 16.4 has to run, but only for the AS external link advertisements whose destination is N. Before that procedure runs, the present routing table entry for N gets invalidated 🧹.
16.7 Events generated as a result of routing table changes 🌈
Sometimes changes to routing table entries make the OSPF area border routers take extra actions, so they need to keep an eye on these changes 👀:
- The cost or path type of a routing table entry has changed. If the destination described by this entry is a Network or AS boundary router, and this isn't just a change to AS external routes, new summary link advertisements might need to be generated. That could be one for each attached area, including the backbone 🦋. See Section 12.4.3 for more info. If a previously advertised entry has been deleted, or isn't advertisable to a particular area anymore, the advertisement has to be flushed from the routing domain by setting its age to
MaxAgeand reflooding it (see Section 14.1) 🗑️. - A routing table entry linked to a configured virtual link has changed. The destination of that entry is an area border router, and the change means the virtual link's cost or viability got modified 🧚.
- If the entry says the area border router is newly reachable (via TOS 0), then the virtual link is now operational. An Interface Up event should be generated for the virtual link, which starts a virtual adjacency forming (see Section 10.3). At this point, the virtual interface's IP address and the virtual neighbor's IP address also get calculated 🎉.
- If the entry says the area border router is no longer reachable (via TOS 0), then the virtual link and its associated adjacency should be destroyed. That means an Interface Down event gets generated for the associated virtual link 💀.
- If the cost of the entry changed and there's a fully established virtual adjacency, a new router links advertisement for the backbone has to be originated. That can set off even more routing table changes 🌀.
16.8 Equal-cost multipath 🍓
OSPF keeps multiple equal-cost routes to all destinations, which you can see in the steps we used to calculate the routing table and in how the routing table structure is defined 🔥.
Each of those multiple routes is the same type (intra-area, inter-area, type 1 external or type 2 external), has the same cost, and has the same associated area. The difference is that each route specifies a separate next hop and advertising router 💖.
There's no requirement that a router running OSPF keep track of every possible equal-cost route to a destination 🙈. An implementation can choose to keep only a fixed number of routes to any given destination, and this doesn't change any of the algorithms in this specification ✨.
16.9 Building the non-zero-TOS portion of the routing table 🌸
OSPF can calculate a different set of routes for each IP TOS (see Section 2.4). Supporting TOS-based routing is optional, and TOS-capable and non-TOS-capable routers can be mixed in the same OSPF routing domain 🫶. Routers that don't support TOS only calculate the TOS 0 route to each destination, and those routes are used to forward all data traffic, no matter what TOS indications are in the data packet's IP header 🚚. A router that doesn't support TOS tells the other OSPF routers this by clearing the T-bit in the Options field of its router links advertisement 📣.
The routing table sections above only handle the TOS 0 case. For routers that support TOS-based routing, each piece of the routing table calculation has to be rerun separately for the non-zero TOS values 🔁. When calculating routes for TOS X, only TOS X metrics can be used 💅. Any link state advertisement may specify a separate cost for each TOS, but a cost for TOS 0 must always be specified 💜. The way TOS is encoded in OSPF link state advertisements is described in Section 12.3 🦋.
An advertisement can say it's restricted to TOS 0 (meaning non-zero TOS isn't handled) by clearing the T-bit in the link state advertisement's Option field 🙅. Those advertisements aren't used when calculating routes for non-zero TOS. Because of that, a destination might be unreachable for some non-zero TOS. In that case, the TOS 0 path gets used when forwarding packets (see Section 11.1) 😭.
Here's what changes when you run the routing table calculation for a non-zero TOS value (called TOS X). Generally, routers and advertisements that don't support TOS get left out of the calculation 🧐.
- Calculating the shortest-path tree (Section 16.1). Routers that don't support TOS-based routing should be left out of the shortest-path tree calculation. They're identified as the routers with the T-bit reset in their router links advertisements 🌿. Those routers should never get added to the
Dijktraalgorithm's candidate list, and their router links advertisements shouldn't be examined when adding the stub networks to the tree 🚫. - Calculating the inter-area routes (Section 16.2). Inter-area paths are the concatenation of a path to an area border router with a summary link. When calculating TOS X routes, both path components also have to specify TOS X. Basically, only TOS X paths to the area border router are examined, and the area border router has to be advertising a TOS X route to the destination 🎀. This also means summary link advertisements with the T-bit reset in their Options field don't get considered 🙈.
- Resolving virtual next hops (Section 16.3). This calculation again considers the concatenation of a path to an area border router with a summary link. Just like with inter-area routes, only TOS X paths to the area border router are examined, and the area border router must be advertising a TOS X route to the destination 🧚.
Calculating AS external routes (Section 16.4). 💖 Okay so this one is a whole vibe 🔗. It looks at the concatenation of a path to a forwarding address with an AS external link. Only TOS X paths to the forwarding address get examined, and the AS boundary router has to be advertising a TOS X route to the destination 🎀. Also, AS external link advertisements with the T-bit reset in their Options field are not considered at all 🙈.
In addition, the advertising AS boundary router must also be reachable for its advertisements to count (see Section 16.4) ✨. BUT if the advertising router and the forwarding address are not the same router, the advertising router only needs to be reachable via TOS 0 🌸.
[1] The graph's vertices can be routers, transit networks, or stub networks 🕸️. Since routers may belong to multiple areas, it is not possible to color the graph's vertices 🎨.
[2] It's possible for all of a router's interfaces to be unnumbered point-to-point links 🧚. In that case, an IP address has to be assigned to the router. That address then gets advertised in the router's router links advertisement as a host route 📣.
[3] Note that in these cases both interfaces, the non-virtual and the virtual, would have the same IP address 👯.
[4] No host route is generated for interfaces to unnumbered point-to-point networks, and no IP packets can be addressed to them 🙅♀️. This is true regardless of such an interface's state 💀.
[5] It's honestly so instructive to see what happens when the Designated Router for the network crashes 😭. Let's call the Designated Router for the network RT1, and the Backup Designated Router RT2. If RT1 crashes (or maybe its interface to the network dies), the other routers on the network detect RT1's absence within RouterDeadInterval seconds 👀. Not everyone notices at precisely the same moment. The routers that spot RT1's absence before RT2 does will, for a little while, pick RT2 to be both Designated Router and Backup Designated Router 🫣. When RT2 realises RT1 is gone, it moves itself up to Designated Router. At that point, the remaining router with the highest Router Priority gets selected as Backup Designated Router 👑.
[6] On point-to-point networks, the lower level protocols indicate whether the neighbor is up and running 🔌. Existence of the neighbor on virtual links is indicated by the routing table calculation instead. Even so, in both of these cases the Hello Protocol is still used 📡. This makes sure that communication between the neighbors is bidirectional, and that each neighbor has a functioning routing protocol layer 🫶.
[7] When the identity of the Designated Router is changing, it can be pretty common for a neighbor in that state to send the router a Database Description packet 🤷♀️. That just means there's some momentary disagreement about who the Designated Router is 🌀.
[8] It's possible for a router to resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart 🔄. This makes the other end of the adjacency process a Seq Number Mismatch event, so it also goes back to ExStart state 💅.
[9] The address space of IP networks and the address space of OSPF Router IDs can overlap 🧩. A network might have an IP address that is identical (when you treat it as a 32-bit number) to some router's Router ID 😳.
[10] It's assumed that, for two different address ranges matching the destination, one range is more specific than the other ✨. Non-contiguous subnet masks can be configured to break this assumption 🙃. Those subnet mask configurations cannot be handled by the OSPF protocol 💔.
[11] MaxAgeDiff is an architectural constant 🏛️. It is the maximum dispersion of ages, in seconds, that can occur for a single link state instance as it gets flooded through the routing domain 🌊. If two advertisements differ by more than this, they're assumed to be different instances of the same advertisement 👯♀️. This can happen when a router restarts and loses track of its previous sequence number. See Section 13.4 for more details 📖.
[12] When two advertisements have different checksums, they're assumed to be separate instances 🧐. This can happen when a router restarts and loses track of its previous sequence number 😵. In this case the two advertisements have the same sequence number, so it's not possible to tell which link state is actually newer 🤯. If the wrong advertisement gets accepted as newer, the originating router will originate another instance 🔁. See Section 13.4 for further details 📚.
[13] There is one instance where a lookup has to be done based on partial information 🔍. That's during the routing table calculation, when a network links advertisement must be found based solely on its Link State ID 🎯. The lookup is still well defined, though, since no two network advertisements can have the same Link State ID 💜.
[14] This clause covers the case where inter-area routes are not summarized to the backbone 🌿. That's because inter-area routes are always associated with the backbone area 🦋.
[15] By keeping more information in the routing table, an implementation can recalculate the shortest path tree for just a single area 🌳. There are even incremental algorithms that let an implementation recalculate only a portion of the shortest path tree [BBN] 🧠. Those algorithms are beyond the scope of this specification 🙌.
[16] This is how the Link state request list gets emptied, which eventually makes the neighbor state transition to Full 🎉. See Section 10.9 for more details ✨.
[17] It should be a pretty rare occurrence for an advertisement's age to reach MaxAge 🥹. Usually the advertisement gets replaced by a more recent instance before it ages out 💖.
[18] Only the TOS 0 routes are important here 💅. That's because all routing protocol packets are sent with TOS= 0. See Appendix A 📎.
[19] It may be the case that paths to certain destinations don't vary based on TOS 🌈. For those destinations, the routing calculation doesn't need to be repeated for each TOS value 🙌. There also only needs to be a single routing table entry for these destinations, instead of a separate entry for each TOS value 🍓.
[20] Strictly speaking, because of equal-cost multipath, the algorithm doesn't actually create a tree 🌲. We keep using the "tree" terminology anyway, because that's what shows up most often in the existing literature 📚.
[21] This means that before data traffic can flow between a pair of neighboring routers, their link state databases must be synchronized 🔗. Before synchronization (neighbor state < Full), a router won't include the connection to its neighbor in its link state advertisements 🙅♀️.
[22] Because of this clause, when a virtual link exists between the calculating router and an AS boundary router, the intra-area path through the virtual link's transit area is always preferred over the virtual link itself 👑.
[23] Note the similarity between this procedure and the calculation of inter-area routes by a router internal to Area A 👯♀️.
[24] When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System 🌐. See Section 12.4.4 for more details 📖.
References 📚
[BBN] McQuillan, J.M., Richer, I. and Rosen, E.C. ARPANET
Routing Algorithm Improvements. BBN Technical Report 3803,
April 1978.
[DEC] Digital Equipment Corporation. Information processing
systems -- Data communications -- Intermediate System to
Intermediate System Intra-Domain Routing Protocol. October
1987.
[McQuillan] McQuillan, J. et.al. The New Routing Algorithm for the
Arpanet. IEEE Transactions on Communications, May 1980.
[Perlman] Perlman, Radia. Fault-Tolerant Broadcast of Routing
Information. Computer Networks, Dec. 1983.
[RFC 791] Postel, Jon. Internet Protocol. September 1981
[RFC 944] ANSI X3S3.3 86-60. Final Text of DIS 8473, Protocol for
Providing the Connectionless-mode Network Service. March
1986.
[RFC 1060] Reynolds, J. and Postel, J. Assigned Numbers. March 1990.
[RFC 1112] Deering, S.E. Host extensions for IP multicasting. May
1988.
[RFC 1131] Moy, J. The OSPF Specification. October 1989.
[RS-85-153] Leiner, Dr. Barry M., et.al. The DARPA Internet Protocol
Suite. DDN Protocol Handbook, April 1985.A. OSPF data formats 🦋
This appendix describes the format of OSPF protocol packets and OSPF link state advertisements 💌. The OSPF protocol runs directly over the IP network layer 🌐. Before any data formats get described, the details of the OSPF encapsulation are explained 🎀.
Next up is the OSPF options field 🧩. It describes various capabilities that may or may not be supported by pieces of the OSPF routing domain ✨. It shows up both in OSPF protocol packets and in OSPF link state advertisements 💜.
OSPF packet formats are detailed in Section A.3 📦. A description of OSPF link state advertisements appears in Section A.4 📝.
A.1 Encapsulation of OSPF packets
OSPF runs directly over the Internet Protocol's network layer 🫶. That means OSPF packets are encapsulated solely by IP and local network headers 💅.
OSPF doesn't define a way to fragment its protocol packets 🙈. Instead it depends on IP fragmentation when transmitting packets larger than the network MTU 😬. The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality ✂️. This is recommended, because IP fragmentation should be avoided whenever possible 🙏. Using this reasoning, an attempt should be made to limit the sizes of packets sent over virtual links to 576 bytes 🌸. However, if necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header) 🍓
The other big features of OSPF's IP encapsulation are the ones that keep things tidy on the wire 🫶
- Use of IP multicast 📡 Some OSPF messages get multicast when they're sent over multi-access networks. Two distinct IP multicast addresses are used. Packets sent to these addresses SHOULD never be forwarded, because they're only meant to travel a single hop. To make sure they don't wander off across multiple hops, their IP TTL MUST be set to 1.
- AllSPFRouters 🦋 This multicast address has been assigned the value 224.0.0.5. All routers running OSPF SHOULD be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Certain protocol packets are also sent here during the flooding procedure.
- AllDRouters 🌸 This multicast address has been assigned the value 224.0.0.6. Both the Designated Router and Backup Designated Router MUST be prepared to receive packets destined to this address. Certain packets are sent here during the flooding procedure.
- Protocol number 🔢 OSPF is IP protocol number 89. This number has been registered with the Network Information Center. IP protocol number assignments are documented in [RFC 1060].
- TOS 💅 Routing protocol packets are sent with IP TOS of 0. OSPF supports TOS-based routing, so routes to any particular destination may vary based on TOS. However, all OSPF routing protocol packets are sent with the DTR bits in the IP header's TOS field (see [RFC 791]) set to 0.
- Precedence 👑 Routing protocol packets are sent with IP precedence set to Internetwork Control. OSPF protocol packets SHOULD be given precedence over regular IP data traffic, both when sending and when receiving. Setting the IP precedence field in the IP header to Internetwork Control [RFC 791] MAY help implement this objective.
A.2 The options field 🎀
The OSPF options field is present in OSPF Hello packets, Database Description packets and all link state advertisements. It lets OSPF routers support (or not support) optional capabilities, and tell other OSPF routers what their capability level is. Thanks to this, routers with different capabilities can be mixed within one OSPF routing domain, which is honestly so iconic 🌈
When it's used in Hello packets, the options field lets a router reject a neighbor because of a capability mismatch. When capabilities are exchanged in Database Description packets, a router can choose not to forward certain LSA types to a neighbor because that neighbor has reduced functionality. Finally, listing capabilities in LSAs lets routers route traffic around reduced-functionality routers by excluding them from parts of the routing table calculation. It's giving smart routing 🧚
Two capabilities are currently defined. For each one, the effect of the capability showing up (or not showing up) in Hello packets, Database Description packets and link state advertisements is spelled out below. For example, the external routing capability (called the E-bit below) only has meaning in OSPF Hello packets. Routers SHOULD reset (i.e. clear) the unassigned part of the capability field when sending Hello packets or Database Description packets and when originating link state advertisements.
Additional capabilities may be assigned in the future. Routers that run into unrecognized capabilities in received Hello packets, Database Description packets or link state advertisements SHOULD ignore the capability and process the packet/advertisement normally 🫧
+-+-+-+-+-+-+-+-+
| | | | | | |E|T|
+-+-+-+-+-+-+-+-+
The options fieldT-bit 🍓 This describes the router's TOS capability. If the T-bit is reset, then the router supports only a single TOS (TOS 0). Such a router is also said to be incapable of TOS-routing. The absence of the T-bit in a router links advertisement causes the router to be skipped when building a non-zero TOS shortest-path tree (see Section 16.9). In other words, routers incapable of TOS routing will be avoided as much as possible when forwarding data traffic requesting a non-zero TOS. The absence of the T-bit in a summary link advertisement or an AS external link advertisement indicates that the advertisement is describing a TOS 0 route only (and not routes for non-zero TOS).
E-bit 💜 AS external link advertisements are not flooded into or through OSPF stub areas (see Section 3.6). The E-bit makes sure that all members of a stub area agree on that area's configuration. The E-bit is meaningful only in OSPF Hello packets. When the E-bit is reset in the Hello packet sent out a particular interface, it means the router will neither send nor receive AS external link state advertisements on that interface (in other words, the interface connects to a stub area). Two routers will not become neighbors unless they agree on the state of the E-bit. 🙈
A.3 OSPF Packet Formats 🧚
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 24 byte header, which gets described first. Each packet type is then described in its own succeeding section. In those sections, each packet's division into fields is displayed, and then the field definitions are listed out ✨
All OSPF packet types (other than the OSPF Hello packets) deal with lists of link state advertisements. For example, Link State Update packets implement the flooding of advertisements throughout the OSPF routing domain. Because of this, OSPF protocol packets cannot be parsed unless the format of link state advertisements is also understood. The format of link state advertisements is described in Section A.4.
The receive processing of OSPF packets is detailed in Section 8.2. The sending of OSPF packets is explained in Section 8.1.
A.3.1 The OSPF packet header 💖
Every OSPF packet starts with a common 24 byte header. This header contains all the necessary information to determine whether the packet should be accepted for further processing. That determination is described in Section 8.2 of the specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version # 🌷 The OSPF version number. This specification documents version 2 of the protocol.
Type 🎀 The OSPF packet types are as follows. The format of each of these packet types is described in a succeeding section.
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State AcknowledgmentPacket length 📏 The length of the protocol packet in bytes. This length includes the standard OSPF header.
Router ID 🆔 The Router ID of the packet's source. In OSPF, the source and destination of a routing protocol packet are the two ends of an (potential) adjacency.
Area ID 🗺️ A 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone area ID of 0.
Checksum 🧮 The standard IP checksum of the entire contents of the packet, excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.
AuType 🔐 Identifies the authentication scheme to be used for the packet. Authentication is discussed in Appendix E of the specification. Consult Appendix E for a list of the currently defined authentication types.
Authentication 🗝️ A 64-bit field for use by the authentication scheme.
A.3.2 The Hello packet 👋
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. On top of that, Hellos are multicast on those physical networks that have multicast or broadcast capability, which enables dynamic discovery of neighboring routers 🦋
All routers connected to a common network MUST agree on certain parameters (network mask, hello and dead intervals). These parameters are included in Hello packets, so differences can inhibit the forming of neighbor relationships. A detailed explanation of the receive processing for Hello packets is presented in Section 10.5. The sending of Hello packets is covered in Section 9.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInt | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DeadInt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |- Network mask: The network mask for this interface. Say the interface goes to a class B network and the third byte is used for subnetting, then the network mask is
0xffffff00. 🎀 - Options: The optional capabilities this router supports, as documented in Section A.2. ✨
- HelloInt: How many seconds pass between this router's Hello packets. ⏰
- Rtr Pri: This router's Router Priority, which gets used when electing the (Backup) Designated Router. If it's set to 0, the router is ineligible to become the (Backup) Designated Router. 👑
- Deadint: How many seconds go by before a silent router gets declared down. 💀
- Designated Router: The identity of the Designated Router for this network, as seen by the advertising router. It's identified by its IP interface address on the network. Set to 0 if there isn't a Designated Router. 🌸
- Backup Designated Router: The identity of the Backup Designated Router for this network, as seen by the advertising router. It's identified by its IP interface address on the network. Set to 0 if there isn't a backup Designated Router. 🦋
- Neighbor: The Router IDs of every router whose valid Hello packets were seen recently on the network. "Recently" means within the last DeadInt seconds. 💜
A.3.3 The Database Description packet ✨
Okay so Database Description packets are OSPF packet type 2, and they show up when an adjacency is getting initialized 🫶 They describe what's inside the topological database. One packet might not be enough, so multiple packets MAY be used to describe the whole thing. The way that works is a poll-response procedure. One router is designated as master and the other is the slave. The master sends Database Description packets (the polls), and the slave answers each one with its own Database Description packet (the responses). The responses link back to the polls through the packets' sequence numbers, which is so iconic 😭
The Database Description packet looks a lot like the Link State Request and Link State Acknowledgment packets. All three have a main chunk that's a list of items, and each item describes one piece of the topological database. Sending Database Description packets is covered in Section 10.8, and receiving them is covered in Section 10.6. 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| A |
+- Link State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |- 0: These fields are reserved, and they MUST be 0. 🙈
- Options: The optional capabilities this router supports, as documented in Section A.2. ✨
- I-bit: The Init bit. When it's set to 1, this packet is the first one in the sequence of database descriptions. 🍓
- M-bit: The More bit. When it's set to 1, more database descriptions are coming. 💅
- MS-bit: The Master/Slave bit. When it's set to 1, the router is the master during the database exchange. Otherwise, it's the slave. 👑
- DD sequence number: Used to sequence the database description packets. The initial value (the one with the Init bit set) SHOULD be unique. After that, the sequence number increments until the whole database description has been sent. 🔥
The rest of the packet is a (maybe partial) list of pieces from the topological database. Each link state advertisement in the database is described by its link state header, which is documented in Section A.4.1. That header has everything needed to uniquely identify both the advertisement and its current instance. 🧚
A.3.4 The Link State Request packet 🎀
Link State Request packets are OSPF packet type 3. Once a router has traded Database Description packets with a neighbor, it MAY find that parts of its topological database are out of date. That's where the Link State Request packet comes in, asking for the newer pieces of the neighbor's database. Multiple Link State Request packets MAY need to be used. Sending these is the last step in bringing up an adjacency. 🦋
A router that sends a Link State Request packet knows exactly which instance of each database piece it wants, defined by LS sequence number, LS checksum, and LS age. It MAY receive even more recent instances in response. 💜
Sending Link State Request packets is documented in Section 10.9, and receiving them is documented in Section 10.7. 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Each requested advertisement is specified by its LS type, Link State ID, and Advertising Router. Those three uniquely identify the advertisement, but not its instance. Link State Request packets are understood to be requests for the most recent instance, whatever that happens to be. 🫶
A.3.5 The Link State Update packet 🦋
Link State Update packets are OSPF packet type 4. These are the packets that flood link state advertisements around. Each Link State Update packet carries a bunch of link state advertisements, each one hop further from its origin. Several link state advertisements MAY be included in a single packet. 💖
Link State Update packets are multicast on physical networks that support multicast or broadcast. To make flooding reliable, the flooded advertisements get acknowledged in Link State Acknowledgment packets. If certain advertisements have to be retransmitted, those always travel in unicast Link State Update packets. For more on reliable flooding, check out Section 13. 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # advertisements |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| Link state advertisements |
+- +-+
| ... |- # advertisements: The number of link state advertisements included in this update. 🍓
The body of the Link State Update packet is a list of link state advertisements. Each advertisement starts with a common 20 byte header, the link state advertisement header, which is described in Section A.4.1. Apart from that header, each of the five types of link state advertisements has its own format, and those are described in Section A.4. 🌸
A.3.6 The Link State Acknowledgment packet 🫶
Link State Acknowledgment Packets are OSPF packet type 5. To make flooding of link state advertisements reliable, the flooded advertisements get explicitly acknowledged. That acknowledgment happens by sending and receiving Link State Acknowledgment packets. Multiple link state advertisements can be acknowledged in a single packet. 💜
Depending on the state of the sending interface and where the advertisements came from, a Link State Acknowledgment packet goes out either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. Sending Link State Acknowledgement packets is documented in Section 13.5, and receiving them is documented in Section 13.7. 🔥
The format of this packet is similar to that of the Data Description
okay so the body of both packets is literally just a list of link state advertisement headers 🎀 that's the whole vibe ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Autype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| A |
+- Link State Advertisement -+
| Header |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Each acknowledged link state advertisement is described by its link state header 🦋 The link state header is documented in Section A.4.1. It contains all the information REQUIRED to uniquely identify both the advertisement and the advertisement's current instance 💖
A.4 Link state advertisement formats 🌈
There are five distinct types of link state advertisements. Each link state advertisement begins with a standard 20-byte link state header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate link state advertisement types.
Each link state advertisement describes a piece of the OSPF routing domain. Every router originates a router links advertisement. In addition, whenever the router is elected Designated Router, it originates a network links advertisement. Other types of link state advertisements MAY also be originated (see Section 12.4). All link state advertisements are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of link state advertisements. (See Section 13 for more information concerning the flooding algorithm). This collection of advertisements is called the link state (or topological) database 🧚
From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16 ✨
A.4.1 The Link State Advertisement header
All link state advertisements begin with a common 20 byte header. This header contains enough information to uniquely identify the advertisement (LS type, Link State ID, and Advertising Router). Multiple instances of the link state advertisement MAY exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the link state advertisement header 🔥
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+LS age The time in seconds since the link state advertisement was originated.
Options The OPTIONAL capabilities supported by the described portion of the routing domain. OSPF's OPTIONAL capabilities are documented in Section A.2.
LS type The type of the link state advertisement. Each link state type has a separate advertisement format. The link state types are as follows (see Section 12.1.3 for further explanation):
LS Type Description
___________________________________
1 Router links
2 Network links
3 Summary link (IP network)
4 Summary link (ASBR)
5 AS external linkLink State ID This field identifies the portion of the internet environment that is being described by the advertisement. The contents of this field depend on the advertisement's LS type. For example, in network links advertisements the Link State ID is set to the IP interface address of the network's Designated Router (from which the network's IP address can be derived). The Link State ID is further discussed in Section 12.1.4.
Advertising Router The Router ID of the router that originated the link state advertisement. For example, in network links advertisements this field is set to the Router ID of the network's Designated Router.
LS sequence number Detects old or duplicate link state advertisements. Successive instances of a link state advertisement are given successive LS sequence numbers. See Section 12.1.6 for more details.
LS checksum The Fletcher checksum of the complete contents of the link state advertisement. See Section 12.1.7 for more details.
length The length in bytes of the link state advertisement. This includes the 20 byte link state header.
A.4.2 Router links advertisements
Router links advertisements are the Type 1 link state advertisements. Each router in an area originates a router links advertisement. The advertisement describes the state and cost of the router's links (or interfaces) to the area. All of the router's links to the area MUST be described in a single router links advertisement. For details concerning the construction of router links advertisements, see Section 12.4.1 🎀
In router links advertisements, the Link State ID field is set to the router's OSPF Router ID. The T-bit is set in the advertisement's Option field if and only if the router is able to calculate a separate set of routes for each IP TOS. Router links advertisements are flooded throughout a single area only 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |bit E When set, the router is an AS boundary router (E is for external)
bit B When set, the router is an area border router (B is for border)
# links The number of router links described by this advertisement. This MUST be the total collection of router links to the area 💅
The following fields are used to describe each router link. Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. It MAY be a link to a transit network, to another router or to a stub network. The values of all the other fields describing a router link depend on the link's type. For example, each link has an associated 32-bit data field. For links to stub networks this field specifies the network's IP address mask. For the other link types the Link Data specifies the router's associated IP interface address 🌸
Type A quick description of the router link. One of the following. Note that host routes are classified as links to stub networks whose network mask is 0xffffffff.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual linkLink ID Identifies the object that this router link connects to. Value depends on the link's type. When connecting to an object that also originates a link state advertisement (i.e., another router or a transit network) the Link ID is equal to the other advertisement's Link State ID. This provides the key for looking up said advertisement in the link state database. See Section 12.2 for more details.
Type Link ID
______________________________________
1 Neighboring router's ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's IDLink Data Okay so the contents here depend on the link's Type field, again 💅 For connections to stub networks, it specifies the network mask. For the other link types, it specifies the router's associated IP interface address. That second one is needed during the routing table build process, when calculating the IP address of the next hop. See Section 16.1.1 for more details 🦋
#metrics This is the number of different TOS metrics given for this link, not counting the required metric for TOS 0. For example, if no additional TOS metrics are given, this field should be set to 0 🌸
TOS 0 metric The cost of using this router link for TOS 0 💖
For each link, separate metrics may be specified for each Type of Service (TOS) ✨ The metric for TOS 0 must always be included, and we already talked about it above. Metrics for non-zero TOS are described below. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for non-zero TOS values that are not specified defaults to the TOS 0 cost. Metrics must be listed in order of increasing TOS encoding. For example, the metric for TOS 16 must always follow the metric for TOS 8 when both are specified 🫶
TOS This is the IP type of service that this metric refers to. The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
metric The cost of using this outbound router link, for traffic of the specified TOS 🔥
A.4.3 Network links advertisements 🎀
Network links advertisements are the Type 2 link state advertisements, and they're giving main character energy 👑 A network links advertisement is originated for each transit network in the area. A transit network is a multi-access network that has more than one attached router. The network links advertisement is originated by the network's Designated Router. The advertisement describes all routers attached to the network, including the Designated Router itself. The advertisement's Link State ID field lists the IP interface address of the Designated Router.
The distance from the network to all attached routers is zero, for all types of service. This is why the TOS and metric fields need not be specified in the network links advertisement. For details about building network links advertisements, see Section 12.4.2 ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network Mask This is the IP address mask for the network. For example, a class A network would have the mask 0xff000000 💅
Attached Router These are the Router IDs of each of the routers attached to the network. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the link state advertisement's length field 🧚
A.4.4 Summary link advertisements 🌈
Summary link advertisements are the Type 3 and 4 link state advertisements. These advertisements are originated by area border routers. A separate summary link advertisement is made for each destination (known to the router) which belongs to the AS, yet is outside the area. For details about building summary link advertisements, see Section 12.4.3 💜
Type 3 link state advertisements are used when the destination is an IP network. In this case, the advertisement's Link State ID field is an IP network number. When the destination is an AS boundary router, a Type 4 advertisement is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4.) Other than the difference in the Link State ID field, the format of Type 3 and 4 link state advertisements is identical 🍓
For stub areas, type 3 summary link advertisements can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the advertisement's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0 🦋
Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described. If a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0 ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network Mask For Type 3 link state advertisements, this is the destination's IP network mask. For example, when advertising the location of a class A network, the value 0xff000000 would be used. This field is not meaningful and must be zero for Type 4 link state advertisements 🙈
For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified 💅
TOS This is the Type of Service that the following cost concerns. The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
metric The cost of this route, expressed in the same units as the interface costs in the router links advertisements 🔥
A.4.5 AS external link advertisements 👑
AS external link advertisements are the Type 5 link state advertisements. These advertisements are originated by AS boundary routers. A separate advertisement is made for each destination (known to the router) which is external to the AS. For details about building AS external link advertisements, see Section 12.4.3 🫶
AS external link advertisements usually describe a particular external destination. For these advertisements, the Link State ID field specifies an IP network number. AS external link advertisements are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0 🌸
Separate costs may be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is described in Section 12.3. Note that the cost for TOS 0 must be included, and is always listed first. If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described by the advertisement. Otherwise, routes for the other TOS values are also described. If a cost for a certain TOS is not included, its cost defaults to that specified for TOS 0 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network Mask This is the IP network mask for the advertised destination. For example, when advertising a class A network, the mask 0xff000000 would be used.
For each specified type of service, the following fields are defined. The number of TOS routes included can be calculated from the link state advertisement's length field. Values for TOS 0 must be specified; they are listed first. Other values must be listed in order of increasing TOS encoding. For example, the cost for TOS 16 must always follow the cost for TOS 8 when both are specified 🧚
bit E This is the type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any link state path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is comparable directly (without translation) to the link state metric 🍓
Okay bestie, the Forwarding address is where the data traffic for the advertised destination gets sent 📬 Simple. If it's set to 0.0.0.0, the traffic goes to the advertisement's originator instead, which is the responsible AS boundary router 🫶
TOS is the Type of Service that the following cost is about. If you want to know how TOS gets encoded in OSPF link state advertisements, check out Section 12.3 🧠
metric is the cost of this route. What it means depends on the external type indication (bit E above) ✨
External Route Tag is a 32-bit field attached to each external route 🏷️ OSPF doesn't use it itself. It may be used to pass information between AS boundary routers, but what that info actually is lives outside this spec, so don't go looking for it here 🙈
B. Architectural Constants ✨
Several OSPF protocol parameters have fixed architectural values, and the text refers to them by names like LSRefreshTimer. The configurable parameters follow the same naming convention, and those are defined in appendix C 💜
Each architectural constant gets its name, its value, and a short description of what it does. Here we go 💅
LSRefreshTime is the maximum time between distinct originations of any particular link state advertisement. For each link state advertisement a router originates, an interval timer should be set to this value. When that timer fires, a new instance of the link state advertisement gets originated. The value of LSRefreshTime is set to 30 minutes ⏰
MinLSInterval is the minimum time between distinct originations of any particular link state advertisement. The value of MinLSInterval is set to 5 seconds 🌸
MaxAge is the maximum age a link state advertisement can reach. When an advertisement's age hits MaxAge, it gets reflooded. After that, it's removed from the database as soon as the flood is acknowledged, meaning as soon as it's been removed from all neighbor Link state retransmission lists. Advertisements with age MaxAge are not used in the routing table calculation 🚫 The value of MaxAge must be greater than LSRefreshTime. The value of MaxAge is set to 1 hour 👑
CheckAge is the moment when a link state advertisement in the link state database hits a multiple of CheckAge. At that point, the advertisement's checksum gets verified. An incorrect checksum then points to a serious error 😭 The value of CheckAge is set to 5 minutes.
MaxAgeDiff is the maximum time dispersion that can happen while a link state advertisement floods through the AS. Most of that time comes from advertisements sitting on router output queues, where they aren't aging during the flood 🌊 The value of MaxAgeDiff is set to 15 minutes.
LSInfinity is the link state metric value that means the destination is unreachable. It's defined as the binary value of all ones 💀 Its size depends on the metric field, which is 16 bits in router links advertisements and 24 bits in both summary and AS external links advertisements.
DefaultDestination is the Destination ID that marks the default route. That route gets used when no other matching routing table entry can be found 🧚 The default destination can only be advertised in AS external link advertisements and in type 3 summary link advertisements for stub areas. Its value is the IP address 0.0.0.0 🍓
C. Configurable Constants 🎀
OSPF has quite a few configurable parameters, and they're grouped into general functional categories like area parameters and interface parameters. Some of them come with sample values 🌈
Some parameter settings need to be consistent across groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask 🫶
Some parameters may be determined by router algorithms that live outside this specification. An example would be the address of a host connected to the router via a SLIP line. From OSPF's point of view, those items still count as configurable 💅
C.1 Global parameters
Most configuration parameters are defined per area, since a separate copy of the OSPF protocol runs for each area. That's why the global ones are a short list 🦋
Router ID is a 32-bit number that uniquely identifies the router in the Autonomous System. One way to assign it is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID changes, the router's OSPF software should be restarted before the new Router ID takes effect 🔄
TOS capability shows whether the router will calculate separate routes based on TOS. For more info, see Sections 4.5 and 16.9 🧐
C.2 Area parameters
All routers belonging to an area must agree on that area's configuration. If two routers disagree, adjacencies can't form between them, and routing protocol traffic gets hindered 😤 The following items must be configured for an area:
Area ID is a 32-bit number that identifies the area. The Area ID of 0 is reserved for the backbone. If the area represents a subnetted network, the IP network number of that subnetted network may be used for the area ID 🌳
List of address ranges: an OSPF area is defined as a list of [IP address, mask] pairs. Each pair describes a range of IP addresses. Networks and hosts get assigned to an area depending on whether their addresses fall into one of the area's defining address ranges. Routers count as belonging to multiple areas, depending on their attached networks' area membership. Routing info gets condensed at area boundaries, so outside the area, a single route is advertised for each address range 🧃
As an example, say an IP subnetted network is going to be its own OSPF area. You'd configure that area as a single address range, where the IP address is the address of the subnetted network and the mask is the natural class A, B, or C internet mask. Outside the area, a single route gets advertised describing the entire subnetted network 🎀
Authentication type: each area can be configured for a separate type of authentication. See Appendix E for a discussion of the defined authentication types 🔐
External routing capability shows whether AS external advertisements will be flooded into and throughout the area. If AS external advertisements are excluded from the area, the area is called a "stub" 🌿 Inside stub areas, routing to external destinations is based solely on a default summary route. The backbone cannot be configured as a stub area, and virtual links cannot be configured through stub areas. For more information, see Section 3.6 📖
StubDefaultCost: if the area is configured as a stub area and the router itself is an area border router, then StubDefaultCost gives the cost of the default summary link that the router should advertise into the area. There can be a separate cost configured for each IP TOS. See Section 12.4.3 for more information 💸
C.3 Router interface parameters
Some router interface parameters, like IP interface address and subnet mask, actually imply properties of the attached networks. So they must be consistent across all the routers attached to that network. These are the parameters that must be configured for a router interface 🧩
IP interface address is the IP protocol address for this interface. It uniquely identifies the router over the entire internet. An IP address isn't required on serial lines, and a serial line like that is called "unnumbered" 🔌
IP interface mask denotes the portion of the IP interface address that identifies the attached network. People often call it the subnet mask 🎭
Interface output cost(s) is the cost of sending a packet on the interface, expressed in the link state metric. It gets advertised as the link cost for this interface in the router's router links advertisement. There may be a separate cost for each IP Type of Service. The interface output cost(s) must always be greater than 0 💯
RxmtInterval is the number of seconds between link state advertisement retransmissions, for adjacencies belonging to this interface. It's also used when retransmitting Database Description and Link State Request Packets. This should be well over the expected round-trip delay between any two routers on the attached network. The setting should be conservative, or needless retransmissions will happen. It will need to be larger on low speed serial lines and virtual links. Sample value for a local area network: 5 seconds ⏳
InfTransDelay is the estimated number of seconds it takes to transmit a Link State Update Packet over this interface. Link state advertisements in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays for the interface. It must be greater than 0. Sample value for a local area network: 1 second 🚀
Router Priority is an 8-bit unsigned integer. When two routers attached to a network both try to become Designated Router, the one with the highest Router Priority wins 🥇 If there's still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached network. Router Priority only gets configured for interfaces to multi-access networks 🗳️
HelloInterval is the length of time, in seconds, between the Hello packets the router sends on the interface. This value gets advertised in the router's Hello packets. It must be the same for all routers attached to a common network. A smaller hello interval means topological changes get detected faster, but more routing traffic follows 🏃♀️ Sample value for a X.25 PDN network: 30 seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval is the number of seconds that a router's Hellos haven't been seen before its neighbors declare the router down. This is also advertised in the router's Hello Packets in the DeadInt field. It should be some multiple of the HelloInterval (say 4). This value again must be the same for all routers attached to a common network 💀
Authentication key is configured data that lets the authentication procedure generate and/or verify the authentication field in the OSPF header. For example, if the authentication type indicates simple password, the authentication key would be a 64-bit password. That key gets inserted directly into the OSPF header when routing protocol packets are originated. There could be a separate password for each network 🔑
C.4 Virtual link parameters
Virtual links are used to restore or increase connectivity of the backbone 🌉 Virtual links may be configured between any pair of area border routers that have interfaces to a common (non-backbone) area. The virtual link appears as an unnumbered point-to-point link in the graph for the backbone. The virtual link must be configured in both of the area border routers 🩷
A virtual link appears in router links advertisements (for the backbone
as if it were a separate router interface to the backbone 🦋 So it gets all the same parameters a router interface has (see Section C.3). Ngl, a virtual link acts like an unnumbered point-to-point link, but it does have an IP interface address 💅 That address is the IP source in the protocol packets it sends along the virtual link, and it gets set dynamically during the routing table build process ✨ The interface output cost is also dynamic on virtual links. It's set to the cost of the intra-area path between the two routers, so it's giving "it figures itself out" 🧚
RxmtInterval has to be configured 🎀 It should be well over the expected round-trip delay between the two routers. Bestie, this one can be hard to estimate for a virtual link, so the move is to err on the side of making it too large 🙈 And Router Priority is not used on virtual links, so don't stress about that one 💜
A virtual link is defined by two configurable parameters 🌸 The first is the Router ID of the virtual link's other endpoint. The second is the (non-backbone) area the virtual link runs through, which is called the virtual link's transit area. Also, virtual links cannot be configured through stub areas 🚫 iykyk 💀
C.5 Non-broadcast, multi-access network parameters
OSPF handles a non-broadcast, multi-access network pretty much the same way it handles a broadcast network 🌈 Since there may be lots of routers attached to the network, a Designated Router gets selected for it. That Designated Router then originates a networks links advertisement, which lists all the routers attached to the non-broadcast network 👑
Here's the catch though: because there's no broadcast capability, some configuration parameters are needed for the Designated Router selection 😭 Those parameters only need to be configured in the routers that are actually eligible to become Designated Router, meaning the ones whose DR Priority for the network is non-zero 🍓
List of all other attached routers This is the list of every other router attached to the non-broadcast network. Each router is listed by its IP interface address on the network. For each router on the list, you also have to define whether it's eligible to become Designated Router ✨ When an interface to a non-broadcast network comes up, the router only sends Hello packets to the neighbors that are eligible to become Designated Router, until it figures out who the Designated Router is 🔥
PollInterval If a neighboring router has gone inactive (no hellos seen for RouterDeadInterval seconds), the router may still need to send Hellos to that dead neighbor 💀 Those Hellos get sent at the reduced rate of PollInterval, which should be much larger than HelloInterval 🫶 Sample value for a PDN X.25 network: 2 minutes ⏰
C.6 Host route parameters
Host routes get advertised in network links advertisements as stub networks with mask 0xffffffff 🦋 They can represent router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (for example, via a SLIP line) 🌸 For each host directly connected to the router, the following items must be configured:
Host IP address The IP address of the host 💖
Cost of link to host The cost of sending a packet to the host, measured in terms of the link state metric 🎀 You can configure multiple costs, one for each IP TOS. Honestly though, since the host probably has only a single connection to the internet, the configured cost(s) are often unimportant, meaning they won't have any effect on routing 🤷♀️✨
D. Required Statistics
An OSPF implementation must provide a minimum set of statistics that show the operational state of the protocol 📊 These statistics must be accessible to the user, which will probably happen through some sort of network management interface 🧚
The hope is that these statistics will help with debugging the implementation and analyzing how the protocol performs 🔍💜
The statistics come in two broad categories 💅 The first is what we'll call logging messages. These are messages produced in real time, usually one message for each single protocol event. People also commonly call these traps 🪤
The second category is called cumulative statistics. These are counters whose values build up over time, like the count of link state retransmissions over the last hour ⏳ Dumps of the various routing data structures also fall into this category 🌈
D.1 Logging messages
A logging message should be produced on every significant protocol event 📝 The major events are listed below. Most of them point to a topology change in the routing domain. But some logging messages can still show up even when the routing domain stays intact for long stretches, like link state originations that happen because the link state refresh timer fired ⏲️
Any message that refers to a link state advertisement should print the area associated with that advertisement 🗺️ AS external link advertisements don't have an area associated with them, so no area for those 🙅♀️
The following logging messages indicate topological changes in the routing domain 🔥
T1 The state of a router interface changes. Interface state changes are documented in Section 9.3, and they'll generally cause new link state advertisements to be originated 🚀 The logging message should include the interface's IP address (or other name), the interface type (virtual link, etc.), and the old and new state values (as documented in Section 9.1) 💖
T2 The state of a neighbor changes. Neighbor state changes are documented in Section 10.3 🫶 The logging message should include the neighbor IP address, plus the old and new state values ✨
T3 The (Backup) Designated Router has changed on one of the attached networks. See Section 9.4 👑 The logging message should include the network IP address, and the old and new (Backup) Designated Routers 🦋
T4 The router is originating a new instance of a link state advertisement 🌸 The logging message should indicate the LS type, Link State ID, and Advertising Router associated with the advertisement (see Section 12.4) 🎀
T5 The router has received a new instance of a link state advertisement. These come in Link State Update packets, and receiving one will cause the routing table to be recalculated 🔄 The logging message should indicate the advertisement's LS type, Link State ID, and Advertising Router. It should also include the neighbor the advertisement was received from 💜
T6 An entry in the routing table has changed (see Section 11) 🗺️ The logging message should indicate the Destination type, Destination ID, and the old and new paths to the destination 🌈
The following logging messages may point to a network configuration error 🙈
C1 A received OSPF packet is rejected because of errors in its IP/OSPF header 🚫 The reasons for rejection are documented in Section 8.2, and they include an OSPF checksum failure, an authentication failure, and being unable to match the source with an active OSPF neighbor 😭 The logging message should include the IP source and destination addresses, the router ID in the OSPF header, and the reason for the rejection 📝
C2 An incoming Hello packet is rejected because its parameters don't match the ones configured for the receiving interface (see Section 10.5). This signals a configuration problem on the attached network 🛠️ The logging message should include the Hello's source, the receiving interface, and the parameters that don't match 🎀
C3 An incoming Database Description packet, Link State Request packet, Link State Acknowledgment packet, or Link State Update packet is rejected because the source neighbor is in the wrong state (see Sections 10.6, 10.7, 13.7, and 13 respectively). This can be totally normal when the identity of the network's Designated Router changes, since that causes momentary disagreements over whether adjacencies are valid 🔁 The logging message should include the source neighbor, its state, and the packet's type 💅
C4 A Database Description packet has been retransmitted 🔁 This may mean the value of RxmtInterval configured for the associated interface is too small 🤏 The logging message should include the neighbor the packet is being sent to 💌
The following messages can be caused by packet transmission errors or by software errors in an OSPF implementation 💀
E1 The checksum in a received link state advertisement is incorrect, so the advertisement is discarded (see Section 13) 🗑️ The logging message should include the advertisement's LS type, Link State ID, and Advertising Router (which may itself be incorrect). It should also include the neighbor the advertisement was received from 🫠
E2 During the aging process, it's discovered that one of the link state advertisements in the database has an incorrect checksum 😱 This points to memory corruption or a software error in the router itself. The router should be dumped and restarted 🔥
The following messages show that a router has restarted and lost track of its previous LS sequence number. If these messages keep showing up, it may mean there are duplicate Router IDs in the network 👀
R1 Two link state advertisements have been seen whose LS type, Link State ID, Advertising Router, and LS sequence number are all the same, but whose LS checksums differ. These count as different instances of the same advertisement, and the instance with the larger checksum is accepted as more recent (see Sections 12.1.7 and 13.1) 🧐 The logging message should include the LS type, Link State ID, Advertising Router, LS sequence number, and the two differing checksums 📊
R2 Two link state advertisements have been seen whose LS type, Link State ID, Advertising Router, LS sequence number, and LS checksum are all the same, but which can still be told apart by their LS age fields 🕰️ That means one of the advertisement's LS age is MaxAge, or the two LS age fields differ by more than MaxAgeDiff 🙃 The logging message should include the LS type, Link State ID, Advertising Router, LS sequence number, and the two differing ages ⏱️
R3 The router has received an instance of one of its own self-originated advertisements that is considered more recent 🪞 This forces the router to originate a new advertisement (see Section 13.4) 🔁 The logging message should include the advertisement's LS type, Link State ID, and Advertising Router, along with the neighbor the advertisement was received from 💜
R4 An acknowledgment has been received for an instance of an advertisement that isn't currently in the router's database (see Section 13.7) 🤔 The logging message should detail the instance being acknowledged and the database copy (if there is one), along with the neighbor the acknowledgment came from 📝
R5 An advertisement has been received through the flooding procedure that is LESS recent than the router's current database copy (see Section 13) 🕰️ The logging message should include the received advertisement's LS type, Link State ID, Advertising Router, LS sequence number, LS age, and LS checksum 🌸 It should also show the neighbor the advertisement was received from 🫶
The following messages indicate normal, yet infrequent, protocol events 🌈 These messages help with interpreting some of the above messages ✨
N1 is when the Link state refresh timer goes off for one of the router's self-originated advertisements (see Section 12.4) ⏰. A new instance of that advertisement MUST be originated 🔁. The message SHOULD include the advertisement's LS type, Link State ID and Advertising Router 📝.
N2 is when one of the advertisements in the router's link state database has aged to MaxAge (see Section 14) 🥀. At that point it's no longer part of the routing table calculation, and it gets reflooded 🌊. The message SHOULD list the advertisement's LS type, Link State ID and Advertising Router 💅.
N3 is when an advertisement of age MaxAge gets flushed from the router's database 🗑️. This only happens after every adjacent neighbor has acknowledged it 🤝. The message SHOULD list the advertisement's LS type, Link State ID and Advertising Router ✨.
D.2 Cumulative statistics
Okay so these statistics show collections of the routing data structures 📊. They SHOULD be able to be obtained interactively, through some kind of network management facility 🖥️.
Every statistics display below is specific to a single area, except for the area list, the routing table and the AS external links 🎀. Like we covered in Section 4, most OSPF protocol mechanisms work on each area separately 🫶.
These statistics displays SHOULD be available:
(1) A list of all the areas attached to the router, along with the authentication type to use for the area, the number of router interfaces attaching to the area, and the total number of nets and routers belonging to the area 🗺️.
For example, picture router RT3 from Figure 15. It has interfaces to two separate areas, Area 1 and the backbone (Area 0) 🦋. Table 20 shows that the backbone is using a simple password for authentication, and that Area 1 is not using any authentication 🔐. The number of nets includes IP networks, subnets, and hosts (this is the reason for 2 backbone nets -- they are the host routes corresponding to the serial line between backbone routers RT6 and RT10) 🧠.
Area ID # ifcs AuType # nets # routers
______________________________________________
0 1 1 2 7
1 2 0 4 4
Table 20: Sample OSPF area display.(2) A list of all the router's interfaces to an area, along with their addresses, output cost, current state, the (Backup) Designated Router for the attached network, and the number of neighbors currently associated with the interface 🔌. Some of these neighbors will have become adjacent, and the number of those is noted in the display too 💕.
Still looking at router RT3 in Figure 15: Table 21 shows that RT4 has been selected as Designated Router for network N3, and router RT1 has been selected as Backup 👑. Adjacencies have been established to both of them 🙌. Nobody besides RT3 is attached to network N4, so it becomes DR, but it still advertises the network as a stub in its router links advertisements 🍓.
Ifc IP address state cost DR Backup # nbrs # adjs
__________________________________________________________________________
192.1.1.3 DR other 1 192.1.1.4 192.1.1.1 3 2
192.1.4.3 DR 2 192.1.4.3 none 0 0
Table 21: Sample OSPF interface display.(3) The list of neighbors associated with a particular interface 👯. Each neighbor's IP address, router ID, state, and the length of the three link state advertisement queues (see Section 10) to the neighbor get displayed 📬.
Say router RT4 is the Designated Router for network N3, and router RT1 is the Backup Designated router 🧚. Also say the adjacency between router RT3 and RT1 hasn't fully formed yet 🥺. The display of router RT3's neighbors (associated with its interface to network N3) may then look like Table 22 🎀. It shows that RT3 and RT1 are still in the database exchange procedure, that RT3 has more Database Description packets to send to RT1, and that RT1 has at least one link state advertisement that RT3 doesn't 💅. There's also a single link state advertisement that has been flooded, but not acknowledged, to each neighbor that takes part in the flooding procedure (state >= Exchng) 🌸. (In the following examples we assume that a router's Router ID is assigned to be its smallest IP interface address 🧩.)
Nbr IP address Router ID state LS rxmt len DB summ len LS req len
____________________________________________________________________________
192.1.1.1 192.1.1.1 Exchng 1 10 1
192.1.1.2 192.1.1.2 2-Way 0 0 0
192.1.1.4 192.1.1.4 Full 1 0 0
Table 22: Sample OSPF neighbor display.(4) A list of the area's link state database 📚. This is the same in all of the routers attached to the area. It's made up of that area's router links, network links, and summary links advertisements. The AS external link advertisements are also part of all the areas' databases 🌈.
The link state database for Area 1 in Figure 15 might look like Table 23 (compare this with Figure 7) 🔍. Assume the Designated Router for network N3 is router RT4, like above. Both routers RT3 and RT4 are originating summary link advertisements into Area 1, since they're area border routers 🚪. Routers RT5 and RT7 are AS external routers 🛰️. Their location has to be described in summary links advertisements. Their AS external link advertisements are flooded throughout the entire AS 🌍.
Router RT3 can find its self-originated advertisements by looking for its own router ID (192.1.1.3) in the Advertising Router fields 🔎.
The LS sequence number, LS age, and LS checksum fields show the advertisement's instance 🪪. Their values are stored in the advertisement's link state header. We didn't bother making up values for the example 🙈.
LS type Link State ID Advertising Router LS seq no LS age LS checksum
_______________________________________________________________________________
1 192.1.1.1 192.1.1.1 * * *
1 192.1.1.2 192.1.1.2 * * *
1 192.1.1.3 192.1.1.3 * * *
1 192.1.1.4 192.1.1.4 * * *
_______________________________________________________________________________
2 192.1.1.4 192.1.1.4 * * *
_______________________________________________________________________________
3 Ia,Ib 192.1.1.3 * * *
3 N6 192.1.1.3 * * *
3 N7 192.1.1.3 * * *
3 N8 192.1.1.3 * * *
3 N9-N11,H1 192.1.1.3 * * *
3 Ia,Ib 192.1.1.4 * * *
3 N6 192.1.1.4 * * *
3 N7 192.1.1.4 * * *
3 N8 192.1.1.4 * * *
3 N9-N11,H1 192.1.1.4 * * *
4 RT5 192.1.1.3 * * *
4 RT7 192.1.1.3 * * *
4 RT5 192.1.1.4 * * *
4 RT7 192.1.1.4 * * *
_______________________________________________________________________________
4 N12 RT5's ID * * *
4 N13 RT5's ID * * *
4 N14 RT5's ID * * *
4 N12 RT7's ID * * *
LS type Link State ID Advertising Router LS seq no LS age LS checksum
_______________________________________________________________________________
4 N15 RT7's ID * * *
Table 23: Sample OSPF link state database display.(5) The contents of any particular link state advertisement 🧾. For example, a listing of the router links advertisement for Area 1, with LS type = 1 and Link State ID = 192.1.1.3, is shown in Section 12.4.1 💖.
(6) A listing of the entire routing table 🗂️. A few examples are in Section 11. The routing table is calculated from the combined databases of each attached area (see Section 16) 🧮. It may be desirable to sort the routing table by Type of Service, by destination, or a combination of the two 🌟.
E. Authentication
All OSPF protocol exchanges are authenticated 🔐. The OSPF packet header (see Section A.3.1) has an authentication type field, plus 64-bits of data for the appropriate authentication scheme (picked by the type field) 🎀.
The authentication type is configurable on a per-area basis 🗺️. Extra authentication data is configurable on a per-interface basis 🔧. For example, if an area uses a simple password scheme, a separate password MAY be configured for each network in the area 🔑.
Authentication types 0 and 1 are defined by this specification 📜. Every other authentication type is reserved for definition by the IANA (iana@ISI.EDU) 🏛️. The current list of authentication types is below in Table 24 💅.
AuType Description
_______________________________________________________________
0 No authentication
1 Simple password
All others Reserved for assignment by the IANA (iana@ISI.EDU)
Table 24: OSPF authentication types.E.1 Autype 0 -- No authentication
With this authentication type, routing exchanges in the area are not authenticated 🙅. The 64-bit field in the OSPF header can contain anything, and it isn't checked on packet reception 🫠.
E.2 Autype 1 -- Simple password
With this one, a 64-bit field is configured on a per-network basis 🔐. Every packet sent on a particular network MUST have this configured value in its OSPF header 64-bit authentication field 🗝️. Basically it's a "clear" 64-bit password 👀.
This guards against routers accidentally joining the area 🚧. They MUST first be configured with their attached networks' passwords before they can join the routing domain 🛡️.
F. Version 1 differences
This section covers the changes between OSPF version 1 and OSPF version 2 🦋. The impetus for these changes comes from comments received on RFC 1131 and recent field experience with the OSPF protocol 💭. Unfortunately, the changes are not backward-compatible 😭, so OSPF version 1 will not interoperate with OSPF version 2 🙈. Still, the changes are small in scope and SHOULD NOT greatly affect any existing implementations 🫶. Plus, some of the proposed changes SHOULD enable future protocol additions to be made in a backward-compatible manner (see Section F.4) ✨.
F.1 Protocol Enhancements
The following enhancements were made to the OSPF protocol 🌸.
F.1.1 Stub area support
In many Autonomous Systems, most of the OSPF link state database is AS external advertisements 🌍. In these Autonomous Systems, some OSPF areas MAY be organized so that external advertisements can be safely ignored, which enables a reduction of the area's
database size 🦋 This is for areas where there's only ONE exit/entry point that every externally addressed packet uses, or where a bit of suboptimal routing to outside destinations is totally fine 🫶
So there's an area config option (see Sections 3.6 and C.2) that lets you switch off importing external advertisements for an area. When it's on, no AS external advertisements get flooded into that area (Sections 13, 13.3 and 10.3). Instead, all data traffic headed to external destinations just follows a per-area default route ✨ These are the stub areas, bestie 🌸
Every area border router attached to a stub area originates a default summary link advertisement for the area (Section 12.4.3). That points all the internal routers at an area border router when they forward externally addressed packets 🧚 To keep stub areas configured consistently, there's a new Options field in OSPF Hello packets (Sections A.2 and A.3.2). A bit gets reset in that field to say the attached area is a stub area (Section 9.5). A router won't accept a neighbor's hellos unless they both agree on whether the area can process AS external advertisements (Section 10.5). So sysadmins can spot the misconfigured routers, and traffic routes around them (to avoid looping) until the config gets fixed 💅
F.1.2 Optional TOS support
OSPF conceptually has a separate routing table for each TOS. The calculations in steps 1-5 of Section 16 must be done separately for each TOS. (Link and summary costs don't need to be specified separately for each TOS. Costs for unspecified TOS values default to the TOS 0 cost 💖)
In version 1, all OSPF routers were required to route based on TOS. But building a separate routing table for every TOS can get pricey, memory-wise and processor-wise 😭 So version 2 lets the sysadmin configure routers to calculate and use only a single routing table, the TOS 0 table. Some traffic may take non-optimal routes, but all packets still get delivered and routing stays loop free (see Section 2.4) 🍓
To avoid loops, a router (router X) using a single table has to tell its peers. It does this by resetting the new TOS-capable bit in its router links advertisement (Section 12.4.1). Then, when peers run the Dijkstra calculation (Section 16.1) for non-zero TOS values, they omit router X from it. Basically, they try to bypass router X when forwarding non-zero TOS traffic 🙈 Summary link and AS external link advertisements can also say they're unavailable for non-zero TOS traffic (Sections 12.4.3 and 12.4.4).
Sometimes no route can be found for a non-zero TOS value. When that happens, the packet goes along the TOS 0 route instead (Section 11.1) 🎀
It's still mandatory for all OSPF implementations to be able to build separate routing tables for each TOS value, if the sysadmin wants them ✨
F.1.3 Preventing external extra-hops
Version 1 can add extra hops when calculating routes to external destinations. That's because the AS external advertisement format implies packets should be forwarded through the advertising router. Picture this: several OSPF routers share a LAN with an external router (call it router Y), but only one OSPF router (call it router X) exchanges routing info with Y. The other OSPF routers on that LAN forward packets for Y and beyond through X, which adds an extra hop (see Section 2.2) 🙄
The fix is a new field in AS external advertisements, the forwarding address. It says which router address packets should be forwarded to (Section 12.4.4). In the example above, router X puts Y's IP address in there. If the field is 0, packets still get forwarded to the advertisement's originator, like before. You can give a different forwarding address for each TOS value 🌈
Whenever possible, this field should be set to 0. Setting it to a real router address adds extra cost during the routing table build (Section 16.4) 💅
The forwarding address has two other uses. The first is for "route servers". A router in the middle of the Autonomous System can collect external routing info and originate AS external advertisements that name the correct exit route for each external destination (Section 2.2) 👑
The second can cut down how many AS external advertisements need to be imported. Say, in the example above, routers X and Z both exchange EGP info with the non-OSPF router Y. Then X and Z will likely both originate the same set of external routes 👀 Two AS external advertisements with the same (non-zero) forwarding address, destination and cost are functionally equivalent, no matter which router originated them. OSPF says the advertisement from the router with the largest Router ID is always the one used. That lets the other router flush its equivalent advertisement (Section 12.4.4) 🫶
F.2 Corrected problems
These problems in OSPF version 1 got fixed in version 2 ✨
F.2.1 LS sequence number space changes
The LS sequence number space changed from version 1's lollipop shape to a linear sequence space (Section 12.1.6). Sequence numbers are now compared as signed 32-bit integers, and advertisements with larger sequence numbers count as more recent 🔥 The space still starts at (-N+1), where N = 2**31. The value -N stays reserved. Each successive instance of an advertisement keeps incrementing until it hits the maximum, N-1. At that point, when a new instance has to be originated (because of a topology change or the expiration of the LS refresh timer), the current instance must first be "prematurely aged" 😭
There's a new section on premature aging (Section 14.1). It's how you flush a link state advertisement from the routing domain. The advertisement's age is set to MaxAge, and it gets reflooded just as if it were newly received. Once all the router's adjacent neighbors acknowledge that flooding, the advertisement is flushed from the database 💀
Premature aging can also be used when, say, a previously advertised external route is no longer reachable. In that case, premature aging is preferred over the alternative, which is originating a new advertisement for the destination with a metric of LSInfinity 🙅♀️
A router may only prematurely age its own self-originated link state advertisements. Those are the ones with the router's own OSPF router ID in the Advertising Router field 💜
F.2.2 Flooding of unexpected MaxAge advertisements
Version 1 skipped a special case in the flooding procedure: receiving a MaxAge advertisement that has no database instance. A paragraph was added to Section 13 to handle it. Without that paragraph, retransmissions of MaxAge advertisements could delay them being flushed from the routing domain 🙃
F.2.3 Virtual links and address ranges
When summarizing info into a virtual link's transit area, version 2 prohibits collapsing multiple backbone IP networks/subnets into a single summary link. This restriction was added to deal with certain weird OSPF area configurations 🌀 See Sections 15 and 12.4.3 for more.
F.2.4 Routing table lookup explained
When forwarding an IP data packet, a router looks up the packet's IP destination in the routing table. That determines the packet's next hop. A new section (Section 11.1) describes the routing table lookup, instead of just saying "best match". It clarifies OSPF's four-level routing hierarchy (intra-area, inter-area, external type 1 and external type 2 routes), and it specifies how TOS affects routing 🧠
F.2.5 Sending Link State Request packets
Version 2 eases up on sending Link State Request packets. They can now go to a neighboring router before a complete set of Database Description packets has been exchanged 🙌 That makes better use of a router's memory. A version 2 implementation may limit the size of the neighbor Link state request lists. See Sections 10.9, 10.7 and 10.3 for details.
F.2.6 Changes to the Database description process
The spec was modified so that when two routers sync their databases during the Database Description process, none of the component link state advertisements can have their sequence numbers decrease. An advertisement's sequence number decreases when it gets flushed via premature aging and then reoriginated with the smallest sequence number, 0x80000001 (see Section 14.1). So now an advertisement can't be flushed from a router's database until both a) it no longer appears on any neighbor Link State Retransmission list and b) none of the router's neighbors are in states Exchange or Loading. See Sections 13 (step 4c) and 14.1 for more 📚
There's also a new step in the flooding procedure (Section 13) to make the Database Description process more robust 💅 It detects when a neighbor lists one instance of an advertisement in its Database Description packets but answers Link State Request packets by sending an earlier instance. That now generates the event BadLSReq, which restarts the Database Description process with that neighbor. In version 1, the neighbor event BadLSReq wrongly did not restart the Database Description process 🫠
F.2.7 Receiving OSPF Hello packets
The section on receive processing of OSPF Hello packets (Section 10.5) now includes generating the neighbor Backup Seen event. The Designated Router election section (Section 9.4) was also modified to include the algorithm's initial state 🧚♀️
F.2.8 Network mask defined for default route
When the default route shows up as the destination in an AS external link advertisement or a summary link advertisement, its network mask is now set to 0.0.0.0 🎀 See Sections A.4.4 and A.4.5 for more.
F.2.9 Rate limit imposed on flooding
When an advertisement is installed in the link state database, it gets timestamped. The flooding procedure isn't allowed to install a new instance of that advertisement until MinLSInterval seconds have passed. That's a rate limit: a new instance can only be flooded once every MinLSInterval seconds ⏳ It guards against routers that ignore the limit on self-originated advertisements (already in OSPF version 1) of one origination every MinLSInterval seconds. For more, see Section 13 🍓
F.3 Packet format changes
Okay so the packet changes are where OSPF gets its glow-up 💖 Some of these were needed to power the new stuff, and others were just about making packets easier to parse. Main character energy, honestly 🎀
F.3.1. Adding a Capability bitfield
To support the new "stub area" and "optional TOS" features, there's now a capability bitfield 🦋 It gets added to the Hello packet, the Database Description packet, and every link state advertisement. In Hello packets, a router can reject a neighbor if the capabilities don't match ✋ In Database Description packets, a router can choose not to forward certain link state advertisements to a neighbor that has reduced functionality 🙈 And in link state advertisements, listing capabilities lets routers route traffic around a reduced functionality router by leaving it out of parts of the routing table calculation 🧚 For the deets, see Section A.2 💜
F.3.2. Packet simplification
To simplify Database Description and Link State Acknowledgment packets, the way they describe link state advertisements has been changed 🍓 Each advertisement is now described by its 20-byte link state header (see Section A.4). Bonus: this doesn't use any extra space in the packets 🫶 The one extra piece of info that shows up is the LS length. You don't need to use that field when processing Database Description and Link State Acknowledgment packets 🌸
F.3.3. Adding forwarding addresses to AS external advertisements
As we covered in Section F.1.3, AS external advertisements now have a forwarding address field 🌈
F.3.4. Labelling of virtual links
Virtual links get labelled as such in router links advertisements 🏷️ This separates them from unnumbered point-to-point links, so all backbone routers can figure out whether any virtual links are in use 👑 See Section 12.4.1 for more.
F.3.5. TOS costs ordered
When a link state advertisement gives a separate cost for each TOS, those costs must be ordered by increasing TOS value. Like, the cost for TOS 16 must always come after the cost for TOS 8 🔥
F.3.6. OSPF's TOS encoding redefined
The way OSPF encodes TOS in its link state advertisements got redefined in version 2 🦋 OSPF's encoding of the Delay (D), Throughput (T) and Reliability (R) TOS flags, which come from [RFC 791], is described in Section 12.3 ✨
F.4 Backward-compatibility provisions ✨
Additional functionality will probably get added to OSPF down the road 🔮 One example is a multicast routing capability, which is still under development. So that new features can be added in a backward-compatible way, the OSPF specification includes the following provisions 💅
New capabilities will probably mean introducing new link state advertisements. If a router gets a link state advertisement of unknown type during the flooding procedure, that advertisement is simply ignored (see Section 13). The router should not try to flood it further, nor acknowledge it. It should not be installed in the link state database. If a router gets an advertisement of unknown type during the Database Description process, that's an error (see Sections 10.6 and 10.3), and the Database Description process gets restarted 🔄
There's also an Options field in the Hello packets, the Database Description packets, and the link state advertisement headers 🎀 Unrecognized capabilities found in these spots should be ignored, and they should not affect the normal processing of protocol packets or link state advertisements (see Sections 10.5 and 10.6). Routers originate their Hello packets, Database Description packets, and link state advertisements with unrecognized capabilities set to 0 (see Sections 9.5, 10.8 and 12.1.2) 🫶
Security Considerations 🔐
🚨 Okay, this part is SERIOUS bestie. Every OSPF protocol exchange is authenticated. That happens through authentication fields contained in the OSPF packet header. Want the full story? Check out Sections 8.1, 8.2, and Appendix E 🔐💀
Author's Address 💌
John Moy
Proteon, Inc.
2 Technology Drive
Westborough, MA 01581
Phone: (508) 898-2800
EMail: jmoy@proteon.com📦 where this page comes from
- ietf: rfc1247 1991-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms