RFC 1583
OSPF Version 2
RFC 1583: OSPF Version 2 💖
Network Working Group 🌸 Okay bestie, this RFC is from March 1994, and it's a Standards Track document, so it's a real protocol spec people build against. It's written by J. Moy from Proteon, Inc. 🎀 It obsoletes RFC 1247, which means this is the newer, upgraded version of the older OSPF doc. 🦋
Status of this Memo ✨
Okay so this doc is an Internet standards track protocol for the whole Internet community, and it's basically inviting everyone to talk about it and suggest improvements 🫶 For the official standardization state of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1), because that's the source of truth. And the good news: distribution of this memo is unlimited, so share it with everyone 💅
Abstract 🌈
Okay, the vibe of OSPF is seriously iconic. This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol, and it's built to run inside a single Autonomous System 💜 Every OSPF router keeps an identical database describing the topology of that Autonomous System, and then each router uses that database to build a routing table by making a shortest-path tree. It's giving teamwork 🧚
OSPF also recalculates routes really fast when the topology changes, and it does that while using a minimum amount of routing protocol traffic ⭐ It supports equal-cost multipath, and it can calculate separate routes for each IP Type of Service 🍓 It also has an area routing capability, which adds another layer of routing protection and cuts down on routing protocol traffic 👑 And the big one: all OSPF routing protocol exchanges are authenticated 🔥 Literally no sketchy messages allowed.
OSPF Version 2 was originally documented in RFC 1247. The differences between RFC 1247 and this memo are explained in Appendix E 💖 They're mostly bug fixes and clarifications, and they're backward-compatible in nature, so implementations of RFC 1247 and this memo will interoperate ✨ Main character energy for the upgrade, no drama 🙈
Comments go to ospf@gated.cornell.edu 💌
Table of Contents 🧚
1 Introduction ........................................... 5
1.1 Protocol Overview ...................................... 5
1.2 Definitions of commonly used terms ..................... 6
1.3 Brief history of link-state routing technology ......... 9
1.4 Organization of this document .......................... 9
2 The Topological Database .............................. 10
2.1 The shortest-path tree ................................ 13
2.2 Use of external routing information ................... 16
2.3 Equal-cost multipath .................................. 20
2.4 TOS-based routing ..................................... 20
3 Splitting the AS into Areas ........................... 21
3.1 The backbone of the Autonomous System ................. 22
3.2 Inter-area routing .................................... 22
3.3 Classification of routers ............................. 23
3.4 A sample area configuration ........................... 24
3.5 IP subnetting support ................................. 30
3.6 Supporting stub areas ................................. 31
3.7 Partitions of areas ................................... 32
4 Functional Summary .................................... 34
4.1 Inter-area routing .................................... 35
4.2 AS external routes .................................... 35
4.3 Routing protocol packets .............................. 35
4.4 Basic implementation requirements ..................... 38
4.5 Optional OSPF capabilities ............................ 39
5 Protocol data structures .............................. 41
6 The Area Data Structure ............................... 42
7 Bringing Up Adjacencies ............................... 45
7.1 The Hello Protocol .................................... 45
7.2 The Synchronization of Databases ...................... 46
7.3 The Designated Router ................................. 47
7.4 The Backup Designated Router .......................... 48
7.5 The graph of adjacencies .............................. 49
8 Protocol Packet Processing ............................ 50
8.1 Sending protocol packets .............................. 51
8.2 Receiving protocol packets ............................ 53
9 The Interface Data Structure .......................... 55
9.1 Interface states ...................................... 58
9.2 Events causing interface state changes ................ 61
9.3 The Interface state machine ........................... 62
9.4 Electing the Designated Router ........................ 65
9.5 Sending Hello packets ................................. 67
9.5.1 Sending Hello packets on non-broadcast networks ....... 68
10 The Neighbor Data Structure ........................... 69
10.1 Neighbor states ....................................... 72
10.2 Events causing neighbor state changes ................. 75
10.3 The Neighbor state machine ............................ 77
10.4 Whether to become adjacent ............................ 83
10.5 Receiving Hello Packets ............................... 83
10.6 Receiving Database Description Packets ................ 86
10.7 Receiving Link State Request Packets .................. 89
10.8 Sending Database Description Packets .................. 89
10.9 Sending Link State Request Packets .................... 90
10.10 An Example ............................................ 91
11 The Routing Table Structure ........................... 93
11.1 Routing table lookup .................................. 96
11.2 Sample routing table, without areas ................... 97
11.3 Sample routing table, with areas ...................... 98
12 Link State Advertisements ............................ 100
12.1 The Link State Advertisement Header .................. 101
12.1.1 LS age ............................................... 102
12.1.2 Options .............................................. 102
12.1.3 LS type .............................................. 103
12.1.4 Link State ID ........................................ 103
12.1.5 Advertising Router ................................... 105
12.1.6 LS sequence number ................................... 105
12.1.7 LS checksum .......................................... 106
12.2 The link state database .............................. 107
12.3 Representation of TOS ................................ 108
12.4 Originating link state advertisements ................ 109
12.4.1 Router links ......................................... 112
12.4.2 Network links ........................................ 118
12.4.3 Summary links ........................................ 120
12.4.4 Originating summary links into stub areas ............ 123
12.4.5 AS external links .................................... 124
13 The Flooding Procedure ............................... 126
13.1 Determining which link state is newer ................ 130
13.2 Installing link state advertisements in the database . 130
13.3 Next step in the flooding procedure .................. 131
13.4 Receiving self-originated link state ................. 134
13.5 Sending Link State Acknowledgment packets ............ 135
13.6 Retransmitting link state advertisements ............. 136
13.7 Receiving link state acknowledgments ................. 138
14 Aging The Link State Database ........................ 139
14.1 Premature aging of advertisements .................... 139
15 Virtual Links ........................................ 140
16 Calculation Of The Routing Table ..................... 142
16.1 Calculating the shortest-path tree for an area ....... 143
16.1.1 The next hop calculation ............................. 149
16.2 Calculating the inter-area routes .................... 150
16.3 Examining transit areas' summary links ............... 152
16.4 Calculating AS external routes ....................... 154
16.5 Incremental updates -- summary link advertisements ... 156
16.6 Incremental updates -- AS external link advertisements 157
16.7 Events generated as a result of routing table changes 157
16.8 Equal-cost multipath ................................. 158
16.9 Building the non-zero-TOS portion of the routing table 158
Footnotes ............................................ 161
References ........................................... 164
A OSPF data formats .................................... 166
A.1 Encapsulation of OSPF packets ........................ 166
A.2 The Options field .................................... 168
A.3 OSPF Packet Formats .................................. 170
A.3.1 The OSPF packet header ............................... 171
A.3.2 The Hello packet ..................................... 173
A.3.3 The Database Description packet ...................... 175
A.3.4 The Link State Request packet ........................ 177
A.3.5 The Link State Update packet ......................... 179
A.3.6 The Link State Acknowledgment packet ................. 181
A.4 Link state advertisement formats ..................... 183
A.4.1 The Link State Advertisement header .................. 184
A.4.2 Router links advertisements .......................... 186
A.4.3 Network links advertisements ......................... 190
A.4.4 Summary link advertisements .......................... 192
A.4.5 AS external link advertisements ...................... 194
B Architectural Constants .............................. 196
C Configurable Constants ............................... 198
C.1 Global parameters .................................... 198
C.2 Area parameters ...................................... 198
C.3 Router interface parameters .......................... 200
C.4 Virtual link parameters .............................. 202
C.5 Non-broadcast, multi-access network parameters ....... 203
C.6 Host route parameters ................................ 203
D Authentication ....................................... 205
D.1 AuType 0 -- No authentication ........................ 205
D.2 AuType 1 -- Simple password .......................... 205
E Differences from RFC 1247 ............................ 207
E.1 A fix for a problem with OSPF Virtual links .......... 207
E.2 Supporting supernetting and subnet 0 ................. 208
E.3 Obsoleting LSInfinity in router links advertisements . 209
E.4 TOS encoding updated ................................. 209
E.5 Summarizing routes into transit areas ................ 210
E.6 Summarizing routes into stub areas ................... 210
E.7 Flushing anomalous network links advertisements ...... 210
E.8 Required Statistics appendix deleted ................. 211
E.9 Other changes ........................................ 211
F. An algorithm for assigning Link State IDs ............ 213
Security Considerations .............................. 216
Author's Address ..................................... 2161. Introduction ✨
This document is the spec for OSPF 💖, the Open Shortest Path First TCP/IP internet routing protocol ✨. It's classified as an Interior Gateway Protocol (IGP) 🎀, which means it shares routing information between routers that all belong to one single Autonomous System 🌸. OSPF is built on link-state or SPF technology, which is a total glow-up from the Bellman-Ford base that traditional TCP/IP internet routing protocols use 💅.
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force 🦋. It was designed expressly for the TCP/IP internet environment, with explicit support for IP subnetting, TOS-based routing and tagging of externally-derived routing information 🫶. OSPF also authenticates 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 keeping the amount of routing protocol traffic small 🔥.
The author would like to thank Fred Baker, Jeffrey Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo Medin, Kannan Varadhan 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 IP Type of Service found in the IP packet header 🎯. IP packets are routed "as is" -- they are not encapsulated in any further protocol headers as they transit the Autonomous System 🧚. OSPF is a dynamic routing protocol, and it quickly detects topological changes in the AS (like router interface failures) and calculates new loop-free routes after a period of convergence 💫. This convergence period is short and involves a minimum of routing traffic, which is honestly so iconic 👑.
In a link-state routing protocol, each router maintains a database describing the Autonomous System's topology 🗺️. Each participating router has an identical database. Each individual piece of this database is a particular router's local state (e.g., the router's usable interfaces and reachable neighbors) 🍓. The router distributes its local state throughout the Autonomous System by flooding 🌊.
All routers run the exact same algorithm, in parallel 👯♀️. From the topological database, each router constructs a tree of shortest paths with itself as root 🌳. This shortest-path tree gives the route to each destination in the Autonomous System. Externally derived routing information appears 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 is distributed equally among them. The cost of a route is described by a single dimensionless metric 📏.
OSPF allows sets of networks to be grouped together, and such a grouping is called an area 🏡. The topology of an area is hidden from the rest of the Autonomous System, and this information hiding enables a significant reduction in routing traffic 🙈. Also, routing within the area is determined only by the area's own topology, which gives the area protection from bad routing data 🛡️. An area is a generalization of an IP subnetted network 💖.
OSPF enables the flexible configuration of IP subnets 🎀. Each route distributed by OSPF has a destination and mask. Two different subnets of the same IP network number may have different sizes (i.e., different masks). This is commonly referred to as variable length subnetting 🦋. A packet is routed to the best (i.e., longest or most specific) match. Host routes are considered to be subnets whose masks are "all ones" (0xffffffff) 🎯.
All OSPF protocol exchanges are authenticated 🔐. This means that only trusted routers can participate in the Autonomous System's routing. A variety of authentication schemes can be used, but a single authentication scheme is configured for each area. This enables some areas to use much stricter authentication than others 💪.
Externally derived routing data (e.g., routes learned from the Exterior Gateway Protocol (EGP)) is passed transparently throughout the Autonomous System 🚀. This externally derived data is kept separate from the OSPF protocol's link state data. Each external route can also be tagged by the advertising router, which enables the passing of additional information between routers on the boundaries of the Autonomous System 🏷️.
1.2. Definitions of commonly used terms 📚
This section provides definitions for terms that have a specific meaning to the OSPF protocol and that are used throughout the text 🤓. If you're unfamiliar with the Internet Protocol Suite, the reader is referred to [RS-85-153] for an introduction to IP 📖.
Router A level three Internet Protocol packet switch. Formerly called a gateway in much of the IP literature 🔀.
Autonomous System A group of routers exchanging routing information via a common routing protocol. Abbreviated as AS 🌐.
Interior Gateway Protocol The routing protocol spoken by the routers belonging to an Autonomous system. Abbreviated as IGP. Each Autonomous System has a single IGP. Separate Autonomous Systems may be running different IGPs 🗣️.
Router ID A 32-bit number assigned to each router running the OSPF protocol. This number uniquely identifies the router within an Autonomous System 🪪.
Network In this memo, an IP network/subnet/supernet. It is possible for one physical network to be assigned multiple IP network/subnet numbers. We consider these to be separate networks. Point-to-point physical networks are an exception: they are considered a single network no matter how many (if any at all) IP network/subnet numbers are assigned to them 🛤️.
Network mask A 32-bit number indicating the range of IP addresses residing on a single IP network/subnet/supernet. This specification displays network masks as hexadecimal numbers. For example, the network mask for a class C IP network is displayed as 0xffffff00. Such a mask is often displayed elsewhere in the literature as 255.255.255.0 🎭.
Multi-access networks Those 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 (e.g., multi-drop networks are excluded) 🫂.
Interface The connection between a router and one of its attached networks. An interface has state information associated with it, which is obtained from the underlying lower level protocols and the routing protocol itself. An interface to a network has associated with it a single IP address and mask (unless the network is an unnumbered point-to-point network). An interface is sometimes also referred to as a link 🔌.
Neighboring routers Two routers that have interfaces to a common network. On multi-access networks, neighbors are dynamically discovered by OSPF's Hello Protocol 👋.
Adjacency A relationship formed between selected neighboring routers for the purpose of exchanging routing information. Not every pair of neighboring routers become adjacent 💞.
Link state advertisement Describes the local state of a router or network. This includes the state of the router's interfaces and adjacencies. Each link state advertisement is flooded throughout the routing domain. The collected link state advertisements of all routers and networks forms 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 Each multi-access network that has 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 the running of the protocol. The Designated Router is elected by the Hello Protocol 👑.
The Designated Router concept enables a reduction in the number of adjacencies required on a multi-access network. This in turn reduces the amount of routing protocol traffic and the size of the topological database 📉.
Lower-level protocols The underlying network access protocols that provide services to the Internet Protocol and in turn the OSPF protocol. Examples of these are the X.25 packet and frame levels for X.25 PDNs, and the ethernet data link layer for ethernets 🧱.
1.3. Brief history of link-state routing technology 🕰️
OSPF is a link state routing protocol. Such protocols are also referred to in the literature as SPF-based or distributed-database protocols. This section gives a brief description of the developments in link-state technology that have influenced the OSPF protocol 🎞️.
The first link-state routing protocol was developed for use in the ARPANET packet switching network. This protocol is described in [McQuillan]. It has formed the starting point for all other link-state protocols. The homogeneous Arpanet environment, i.e., single-vendor packet switches connected by synchronous serial lines, simplified the design and implementation of the original protocol 🌱.
Modifications to this protocol were proposed in [Perlman]. These modifications dealt with increasing the fault tolerance of the routing protocol through, among other things, adding a checksum to the link state advertisements (thereby detecting database corruption). The paper also included means for reducing the routing traffic overhead in a link-state protocol. This was accomplished by introducing mechanisms which enabled the interval between link state advertisement originations to be increased by an order of magnitude 🧠.
A link-state algorithm has also been proposed for use as an ISO IS-IS routing protocol. This protocol is described in [DEC]. The protocol includes methods for data and routing traffic reduction when operating over broadcast networks. This is accomplished by election of a Designated Router for each broadcast network, which then originates a link state advertisement for the network 📡.
2. The Topological Database ✨
1.4. Organization of this document 🧚
okay so the first three sections are the chill overview, bestie 🌸 they explain what the protocol can do and how it works at a high level. Sections 4-16 are where we get into the nitty gritty of the mechanisms 🔥. The packet formats, protocol constants, and configuration items all live in the appendices 📚.
Labels like HelloInterval that pop up in the text are protocol constants 💖. They might be configurable, or they might not, so keep that in mind 🙈. The architectural constants get explained in Appendix B, and the configurable ones get explained in Appendix C 🎀.
The spec describes the protocol using data structures, because that makes the explanation way more precise ✨. Implementations need to support the functionality described, but they don't have to use the exact data structures in this memo 🫶. Pick whatever works for your code, periodt 💅.
The big picture, iykyk: the topological database is the heart of OSPF 💜. Let's get into it 🦋.
The Autonomous System's topological database 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 that connects a router to a network means that the router has an interface on that network ✨.
The vertices can be typed even further by function 🧚. Only some of these types carry transit data traffic, which just means 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 that support many (more than two) attached routers, along with the ability to address a single physical message to all of the attached routers (broadcast) ✨. Neighboring routers get discovered dynamically on these nets using OSPF's Hello Protocol 👀. The Hello Protocol itself takes advantage of the broadcast capability 🙌. The protocol also uses multicast capabilities if they exist 🌸. An ethernet is an example of a broadcast network 🎀.
- Non-broadcast networks 🚫📡 Networks that support many (more than two) routers but have no broadcast capability 😭. Neighboring routers are also discovered on these nets using OSPF's Hello Protocol 🦋. However, because there's no broadcast capability, some configuration information is necessary for the Hello Protocol to work correctly 🙈. On these networks, OSPF protocol packets that would normally be multicast need to be sent to each neighboring router, one at a time, 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 two things: whether the network has multi-access capabilities (either broadcast or non-broadcast), and if it does, how many routers have an interface to the network 🧠. The three cases are shown in Figure 1 🖼️. In the figure, rectangles are routers, and 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 👉.
**FROM**
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Physical point-to-point networks
**FROM**
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|N2 |
+---+ +---+ * ------------------------
| N2 | * RT3| | | | | X |
+----------------------+ T RT4| | | | | X |
| | O RT5| | | | | X |
+---+ +---+ * RT6| | | | | X |
|RT5| |RT6| * N2| X | X | X | X | |
+---+ +---+ *
Multi-access networks
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Stub multi-access networks
Figure 1: Network map components
Networks and routers are represented by vertices.
An edge connects Vertex A to Vertex B iff the
intersection of Column A and Row B is marked with
an X.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 on physical point-to-point networks don't have to be assigned IP addresses 🤷♀️. A network like that is called unnumbered 🫧. The graph representation of point-to-point networks is designed so unnumbered networks can be supported naturally, which is so clever 🧠✨. When interface addresses do exist, they get modelled as stub routes 🧸. So each router would have a stub connection to the other router's interface address (check out Figure 1 for this one 👀).
When multiple routers are attached to a multi-access network, the directed graph shows all of those routers bidirectionally connected to the network vertex (again, Figure 1 has you covered 🥰). If only a single router is attached to a multi-access network, the network shows up in the directed graph as a stub connection 🌱.
Each network in the graph, whether stub or transit, has an IP address and an associated network mask 🎯. The mask tells you the number of nodes on the network 🔢. Hosts attached directly to routers (called host routes) appear 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 shows a sample map of an Autonomous System 🗺️. The rectangle labelled H1 is a host with a SLIP connection to Router RT12, so Router RT12 advertises a host route 💻. Lines between routers mean physical point-to-point networks 🧵. The only point-to-point network with assigned interface addresses is the one joining Routers RT6 and RT10 💅. Routers RT5 and RT7 have EGP connections to other Autonomous Systems 🌍. Both of those routers display a set of EGP-learned routes 📍.
Every router output interface has a cost attached to it 💸. The system administrator can configure this cost 🛠️. The lower the cost, the more likely the interface is to be used to forward data traffic 🚀. Costs are also associated with the externally derived routing data, like 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, so don't ignore them 👑. Also, the externally derived routing data shows up on the graph as stubs 🌿.
The topological database (the thing we've been calling the directed graph) gets pieced together from the link state advertisements that routers generate 🧩. The neighborhood of each transit vertex lives 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 🌟. Network N6 is a broadcast network with three attached routers 🙌. The cost of all links from Network N6 to its attached routers is 0 💖. The link state advertisement for Network N6 is actually generated by one of the attached routers, namely the router that was 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, leading to an
Okay bestie, the routing table math is about to get very cute 🎀 Figure 2 is our sample Autonomous System, and it's giving full chaos 🌸
+
| 3+---+ N12 N14
N1|--|RT1|\ 1 \ N13 /
| +---+ \ 8\ |8/8
+ \ ____ \|/
/ \ 1+---+8 8+---+6
* N3 *---|RT4|------|RT5|--------+
\____/ +---+ +---+ |
+ / | |7 |
| 3+---+ / | | |
N2|--|RT2|/1 |1 |6 |
| +---+ +---+8 6+---+ |
+ |RT3|--------------|RT6| |
+---+ +---+ |
|2 Ia|7 |
| | |
+---------+ | |
N4 | |
| |
| |
N11 | |
+---------+ | |
| | | N12
|3 | |6 2/
+---+ | +---+/
|RT9| | |RT7|---N15
+---+ | +---+ 9
|1 + | |1
_|__ | Ib|5 __|_
/ \ 1+----+2 | 3+----+1 / \
* N9 *------|RT11|----|---|RT10|---* N6 *
\____/ +----+ | +----+ \____/
| | |
|1 + |1
+--+ 10+----+ N8 +---+
|H1|-----|RT12| |RT8|
+--+SLIP +----+ +---+
|2 |4
| |
+---------+ +--------+
N10 N7
Figure 2: A sample Autonomous SystemHere's the FROM table, which is where the real fun starts 💅
**FROM**
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
----- ---------------------------------------------
RT1| | | | | | | | | | | | |0 | | | |
RT2| | | | | | | | | | | | |0 | | | |
RT3| | | | | |6 | | | | | | |0 | | | |
RT4| | | | |8 | | | | | | | |0 | | | |
RT5| | | |8 | |6 |6 | | | | | | | | | |
RT6| | |8 | |7 | | | | |5 | | | | | | |
RT7| | | | |6 | | | | | | | | |0 | | |
* RT8| | | | | | | | | | | | | |0 | | |
* RT9| | | | | | | | | | | | | | | |0 |
T RT10| | | | | |7 | | | | | | | |0 |0 | |
O RT11| | | | | | | | | | | | | | |0 |0 |
* RT12| | | | | | | | | | | | | | | |0 |
* N1|3 | | | | | | | | | | | | | | | |
N2| |3 | | | | | | | | | | | | | | |
N3|1 |1 |1 |1 | | | | | | | | | | | | |
N4| | |2 | | | | | | | | | | | | | |
N6| | | | | | |1 |1 | |1 | | | | | | |
N7| | | | | | | |4 | | | | | | | | |
N8| | | | | | | | | |3 |2 | | | | | |
N9| | | | | | | | |1 | |1 |1 | | | | |
N10| | | | | | | | | | | |2 | | | | |
N11| | | | | | | | |3 | | | | | | | |
N12| | | | |8 | |2 | | | | | | | | | |
N13| | | | |8 | | | | | | | | | | | |
N14| | | | |8 | | | | | | | | | | | |
N15| | | | | | |9 | | | | | | | | | |
H1| | | | | | | | | | | |10| | | | |
Figure 3: The resulting directed graphNetworks and routers are vertices in this graph 🦋 An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X. ✨
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.Everyone ends up with the same graph, which is ~iconic~ identical graphical representation 💜 Each router builds its routing table from this graph by calculating a tree of shortest paths with itself as the root. The shortest-path tree depends on which router is doing the calculating, so every router gets its own tree 🌈 The tree for Router RT6 in our example is in Figure 5.
**FROM** **FROM**
|RT12|N9|N10|H1| |RT9|RT11|RT12|N9|
* -------------------- * ----------------------
* RT12| | | | | * RT9| | | |0 |
T N9|1 | | | | T RT11| | | |0 |
O N10|2 | | | | O RT12| | | |0 |
* H1|10 | | | | * N9| | | | |
* *
RT12's router links N9's network links
advertisement advertisement
Figure 4: Individual link state components
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.The tree gives the entire route to any destination network or host 🧚 Only the next hop gets used in forwarding though, so that's the bit that matters most. The best route to any router is calculated too. For external data, the router notes the next hop and distance to any router advertising external routes 💖 RT6's routing table is in Table 2, and there's a separate route for each end of a numbered serial line (here, the serial line between RT6 and RT10) 🍓
RT6(origin)
RT5 o------------o-----------o Ib
/|\ 6 |\ 7
8/8|8\ | \
/ | \ | \
o | o | \7
N12 o N14 | \
N13 2 | \
N4 o-----o RT3 \
/ \ 5
1/ RT10 o-------o Ia
/ |\
RT4 o-----o N3 3| \1
/| | \ N6 RT7
/ | N8 o o---------o
/ | | | /|
RT2 o o RT1 | | 2/ |9
/ | | |RT8 / |
/3 |3 RT11 o o o o
/ | | | N12 N15
N2 o o N1 1| |4
| |
N9 o o N7
/|
/ |
N11 RT9 / |RT12
o--------o-------o o--------o H1
3 | 10
|2
|
o N10
Figure 5: The SPF tree for Router RT6Edges without a marked cost have a cost of zero, since those are the network-to-router links 🎀 Routes to networks N12-N15 are external information, which gets handled in Section 2.2 💅
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.2.2. Use of external routing information ✨
Once the tree is built, the external routing information gets checked 🦋 That external info might come from another routing protocol like 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 info 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 means you don't have to convert external costs into internal link state metrics 🙈
Quick Type 1 example: suppose Routers RT7 and RT5 in Figure 2 are advertising Type 1 external metrics. For each external route, the distance from Router RT6 is the sum of the external route's cost and the distance from RT6 to the advertising router. For every external destination, the router advertising the shortest route is found, 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, but RT7 wins, bestie 💅 It's advertising N12 at a distance of 10 (8+2) to Router RT6, which beats 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.Type 2 external metrics are 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 external routes, all traffic for N12 would go to RT7, since 2 < 8 💖 When several equal-cost Type 2 routes exist, the internal distance to the advertising routers breaks the tie.
Type 1 and Type 2 external metrics can both be in the AS at the same time 👑 When that happens, Type 1 external metrics always take precedence.
Now, this section has assumed that packets for external destinations always go through the advertising AS boundary router. That's not always ideal 🙈 Say that in Figure 2 there's another router on Network N6 called Router RTX. RTX doesn't take part in OSPF routing, but it does swap EGP information with the AS boundary router RT7. Then RT7 would end up advertising OSPF external routes for every destination that should really go to RTX, and packets for those destinations might take an extra hop if they always have to go to RT7 first (the advertising router) 😭
To fix this, OSPF lets an AS boundary router put a "forwarding address" in its external advertisements. In the example above, RT7 would list RTX's IP address as the "forwarding address" for all those destinations whose packets should go straight to RTX.
The "forwarding address" has one more trick too 🧚 It lets routers inside the Autonomous System act as "route servers". For example, in Figure 2, RT6 could become a route server by picking up external routing information through a mix of static configuration and external routing protocols. RT6 would then start advertising itself as an AS boundary router and originate a bunch of OSPF external advertisements. In each one, RT6 would set the "forwarding address" field to the right Autonomous System exit point for that destination 🌈
2.3. Equal-cost multipath
So far we've pretended there's only one route to any destination, which was a little fib 🙈 In reality, if multiple equal-cost routes to a destination exist, they're all discovered and used. This doesn't change the algorithm conceptually, and we'll talk about it properly when we get into the tree-building process in more detail 🌸
With equal cost multipath, a router can 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 🎀 So for any destination, there can potentially be multiple routing table entries, one for each IP TOS. The IP TOS values are represented in OSPF exactly as they appear in the IP packet header ✨
Up to this point, every example has assumed routes don't vary by TOS. To differentiate routes by TOS, you can configure separate interface costs 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 by TOS, a separate shortest path tree is calculated for each TOS (see Section 2.1). External costs can vary by 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 gets added to the TOS X cost RT7 advertised for Network N15 (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 skips calculating non-zero TOS paths entirely. This can save routing table space and processing power on 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 groups of contiguous networks and hosts be bundled together 🧺 That group, plus the routers with interfaces to any of the included networks, is called an area. Each area runs its own separate copy of the basic link-state routing algorithm. So each area has its own topological database and corresponding graph, just like we covered in the previous section 💖
The topology of an area is invisible from outside the area 🙈 And routers inside an area know nothing about the detailed topology outside it. This isolation of knowledge lets the protocol cut routing traffic way down compared to treating the whole Autonomous System as one link-state domain 🌈
With areas in the picture, not all routers in the AS have an identical topological database anymore 😭 A router actually keeps a separate topological database for each area it's connected to. (Routers connected to multiple areas are called area border routers.) Two routers in the same area have identical area topological databases for that area 👑
Routing in the Autonomous System happens on two levels 💅 It depends 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 from outside the area can be used, which protects intra-area routing from bad routing information getting injected 🛡️ We'll talk about inter-area routing in Section 3.2 🦋
3.1. The backbone of the Autonomous System
The backbone consists of the networks not contained in any area, their attached routers, and the routers that belong to multiple areas. The backbone must be contiguous 🦴
It's possible to define areas so the backbone is no longer contiguous. When that happens, 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, those two routers are joined by arcs whose costs are the intra-area distances between them. 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 the properties of an area. The topology of the backbone is invisible to each of the areas, while the backbone itself knows nothing about the topology of the areas 🎀
3.2. Inter-area routing
When routing a packet between two areas, the backbone gets used 🌊 The path 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 with the smallest cost ✨
Another way to picture it: inter-area routing forces a star configuration on the Autonomous System, with the backbone as the hub and each area as a spoke ⭐
The topology of the backbone dictates which backbone paths get used between areas. You can enhance the backbone topology by adding virtual links, which 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 that 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 showed up, the only OSPF routers with a specialized function were the ones advertising external routing information, like Router RT5 in Figure 2 🌷 Once the AS gets split into OSPF areas, 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 👑
Okay bestie, so the backbone routers are the routers that have an interface on the backbone 🦋. That includes every router that connects to more than one area (those are the area border routers). Backbone routers don't have to be area border routers, though 💅. And a router whose interfaces all sit on the backbone counts as an internal router.
AS boundary routers are the ones that swap routing info with routers in other Autonomous Systems 🌍. They carry AS external routes that get advertised all over the Autonomous System, and every router in the AS knows the path to each one ✨. This classification is totally separate from the other ones: an AS boundary router can be internal or an area border router, and it may or may not be on the backbone. Iconic independence 👑.
3.4. A sample area configuration 🦋
Okay so Figure 6 is the sample area setup and it's giving organized 🎀. Area 1 has networks N1-N4 plus their routers RT1-RT4. Area 2 has networks N6-N8 plus routers RT7, RT8, RT10 and RT11. Area 3 has networks N9-N11 and Host H1 plus routers RT9, RT11 and RT12. Area 3 is set up so N9-N11 and Host H1 all get grouped into a single route when they're advertised outside the area 🧚 (see Section 3.5 for the deets).
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 🌸. And like before, RT5 and RT7 are AS boundary routers 🔥.
...........................
. + .
. | 3+---+ . N12 N14
. N1|--|RT1|\ 1 . \ N13 /
. | +---+ \ . 8\ |8/8
. + \ ____ . \|/
. / \ 1+---+8 8+---+6
. * N3 *---|RT4|------|RT5|--------+
. \____/ +---+ +---+ |
. + / \ . |7 |
. | 3+---+ / \ . | |
. N2|--|RT2|/1 1\ . |6 |
. | +---+ +---+8 6+---+ |
. + |RT3|------|RT6| |
. +---+ +---+ |
. 2/ . Ia|7 |
. / . | |
. +---------+ . | |
.Area 1 N4 . | |
........................... | |
.......................... | |
. N11 . | |
. +---------+ . | |
. | . | | N12
. |3 . Ib|5 |6 2/
. +---+ . +----+ +---+/
. |RT9| . .........|RT10|.....|RT7|---N15.
. +---+ . . +----+ +---+ 9 .
. |1 . . + /3 1\ |1 .
. _|__ . . | / \ __|_ .
. / \ 1+----+2 |/ \ / \ .
. * N9 *------|RT11|----| * N6 * .
. \____/ +----+ | \____/ .
. | . . | | .
. |1 . . + |1 .
. +--+ 10+----+ . . N8 +---+ .
. |H1|-----|RT12| . . |RT8| .
. +--+SLIP +----+ . . +---+ .
. |2 . . |4 .
. | . . | .
. +---------+ . . +--------+ .
. N10 . . N7 .
. . .Area 2 .
.Area 3 . ................................
..........................Figure 6: A sample OSPF area configuration
Figure 7 is Area 1's topological database, and it totally describes that area's intra-area routing 🎀. It also gives the complete view of the internet for the two internal routers RT1 and RT2 ✨. Area border routers RT3 and RT4 have the job of advertising into Area 1 the distances to every destination outside the area 🧚. Those show up as the dashed stub routes in Figure 7. RT3 and RT4 also must advertise the location of the AS boundary routers RT5 and RT7 into Area 1 🌈. And external advertisements from RT5 and RT7 get flooded through the entire AS, including Area 1 💖. Those land in Area 1's database and give 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 🍓. Those summaries show which networks live in Area 1 (that's Networks N1-N4) and the distance from RT3 and RT4 to them.
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.
The backbone's topological database is in Figure 8 🔥. The pictured routers are the backbone routers. RT11 is a backbone router because it belongs to two areas 👑. To make the backbone connected, a virtual link gets configured between Routers R10 and R11 🦋.
Again, RT3, RT4, RT7, RT10 and RT11 are area border routers 💜. Like RT3 and RT4 did above, they've condensed their attached areas' routing info for distribution over the backbone. Those are the dashed stubs in Figure 8 ✨. Remember Area 3 is configured to condense N9-N11 and Host H1 into a single route, so Figure 8 shows one dashed line for them 🧚. RT5 and RT7 are AS boundary routers, and their externally derived info shows up in Figure 8 as stubs too 🌸.
The backbone is how area border routers swap summary info 💅. Every area border router hears the area summaries from all the other area border routers. Then it builds a picture of the distance to every network outside its area by looking at those advertisements and adding the backbone distance to each advertising router 🫶.
Using RT3 and RT4 as the example: first they calculate the SPF tree for the backbone 🌈. That gives the distances to all the other area border routers. They also note the distances to the networks (Ia and Ib) and AS boundary routers (RT5 and RT7) that live on the backbone. That calculation is in Table 5.
Next, by looking at the area summaries from those area border routers, RT3 and RT4 can work out the distance to every network outside their area 🔥. Then they advertise those distances internally to the area. The advertisements RT3 and RT4 make into Area 1 are in Table 6 💖.
**FROM**
|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |7 |N3|
----- -------------------
RT1| | | | | | |0 |
RT2| | | | | | |0 |
RT3| | | | | | |0 |
* RT4| | | | | | |0 |
* RT5| | |14|8 | | | |
T RT7| | |20|14| | | |
O N1|3 | | | | | | |
* N2| |3 | | | | | |
* N3|1 |1 |1 |1 | | | |
N4| | |2 | | | | |
Ia,Ib| | |15|22| | | |
N6| | |16|15| | | |
N7| | |20|19| | | |
N8| | |18|18| | | |
N9-N11,H1| | |19|16| | | |
N12| | | | |8 |2 | |
N13| | | | |8 | | |
N14| | | | |8 | | |
N15| | | | | |9 | |Figure 7: Area 1's Database.
Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X.
**FROM**
|RT|RT|RT|RT|RT|RT|RT|
|3 |4 |5 |6 |7 |10|11|
------------------------
RT3| | | |6 | | | |
RT4| | |8 | | | | |
RT5| |8 | |6 |6 | | |
RT6|8 | |7 | | |5 | |
RT7| | |6 | | | | |
* RT10| | | |7 | | |2 |
* RT11| | | | | |3 | |
T N1|4 |4 | | | | | |
O N2|4 |4 | | | | | |
* N3|1 |1 | | | | | |
* N4|2 |3 | | | | | |
Ia| | | | | |5 | |
Ib| | | |7 | | | |
N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |1 |
N12| | |8 | |2 | | |
N13| | |8 | | | | |
N14| | |8 | | | | |
N15| | | | |9 | | |Figure 8: The backbone's database.
Networks and routers are represented by vertices. An edge of cost X connects Vertex A to Vertex B iff the intersection of Column A and Row B is marked with an X.
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 14
Table 5: Backbone distances calculated
by Routers RT3 and RT4.Bestie, quick heads up before we go on 💅 Table 6 assumes that an area range has been configured for the backbone that groups Ia and Ib into a single advertisement 🫶
The info that RT3 and RT4 import into Area 1 is so useful 🦋 It lets an internal router, like RT1, pick an area border router intelligently ✨ RT1 would use RT4 for traffic to Network N6, RT3 for traffic to Network N10, and would load share between the two for traffic to Network N8 🔥
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 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.RT1 can also work out the shortest path to the AS boundary routers RT5 and RT7 this same way 🌸 Then it checks RT5 and RT7's external advertisements and decides between RT5 or RT7 when sending to a destination in another Autonomous System (one of the networks N12-N15) 👑
⚠️ Heads up: if the line between Routers RT6 and RT10 fails, the backbone becomes disconnected 💀
A virtual link between Routers RT7 and RT10 gives the backbone more connectivity and more resistance to failures like that 🧚 Also, a virtual link between RT7 and RT10 would allow a much shorter path between the third area (containing N9) and the 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 that route describes. 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 subnetting possible 🌈 Basically, a single IP class A, B, or C network number can be broken up into lots of subnets of different sizes. For example, the network 128.185.0.0 could be broken up into 62 variable-sized subnets: 15 subnets of size 4K, 15 subnets of size 256, and 32 subnets of size 8 🍓 Table 7 shows some of the resulting network addresses along 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 8
Table 7: Some sample subnet sizes.There are a bunch of ways to divide a class A, B, or C network into variable sized subnets 🦋 The exact procedure is beyond the scope of this specification, so don't look for it here. What this spec does establish is this guideline: when an IP packet is forwarded, it is always forwarded to the network that is the best match for the packet's destination. "Best match" is just another way of saying 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, but really an OSPF area is specified to be a list of address ranges (see Section C.2 for more details). Each address range is defined as an [address,mask] pair. Lots of separate networks can live in 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 falling 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, hiding even the fact that it's 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 AS external advertisements 😭 An OSPF AS external advertisement is usually flooded throughout the entire AS. However, OSPF lets certain areas be configured as "stub areas" 🧚 AS external advertisements are not flooded into/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 that works 💅 One or more of the stub area's area border routers must advertise a default route into the stub area via summary link advertisements. These summary defaults are flooded throughout the stub area, but no further (for this reason, these defaults pertain only to that particular stub area) 🌈 These summary default routes will match any destination that is not explicitly reachable by an intra-area or inter-area path (i.e., AS external destinations) ✨
An area can be configured as stub when there is 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 must travel through its single area border router RT11. If Area 3 were configured as a stub, Router RT11 would advertise a default route for distribution inside Area 3 (in a summary link advertisement), instead of flooding the AS external advertisements for Networks N12-N15 into/throughout the area 🍓
OSPF makes sure all routers in an area agree on whether the area is configured as a stub 🫶 That way, no confusion creeps into the flooding of AS external advertisements 👑
There are a couple of restrictions on stub areas, so watch out 🙈 Virtual links cannot be configured through stub areas. Also, 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, and the backbone then does routing between the new areas. Some destinations that were reachable via intra-area routing before the partition will now require inter-area routing 🌸
Remember, an area was described as a list of address ranges earlier on. Any particular address range must still be completely contained in a single component of the area partition 💜 This has to do with how area contents get summarized to the backbone. Also, the backbone itself must not partition. If it does, parts of the Autonomous System will become unreachable 😭 Backbone partitions can be repaired by configuring virtual links (see Section 15) 🔥
Another way to think about area partitions is to look at the Autonomous System graph that was introduced in Section 2 🌈 Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. Either way, the edge is colored with the network's Area ID 🦋
A group of edges that all have the same color and are interconnected by vertices represents an area 🧚 If the topology of the Autonomous System is intact, the graph will have several regions of color, each color being a distinct Area ID 💖
When the AS topology changes, one of the areas may become partitioned. The graph of the AS will then have multiple regions of the same color (Area ID) 🥹 Routing in the Autonomous System keeps working as long as these regions of the same color are connected by the single backbone region ✨
4. Functional Summary ✨
A separate copy of OSPF's basic routing algorithm runs in each area 👑 Routers with interfaces to multiple areas run multiple copies of the algorithm. Here's a quick summary of the routing algorithm 💅
When a router starts, it first initializes the routing protocol data structures 🌸 Then it waits for indications from the lower-level protocols that its interfaces are functional 🫶
Next, a router uses OSPF's Hello Protocol to acquire neighbors 🎀 It sends Hello packets to its neighbors and, in turn, receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters 🦋 On non-broadcast networks, some configuration information is necessary to discover neighbors 🙈 On all multi-access networks (broadcast or non-broadcast), the Hello Protocol also elects a Designated router for the network 👑
The router will attempt to form adjacencies with some of its newly acquired neighbors 🦋 Topological databases get synchronized between pairs of adjacent routers, and on multi-access networks, the Designated Router decides which routers should become adjacent 👑
Adjacencies control the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies, so distribution of topological database updates goes along adjacencies too 💅
A router periodically advertises its state, which is also called link state ✨ Link state gets advertised when a router's state changes, too. A router's adjacencies show up in the contents of its link state advertisements, and that relationship is how the protocol can detect dead routers in a timely fashion 🫶
Link state advertisements are flooded throughout the area, and the flooding algorithm is reliable, so all routers in an area end up with exactly the same topological database 🔥 That database is the collection of link state advertisements received from each router belonging to the area. From it, each router calculates a shortest-path tree with itself as the root, and that tree yields a routing table for the protocol 🌸
4.1. Inter-area routing
The previous section covered how the protocol works within a single area 🎀 For intra-area routing, no other routing information is pertinent. To route to destinations outside the area, the area border routers inject additional routing information into the area. That extra info is a distillation of the rest of the Autonomous System's topology 🧚
Here's how the distillation works 💖 Each area border router is by definition connected to the backbone. Each area border router summarizes the topology of its attached areas for transmission on the backbone, and therefore to all other area border routers. An area border router then has complete topological information about the backbone, plus the area summaries from each of the other area border routers. From all of that, the router calculates paths to all destinations not contained in its attached areas, and then advertises those paths into its attached areas. This lets the area's internal routers pick the best exit router when forwarding traffic to destinations in other areas 👑✨
4.2. AS external routes
Routers that have information about other Autonomous Systems can flood that information throughout the AS 🌈 This external routing information is distributed verbatim to every participating router. There's one exception: external routing information is not flooded into "stub" areas (see Section 3.6) 🙈
To use external routing information, the path to all routers advertising external information must be known throughout the AS (except in 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
The OSPF protocol runs directly over IP, using IP protocol 89 🔥 OSPF doesn't provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly gets used. OSPF protocol packets were designed so that large protocol packets can generally be split into several smaller protocol packets. This 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, routing protocol packets should be given preference over regular IP data traffic, both when being sent and when being received. To help make that happen, OSPF protocol packets should have their IP precedence field set to the value Internetwork Control (see [RFC 791]) ✨
All OSPF protocol packets share a common protocol header, which is described in Appendix A 🎀 The OSPF packet types are listed below in Table 8, and their formats are also described 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 🫶 The Database Description and Link State Request packets are used in forming adjacencies. OSPF's reliable update mechanism is implemented by the Link State Update and Link State Acknowledgment packets 🌸
Each Link State Update packet carries a set of new link state advertisements, one hop further away from their point of origination 😭 A single Link State Update packet may contain the link state advertisements of several routers. Each advertisement is tagged with the ID of the originating router and a checksum of its link state contents. The five different types of OSPF link state advertisements are listed below in Table 9 🔥
As mentioned above, OSPF routing packets (except Hellos) are sent only over adjacencies 💅 That means all OSPF protocol packets travel a single IP hop, except those sent over virtual adjacencies. The IP source address of an OSPF protocol packet is one end of a router adjacency, and the IP destination address is either the other end of the adjacency or an IP multicast address 👑
LS Advertisement Advertisement description
type name
_________________________________________________________
1 Router links Originated by all routers.
advertisements This 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
advertisements networks by the Designated
Router. This advertisement
contains the list of routers
connected to the network.
Flooded throughout a single
area only.
_________________________________________________________
3,4 Summary link Originated by area border
advertisements routers, and flooded through-
out the advertisement's
associated area. Each summary
link advertisement describes
a route to a destination out-
side 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 link Originated by AS boundary
advertisements routers, and flooded through-
out the AS. Each AS external
link advertisement describes
a route to a destination in
another Autonomous System.
Default routes for the AS can
also be described by AS
external link advertisements.
Table 9: OSPF link state advertisements.4.4. Basic implementation requirements
An implementation of OSPF requires the following pieces of system support 🧚
Timers
Two different kinds of timers are required 💖 The first kind, called single shot timers, fire once and cause a protocol event to be processed. The second kind, called interval timers, fire at continuous intervals, and these are used for sending packets at regular intervals. A good example is the regular broadcast of Hello packets (on broadcast networks) 📡 The granularity of both kinds of timers is one second ⭐
Interval timers should be implemented to avoid drift 🌸 In some router implementations, packet processing can affect timer execution. When multiple routers are attached to a single network, all doing broadcasts, this can lead to the synchronization of routing packets, which should be avoided 😭 If timers cannot 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 take the form of IP multicast datagrams. Support for receiving and sending IP multicast datagrams, along with the appropriate lower-level protocol support, is required ✨ The IP multicast datagrams used by OSPF never travel more than one hop. For this reason, the ability to forward IP multicast datagrams is not required 🦋 For information on IP multicast, see [RFC 1112] 🫶
Variable-length subnet support
The router's IP protocol support must include the ability to divide a single IP class A, B, or C network number into many subnets of various sizes 👑 This is commonly called variable-length subnetting, and Section 3.5 has the details 💅
IP supernetting support
The router's IP protocol support must include the ability to aggregate contiguous collections of IP class A, B, and C networks into larger quantities called supernets 🌈 Supernetting has been proposed as one way to improve the scaling of IP routing in the worldwide Internet. For more information on IP supernetting, see [RFC 1519] 🧚
Lower-level protocol support
The lower-level protocols referred to here are the network access protocols, such as the Ethernet data link layer 🔌 Indications must be passed from these protocols to OSPF as the network interface goes up and down. For example, on an ethernet, it would be valuable to know when the ethernet transceiver cable becomes unplugged 😭🍓
Remember that non-broadcast networks are multi-access networks, like an X.25 PDN 🫶. On these networks, the Hello Protocol can get a boost if OSPF gets a heads-up whenever someone tries to send a packet to a dead or non-existent router 💀. For example, on an X.25 PDN, a dead neighbor can be flagged by receiving an X.25 clear with an appropriate cause and diagnostic, and that info gets passed up to OSPF ✨.
List manipulation primitives 📝
Tons of OSPF functionality is described in terms of messing with lists of link state advertisements 💅. For example, the group of advertisements that keep getting resent to an adjacent router until it acks them is treated as a list 🧚. One advertisement can be sitting on lots of these lists at once 🦋, so an OSPF implementation needs to be able to juggle them, adding and deleting advertisements as needed ✨.
Tasking support 🎀
Some procedures in this spec call other procedures 🔥. Sometimes those other procedures SHOULD be run in-line, meaning before the current one wraps up 💅. The text flags this with instructions to execute a procedure. Other times, they only run once the current procedure is finished, which is flagged by instructions to schedule a task 🌈.
4.5. Optional OSPF capabilities 👑
OSPF defines several optional capabilities 🌈. A router tells everyone which ones it supports by including them in its OSPF Hello packets, Database Description packets, and link state advertisements 💖. This way, routers with a mix of capabilities can all hang out in one Autonomous System 🫶.
Some capabilities MUST be supported by all routers attached to a specific area 😭. So a router won't accept a neighbor's Hello packet unless the reported capabilities match. A capability mismatch blocks the neighbor relationship from forming, periodt 💀. ExternalRoutingCapability is an example.
Other capabilities can be negotiated during the Database Exchange process 🦋. This happens by listing the optional capabilities in Database Description packets. If the capabilities don't match with a neighbor here, only a subset of link state advertisements gets exchanged between the two 🙈.
Capabilities can also change how the routing table gets built 🧠. Since they're reported in link state advertisements, routers that can't do certain functions can be avoided when building the shortest path tree ✨. TOS routing capability is an example of this.
Here's the full list of current OSPF optional capabilities 🍓 (peep Section A.2 for more info 💜).
ExternalRoutingCapability 🏡
Entire OSPF areas can be configured as "stubs" (see Section 3.6) 🌿. AS external advertisements won't be flooded into stub areas 💅. This capability is shown by the E-bit in the OSPF options field (see Section A.2). To keep stub areas configured consistently, all routers interfacing with 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, it only calculates routes for TOS 0 💅. This capability is shown by the T-bit in the OSPF options field (see Section A.2). TOS-capable routers will try to steer clear of non-TOS-capable routers when calculating non-zero TOS paths 🙈.
5. Protocol Data Structures 🧩
The OSPF protocol is described in this spec in terms of how it operates on various protocol data structures 🤓. The list below covers the top-level OSPF data structures, and any initialization that needs doing is noted 🔥. OSPF areas, interfaces and neighbors also have their own data structures, which get covered later in the spec 💜.
Router ID 🆔
A 32-bit number that uniquely identifies this router in the AS 💅. One possible implementation strategy would be to use the smallest IP interface address belonging to the router. If a router's OSPF Router ID changes, its OSPF software SHOULD be restarted before the new Router ID takes effect. Before restarting to change its Router ID, the router SHOULD flush its self-originated link state advertisements from the routing domain (see Section 14.1), or they'll persist for up to MaxAge minutes 😱.
Area structures 🏠
Each area the router is connected to has its own data structure 🏡. It describes how the basic algorithm works in that area 🧠. Remember that each area runs its own separate copy of the basic algorithm 💖.
Backbone (area) structure 🦴
The basic algorithm treats the backbone like it's just another area 💅, so the backbone gets represented as an area structure too ✨.
Virtual links configured 🔗
These are 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 💜. Those 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 get 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 outside the Autonomous System, 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 information to be advertised by OSPF with a configured metric) 🧭. Any router having these external routes is called an AS boundary router 👑. The router advertises these routes into the OSPF routing domain via 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 cover routes to destinations outside the Autonomous System 💅. Heads up: if the router is itself an AS boundary router, some of these AS external link advertisements were self-originated 🙈.
The routing table 🗺️
Derived from the topological database 🧠. Each destination 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 🗺️. Note that 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 ✨
okay bestie, this is the big one. the area data structure holds everything a router needs to run the basic routing algorithm 💅 each area keeps its own topological database, and a network belongs to exactly one area. a router interface connects to one area, and each router adjacency belongs to one area too. no sharing, no drama 🫶
the OSPF backbone has all the properties of an area, so it gets its own area data structure as well. the backbone is still a little different from the other areas, though, so some items in the structure apply to it differently. the backbone is a main character, but it's still special in its own way 👑
Figure 9 shows what Router RT10's data structures look like:
+----+
|RT10|------+
+----+ \+-------------+
/ \ |Routing Table|
/ \ +-------------+
/ \
+------+ / \ +--------+
|Area 2|---+ +---|Backbone|
+------+***********+ +--------+
/ \ * / \
/ \ * / \
+---------+ +---------+ +------------+ +------------+
|Interface| |Interface| |Virtual Link| |Interface Ib|
| to N6 | | to N8 | | to RT11 | +------------+
+---------+ +---------+ +------------+ |
/ \ | | |
/ \ | | |
+--------+ +--------+ | +-------------+ +------------+
|Neighbor| |Neighbor| | |Neighbor RT11| |Neighbor RT6|
| RT8 | | RT7 | | +-------------+ +------------+
+--------+ +--------+ |
|
+-------------+
|Neighbor RT11|
+-------------+
Figure 9: Router RT10's Data structuresthe area topological (or link state) database is the collection of router links, network links and summary link advertisements that came from the area's routers 🧚 this info only gets flooded throughout its own single area. the list of AS external link advertisements (see Section 5) also counts as part of each area's topological database 🌸
Area ID A 32-bit number that identifies the area. 0.0.0.0 is reserved for the Area ID of the backbone. if you're assigning subnetted networks as separate areas, the IP network number can be used as the Area ID 🎀
List of component address ranges the address ranges that define the area. each address range is an [address,mask] pair with a status of either Advertise or DoNotAdvertise (see Section 12.4.3). each network gets assigned to an area based on which address range it falls into, and specified address ranges are not allowed to overlap 🙅♀️ as an example, if an IP subnetted network is going to be its own separate OSPF area, the area is defined by a single address range: an IP network number with its natural (class A, B or C) mask ✨
Associated router interfaces this router's interfaces that connect 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 links. a virtual link is identified by the Router ID of its other endpoint, and its cost is the cost of the shortest intra-area path through the Transit area that exists between the two routers 🦋
List of router links advertisements a router links advertisement gets 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 gets generated for each transit multi-access network in the area. it describes the set of routers currently connected to the network 🌈
List of summary link advertisements summary link advertisements come from the area's area border routers. they describe routes to destinations that are internal to the Autonomous System but external to the area 👑
Shortest-path tree the shortest-path tree for the area, with this router itself as the root. it's derived from the collected router links and network links advertisements by the Dijkstra algorithm (see Section 16.1) 🔥
AuType the type of authentication used for this area. authentication types are defined in Appendix D. all OSPF packet exchanges are authenticated, and different areas can use different authentication schemes 🔐
TransitCapability set to TRUE if and only if there are one or more active virtual links using the area as a Transit area. put another way, this parameter tells you whether the area can carry data traffic that neither originates nor terminates in the area itself ✨ this parameter is calculated when the area's shortest-path tree is built (see Section 16.1), and it's used as an input to a later step of the routing table build process (see Section 16.3) 🧚
ExternalRoutingCapability whether AS external advertisements will be flooded into/throughout the area. this is a configurable parameter 🎀 if AS external advertisements are excluded from the area, the area is called a "stub" 🌸 inside stub areas, routing to AS 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 either. for more info, 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 tells you 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 info 💜
Unless otherwise specified, the rest of this document talks about how the protocol works inside a single area. you've got this, one area at a time 🌷
7. Bringing Up Adjacencies 🦋
OSPF creates adjacencies between neighboring routers so they can swap routing info 💖 not every pair of neighboring routers ends up adjacent, which is kind of a vibe. this section covers the basics of creating adjacencies. for the full details, check out Section 10 🍓
7.1. The Hello Protocol
the Hello Protocol handles 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 confirmed 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. the Designated Router controls, among other things, which adjacencies will be formed over the network (see below) 👑
the Hello Protocol works differently on broadcast networks than on non-broadcast networks 🌈 on broadcast networks, each router announces itself by periodically multicasting Hello Packets, so neighbors can be discovered dynamically. these Hello Packets contain the router's view of the Designated Router's identity, plus the list of routers whose Hello Packets have been seen recently 💅
on non-broadcast networks, some configuration info is needed for the Hello Protocol to work. each router that could potentially become Designated Router has a list of all the other routers attached to the network 🎀 a router with Designated Router potential sends Hello Packets to all the other potential Designated Routers when its interface to the non-broadcast network first comes up. this is an attempt to find the Designated Router for the network 🔥 if the router itself gets elected Designated Router, it starts sending Hello Packets to all the other routers attached to the network 🧚
once a neighbor has been discovered, bidirectional communication is ensured, and (if it's a multi-access network) a Designated Router has been elected, a decision is made about whether or not an adjacency should be formed with that neighbor (see Section 10.4). adjacencies are always attempted over point-to-point networks and virtual links 🦋 the first step in bringing up an adjacency is synchronizing the neighbors' topological databases. that's covered in the next section 💖
7.2. The Synchronization of Databases
in a link-state routing algorithm, it's super important that all the routers' topological databases stay synchronized 😭 OSPF keeps things simple by only requiring adjacent routers to stay synchronized with each other 🫶 the synchronization process kicks off as soon as the routers try 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 from the router's database 🌸 when the neighbor sees a link state advertisement that's more recent than its own 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) get acknowledged by the slave by echoing the sequence number 🎀 both the polls and their responses contain summaries of link state data. the master is the only one allowed to retransmit Database Description Packets, and it only does that at fixed intervals, whose length is the configured constant RxmtInterval ⏰
each Database Description contains an indication that there are more packets to follow, called 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 keeps a list of the link state advertisements where the neighbor has more up-to-date instances 🦋 these get requested in Link State Request Packets. Link State Request packets that aren't satisfied are retransmitted at fixed intervals of time RxmtInterval 🧚 once the Database Description Process has completed and all Link State Requests have been satisfied, the databases are considered synchronized and the routers are marked fully adjacent ✨ at that point the adjacency is fully functional and it's advertised in the two routers' link state advertisements 👑
the adjacency gets 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
Okay bestie, every multi-access network has a Designated Router, and the DR has two main jobs 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 is the main character of 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. Generally, when a router's interface to a network first becomes functional, it checks whether there is already 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 who the Designated Router will be, but it means 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 🌸. To optimize the flooding procedure on broadcast networks, the Designated Router multicasts its Link State Update Packets to the address AllSPFRouters, instead of sending separate packets over each adjacency.
Section 2 of this document talks about the directed graph representation of an area 🗺️. Router nodes are labelled with their Router ID. Multi-access network nodes are actually labelled with the IP address of their Designated Router. So when the Designated Router changes, it looks like the network node on the graph gets replaced by a brand new node 😭. This makes the network and all its attached routers originate new link state advertisements. Until the topological databases converge again, some temporary loss of connectivity may happen, and that can lead to ICMP unreachable messages being sent in response to data traffic 💀. That's why 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 🦋
To make the transition to a new Designated Router smoother, every multi-access network has a Backup Designated Router 🧚. The Backup Designated Router is also adjacent to all routers on the network, and it becomes Designated Router when the previous Designated Router fails. Without a Backup Designated Router, a new Designated Router would have to form new adjacencies with every other router on the network 😩. Part of forming an adjacency is synchronizing topological databases, which can take quite a long time. During that time, the network wouldn't be available for transit data traffic. The Backup Designated Router skips all that drama, since the adjacencies already exist. So the disruption to transit traffic only lasts as long as it takes to flood the new link state advertisements (the ones announcing 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. But 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 and lets the Designated Router do more of the work. That 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 🧶.
You can picture the collection of adjacencies on a network as an undirected graph 💖. The vertices are 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 Update Packets, through the Autonomous System 🌈.
There are two possible graphs, 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 the 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). That's the reason for the dashed lines connecting the Backup Designated Router RT3 🩵.
8. Protocol Packet Processing ✨
okay bestie, this section is about how routers handle OSPF routing protocol packets 🫶 and it's so important because the topological databases have to stay synchronized 🔥 so routing protocol packets get VIP treatment over ordinary data packets, both when they're sent AND when they're received 👑
Routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies) 🦋 picture it like this:
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3Figure 10: The graph of adjacencies
This means that all routing 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 spill the tea on how to fill in and verify this standard header. Then, for each packet type, you'll find the section 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 the standard OSPF packet header like this 🎀 for more details on the header format, check out 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 OSPF packet header.Router ID: The identity of the router itself (who is originating the packet).Area ID: The OSPF area that the packet is being sent into.Checksum: The standard IP 16-bit one's complement checksum of the entire OSPF packet, excluding the 64-bit authentication field. This checksum should be calculated before handing the packet to the appropriate authentication procedure.AuType and Authentication: Each OSPF packet exchange is authenticated 🔐 authentication types are assigned by the protocol and documented in Appendix D. A different authentication scheme can be used for each OSPF area. The 64-bit authentication field is set by the appropriate authentication procedure (determined by AuType). This procedure should be the last called when forming the packet to be sent. The setting of the authentication field is determined by the packet contents and the authentication key (which is configurable on a per-interface basis).
Now for the IP destination address, which is giving main character energy 💜 On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), the majority of OSPF packets are sent as unicasts, meaning sent directly to the other end of the adjacency. In that case, the IP destination is just the Neighbor IP address associated with the other end of the adjacency (see Section 10). The only packets not sent as unicasts are on broadcast networks 🍓 on those networks, Hello packets are sent to the multicast destination AllSPFRouters, the Designated Router and its Backup send both Link State Update Packets and Link State Acknowledgment Packets to the multicast address AllSPFRouters, and all other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters 🧚
Retransmissions of Link State Update packets are ALWAYS sent as unicasts 🙈
The IP source address should be set to the IP address of the sending interface. Interfaces to unnumbered point-to-point networks have no associated IP address 💀 on these interfaces, the IP source should be set to any of the other IP addresses belonging to the router. For this reason, there must be at least one IP address assigned to the router.[2] Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IP interface address (discovered during the routing table build process), which is used as the IP source when sending packets over the virtual link ✨
For more information on the format of specific OSPF packet types, check the sections listed 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.5Table 10: Sections describing OSPF protocol packet transmission.
8.2. Receiving protocol packets
Whenever a protocol packet is received by the router, it gets marked with the interface it was received on 🦋 for routers that have virtual links configured, it may not be immediately obvious which interface to associate the packet with. For example, consider the Router RT11 depicted in Figure 6. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.[3] 🫠
In order for the packet to be accepted at the IP level, it must pass a number of tests, even before the packet is passed to OSPF for processing 🛡️
- The IP checksum must be correct.
- The packet's IP destination address must be the IP address of the receiving interface, or one of the IP multicast addresses
AllSPFRoutersorAllDRouters. - The IP protocol specified must be OSPF (89).
- Locally originated packets should not be passed on to OSPF. That is, the source IP address should be examined to make sure this is not a multicast packet that the router itself generated.
Next, the OSPF packet header gets verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded 🙅♀️
- The version number field must specify protocol version 2.
- The 16-bit one's complement checksum of the OSPF packet's contents must be verified. Remember that the 64-bit authentication field must be excluded from the checksum calculation.
- The Area ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID specified in the header must either:
- (1) Match the Area ID of the receiving interface. In this case, the packet has been sent over a single hop. Therefore, the packet's IP source address must be on the same network as the receiving interface. This can be determined by comparing the packet's IP source address to the interface's IP address, after masking both addresses with the interface mask. This comparison should not be performed on point-to-point networks. On point-to-point networks, the interface addresses of each end of the link are assigned independently, if they are assigned at all.
- (2) Indicate the backbone. In this case, the packet has been sent over a virtual link. The receiving router must be an area border router, and the Router ID specified 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 succeed, the packet is accepted and is from now on associated with the virtual link (and the backbone area) 🌈
- Packets whose IP destination is
AllDRoutersshould only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1). - The AuType specified in the packet must match the AuType specified for the associated area.
Next, the packet must be authenticated 🔐 this depends on the AuType specified (see Appendix D). The authentication procedure may use an Authentication key, which can be configured on a per-interface basis. If the authentication fails, the packet should be discarded.
If the packet type is Hello, it should then be further processed by the Hello Protocol (see Section 10.5). All other packet types are sent and received only on adjacencies, which means the packet must have been sent by one of the router's active neighbors 👯 if the receiving interface is a multi-access network (either broadcast or non-broadcast), the sender is identified by the IP source address found in the packet's IP header. If the receiving interface is a point-to-point link or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPF header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded 🗑️
At this point, all received protocol packets are associated with an active neighbor ✨ for the further input processing of specific packet types, check the sections listed 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.7Table 11: Sections describing OSPF protocol packet reception.
9. The Interface Data Structure 🎀
Okay so this is the interface section, and it's giving main character energy 💅 An OSPF interface is basically 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. Supporting multiple addresses on one network is something they're leaving for later 👀
An OSPF interface counts as part of the area that contains its attached network. Every routing protocol packet the router sends out this interface gets labelled with the interface's Area ID 🏷️ Multiple router adjacencies can form over one interface, and the router's link state advertisements reflect how its interfaces and their adjacencies are doing. Iconic self-awareness 🪞
Here's the tea: a bunch of these items are really configuration for the attached network, so they must be the same for every router connected to that network. Literally everyone has to agree 🫶
Here's everything attached to an interface:
- Type 🛣️: The kind of network the interface attaches to. The value is broadcast, non-broadcast yet still multi-access, point-to-point, or virtual link.
- State 🚦: The functional level of the interface. State decides whether full adjacencies are allowed to form over the interface, and it also shows up in the router's link state advertisements.
- IP interface address 🏠: The IP address tied to the interface. It shows up as the IP source address in every routing protocol packet sent over this interface. Interfaces to unnumbered point-to-point networks don't have one at all 🙈
- IP interface mask 🎭: Also called the subnet mask. It marks which portion of the IP interface address identifies the attached network. Masking the IP interface address with the IP interface mask gives you the IP network number of that network. On point-to-point networks and virtual links, the IP interface mask isn't defined. The link itself doesn't get an IP network number, so each side's addresses get assigned on their own, if they get assigned at all 🤷♀️
- Area ID 🗺️: The Area ID of the area the attached network belongs to. Every routing protocol packet from this interface gets labelled with it.
- HelloInterval ⏰: How many seconds pass between the Hello packets the router sends on this interface. It's advertised in the Hello packets sent out this interface.
- RouterDeadInterval 💀: The number of seconds neighbors wait, after they stop hearing the router's Hello packets, before they declare it down. It's advertised in the Hello packets sent out this interface.
- InfTransDelay 🚚: The estimated number of seconds it takes to transmit a Link State Update Packet over this interface. Link state advertisements inside that packet get their age increased by this amount before they're sent. This value should take transmission and propagation delays into account, and it must be greater than zero ⏱️
- Router Priority 👑: An 8-bit unsigned integer. When two routers on the same network both try to become Designated Router, the one with the highest Router Priority wins. A router with Router Priority set to 0 can't become Designated Router on that network. It's advertised in the Hello packets sent out this interface.
- Hello Timer 🔔: An interval timer that makes the interface send a Hello packet. It fires every HelloInterval seconds. 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, it selects a Designated Router on the network. The timer runs for RouterDeadInterval seconds.
- List of neighboring routers 👯: The other routers attached to this network. On multi-access networks, the Hello Protocol forms this list. Adjacencies will form with some of these neighbors, and you can figure out which neighbors are adjacent by looking at all of their states.
- Designated Router 🌟: The Designated Router selected for the attached network. On every multi-access network, the Hello Protocol picks it. Two pieces of info are stored for it: its Router ID and its IP interface address on the network. The Designated Router advertises link state for the network, and that network link state advertisement is labelled with the Designated Router's IP address. It starts out as 0.0.0.0, which means there isn't a Designated Router yet.
- Backup Designated Router 🥈: Also picked by the Hello Protocol on every multi-access network. Every router on the attached network becomes adjacent to both the Designated Router and the Backup Designated Router. If the current Designated Router fails, the Backup Designated Router steps up and becomes the Designated Router. It starts out as 0.0.0.0, which means there isn't a Backup Designated Router yet 🦸♀️
- Interface output cost(s) 💸: The cost of sending a data packet over the interface, measured in the link state metric. It's 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 🔁: The number of seconds between link state advertisement retransmissions for adjacencies that belong to this interface. It's also used when retransmitting Database Description and Link State Request packets.
- Authentication key 🔐: This configured data lets the authentication procedure generate and/or verify the Authentication field in the OSPF header. The Authentication key can be configured per interface. For example, if the AuType is simple password, the Authentication key would be a 64-bit password. That key goes straight into the OSPF header when routing protocol packets get originated, and each network can have its own password.
9.1. Interface states 🚦✨
Okay this part is about the different states a router interface can be in. They're listed from least to most functional, so the inoperative state comes first, then a bunch of intermediate states, and then the final fully working one. The spec actually relies on that ordering, sometimes saying things like "those interfaces in state greater than X" 🧠 Figure 11 shows how the interface state changes move around. Each arc is labelled with the event that causes the change, and those events are documented in Section 9.2. The interface state machine gets a more detailed description in Section 9.3 📚
+----+ UnloopInd +--------+
|Down|<--------------|Loopback|
+----+ +--------+
|
|InterfaceUp
+-------+ | +--------------+
|Waiting|<-+-------------->|Point-to-point|
+-------+ +--------------+
|
WaitTimer|BackupSeen
|
|
| NeighborChange
+------+ +-+<---------------- +-------+
|Backup|<----------|?|----------------->|DROther|
+------+---------->+-+<-----+ +-------+
Neighbor | |
Change | |Neighbor
| |Change
| +--+
+---->|DR|
+--+Figure 11: Interface State changes 🖼️
On top of the transitions pictured, the event InterfaceDown always forces the Down State, and the event LoopInd always forces the Loopback State. No exceptions, periodt 💅
Down 🕳️
This is the initial interface state. Here the lower-level protocols have said the interface isn't usable. No protocol traffic at all gets sent or received on such a interface. In this state, interface parameters should be set to their initial values. All interface timers should be disabled, and there shouldn't be any adjacencies tied to the interface. Super clean slate energy ✨
Loopback 🔄
In this state, the router's interface to the network is looped back. That can happen in hardware or in software. The interface is unavailable for regular data traffic. Still, it might be useful to learn about the quality of this interface, either by sending ICMP pings to it or through something like a bit error test 🔍 That's why IP packets can 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, where the destination is the IP interface address.[4] Lowkey genius 🧪
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 Hello packets it receives. The router isn't allowed to elect a Backup Designated Router or a Designated Router until it leaves the Waiting state. That stops unnecessary changes to the (Backup) Designated Router, which is honestly so thoughtful 🥹
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. Hello packets go out to the neighbor every HelloInterval seconds 📡
DR Other 🙋♀️
The interface is connected to a multi-access network where some other router has already been picked as the Designated Router. In this state, the router itself hasn't been picked as Backup Designated Router either. It forms adjacencies to both the Designated Router and the Backup Designated Router, if they exist 🫂
Backup 🫶 This is when the router itself is the Backup Designated Router on the attached network. If the current Designated Router fails, this router gets promoted to Designated Router 💅. It establishes adjacencies to all the other routers attached to the network. The Backup Designated Router does slightly different things during the Flooding Procedure than the Designated Router does (see Section 13.3), and you can find more on its jobs in Section 7.4 📖✨
DR 👑 This is when this router itself is the Designated Router on the attached network. It establishes adjacencies to all the other routers on the network, and it must also originate a network links advertisement for the network node. That advertisement lists links to every router attached to the network, including the Designated Router itself 🌸. Check out Section 7.3 for the full breakdown of what the Designated Router does 🔥
9.2. Events causing interface state changes
State changes can be triggered by a bunch of different events 🦋 They're the labelled arcs in Figure 11, and the label definitions are listed below. If you want the full scoop on how each event affects OSPF protocol operation, go to Section 9.3 💜
InterfaceUp 🧚 Lower-level protocols have told us the network interface is operational. This lets the interface move out of the Down state. On virtual links, that operational indication actually comes from the shortest path calculation (see Section 16.7) 🌈
WaitTimer ⏰ The Wait Timer has fired. That means the waiting period is over, which is required before electing a (Backup) Designated Router 🎀
BackupSeen 👀 The router has spotted whether a Backup Designated Router exists for the network or not. There are two ways this happens. First, a Hello Packet might arrive from a neighbor who says it's the Backup Designated Router. Or, a Hello Packet might arrive from a neighbor who says it's the Designated Router and also says there is no Backup Designated Router. Either way, there must be bidirectional communication with that neighbor, so the router must also appear in the neighbor's Hello Packet 🙈 This event ends the Waiting state 🎉
NeighborChange 🔄 The set of bidirectional neighbors on the interface has changed, so the (Backup) Designated Router needs to be recalculated. These neighbor changes are what trigger the NeighborChange event. For what the neighbor states mean, see Section 10.1 💅
- Bidirectional communication has been set up with a neighbor. In other words, the neighbor's state has moved to 2-Way or higher ✨
- Bidirectional communication with a neighbor is gone. In other words, the neighbor's state has dropped to Init or lower 💀
- One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. This gets caught by reading 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. This also gets caught by reading that neighbor's Hello Packets 😭
- The advertised Router Priority for a bidirectional neighbor has changed. Again, this is detected by reading that neighbor's Hello Packets 🍓
LoopInd 🔁 The router has been told that the interface is now looped back to itself. That info can come from network management or from the lower level protocols 💜
UnloopInd 🔓 The router has been told the interface is no longer looped back. Just like LoopInd, this can come from network management or from the lower level protocols 🌸
InterfaceDown 💔 Lower-level protocols say this interface isn't functional anymore. It doesn't matter what the interface state is right now, because the new interface state will be Down 🫠
9.3. The Interface state machine
Okay, this part is the detailed play-by-play of the interface state changes 🎀 Each change is kicked off by an event (Section 9.2). The effect can be different depending on what state the interface is in at the time. That's why the state machine is organized by current interface state and then by received event. Each entry tells you the new interface state and the set of additional actions that are required 💖
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 involve generating events for the neighbor state machine. For example, when an interface becomes inoperative, all neighbor connections tied to that interface must be destroyed. For more on the neighbor state machine, see Section 10.3 ✨
State(s): Down
Event: InterfaceUp
New state: Depends upon 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, in an attempt 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: BackupSeen
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: WaitTimer
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): DR Other, Backup or DR
Event: NeighborChange
New state: Depends upon action routine.
Action: Recalculate 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): Any State
Event: InterfaceDown
New state: Down
Action: All interface variables are reset, and interface
timers disabled. Also, all neighbor connections
associated with the interface are destroyed. This
is done by generating the event KillNbr on all
associated neighbors (see Section 10.2). State(s): Any State
Event: LoopInd
New state: Loopback
Action: Since this interface is no longer connected to the
attached network the actions associated with the
above InterfaceDown event are executed. State(s): Loopback
Event: UnloopInd
New state: Down
Action: No actions are necessary. For example, the
interface variables have already been reset upon
entering the Loopback state. Note that reception of
an InterfaceUp event is necessary before the
interface again becomes fully functional.9.4. Electing the Designated Router
This section walks through the algorithm used to calculate a network's Designated Router and Backup Designated Router 🗳️ The Interface state machine is what invokes this algorithm. The first time a router runs the election for a network, the network's Designated Router and Backup Designated Router are set to 0.0.0.0. That value means there's no Designated Router and no Backup Designated Router yet 🫧
Here's how the Designated Router election goes. The router doing the calculation is called Router X 🧠 Next, we check the list of neighbors attached to the network that have established bidirectional communication with Router X. This list is exactly the set of Router X's neighbors on this network whose state is 2-Way or higher (see Section 10.1). Router X itself is also put on the list 💅 Then we throw out every router on the list that isn't eligible to become Designated Router. (Routers with a Router Priority of 0 are not eligible to become Designated Router.) After that, the following steps run, 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. These get used later for comparison purposes 💜
(2) okay so step 2 is all about picking the new Backup Designated Router 🦋 Only the routers on the list that have not declared themselves to be Designated Router are eligible. If one or more of them have declared themselves Backup Designated Router (so they're listing themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets), the one with the highest Router Priority gets the job. Ties go to the highest Router ID 💅 If nobody has declared themselves Backup Designated Router, the router with the highest Router Priority wins instead (again skipping anyone who has declared themselves Designated Router), and the Router ID breaks any ties.
(3) Next up is the new Designated Router ✨ If one or more routers have declared themselves Designated Router (they're listing themselves as Designated Router in their Hello Packets), the one with the highest Router Priority is declared the Designated Router. Ties go to the highest Router ID again. If nobody has declared themselves Designated Router, the Designated Router is just whoever was picked as the newly elected Backup Designated Router 🌸
(4) If Router X is now newly the Designated Router or newly the Backup Designated Router, or is now no longer either one, repeat steps 2 and 3, and then move on to step 5 🔥 For example, if Router X is now the Designated Router, then when step 2 gets repeated, X isn't eligible for Backup Designated Router anymore. This is the part that makes sure no router ends up declaring itself both Backup Designated Router and Designated Router at the same time 🙈[5]
(5) So after all those calculations, the router itself might now be the Designated Router or the Backup Designated Router 👑 Check Sections 7.3 and 7.4 for the extra duties that come with it. The router's interface state should be set to match. If the router itself is now the Designated Router, the new interface state is DR. If it's now the 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 Hello Packets to the neighbors that aren't eligible to become Designated Router (see Section 9.5.1) 🦋 To do that, 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 will need to be modified 🌈 Some adjacencies may need to form, and others may need to break. To make that happen, invoke the event AdjOK? on all neighbors whose state is at least 2-Way. That makes them re-examine their eligibility for adjacency (see Sections 10.3 and 10.4) 💖
The reason this election algorithm is so complicated is that the designers wanted an orderly handoff from Backup Designated Router to Designated Router when the current Designated Router fails 😭 That smooth handoff comes from hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities 🫶
The procedure above may elect the same router as both Designated Router and Backup Designated Router, though that router will never be the calculating router (Router X) itself 💀 The elected Designated Router doesn't have to be the router with the highest Router Priority, and the Backup Designated Router won't necessarily have the second highest one either 🧚 If Router X isn't itself eligible to become Designated Router, it's possible that neither a Backup Designated Router nor a Designated Router gets selected by this procedure. And if Router X is the only attached router that's eligible to become Designated Router, it'll select itself as Designated Router, and there won't be a Backup Designated Router for the network ✨
9.5. Sending Hello packets 📡
Hello packets are sent out of each functioning router interface 🌸 They're used to discover and maintain neighbor relationships.[6] On multi-access networks, Hello Packets also help elect the Designated Router and Backup Designated Router, which is how they figure out which adjacencies should be formed 🦋
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), plus the interval between Hello Packets sent out the interface (HelloInterval). It also says how often a neighbor has to 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.0.0.0 💅
The Hello packet's Options field describes the router's optional OSPF capabilities. Right now there are two optional capabilities defined (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's not a stub area) 🔥 If the E-bit is set incorrectly, the neighboring routers will refuse to accept the Hello Packet (see Section 10.5) 😭 The rest of the Hello Packet's Options field should be set to zero.
To make sure two-way communication happens between adjacent routers, the Hello packet contains the list of all routers that have recently been seen sending Hello Packets 🫶 The Hello packet also carries the router's current choice for Designated Router and Backup Designated Router. A value of 0.0.0.0 in these fields means one hasn't been selected yet 🌈
On broadcast networks and physical point-to-point networks, Hello packets go out every HelloInterval seconds to the IP multicast address AllSPFRouters 📡 On virtual links, Hello packets are sent 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 that's what the next section covers 🧚
9.5.1. Sending Hello packets on non-broadcast networks
Static configuration information is required for the Hello Protocol to work on non-broadcast networks (see Section C.5) ✨ Every attached router that's eligible to become Designated Router has a configured list of all of 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 Hello Packets get sent 🦋 Hello Packets are then sent directly (as unicasts) to some subset of a router's neighbors. Sometimes a Hello Packet goes out periodically on a timer, and other times it's sent in response to a received Hello Packet 🌸 How a router behaves when sending Hello packets 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 Hello Packets to all neighbors that are also eligible. If the router is itself the Designated Router or Backup Designated Router, it must also send periodic Hello Packets to all its other neighbors 👑 That means any two eligible routers are always exchanging Hello Packets, which is needed for the Designated Router election algorithm to work correctly. To keep the number of Hello Packets down, the number of eligible routers on a non-broadcast network should be kept small 💅
If the router is not eligible to become Designated Router, it must periodically send Hello Packets to both the Designated Router and the Backup Designated Router (if they exist). It must also send a Hello Packet in reply to a Hello Packet received from any eligible neighbor (other than the current Designated Router and Backup Designated Router) 🙈 This is needed to set up an initial bidirectional relationship with any potential Designated Router.
When sending Hello packets periodically to any neighbor, the interval depends on that neighbor's state 🍓 If the neighbor is in state Down, Hello Packets go out every PollInterval seconds. Otherwise, they go out every HelloInterval seconds.
10. The Neighbor Data Structure 💜
An OSPF router chats with its neighboring routers 🫶 Each separate conversation is described by a "neighbor data structure". Each conversation is bound to one 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 with its own unique neighbor data structure. Each separate conversation is loosely called a separate "neighbor" in the text.
The neighbor data structure holds all the info that matters for forming or having formed an adjacency between the two neighbors. (Remember though, not every neighbor becomes adjacent 💀) An adjacency is basically a highly developed conversation between two routers 😭
State: The functional level of the neighbor conversation. This is described in more detail in Section 10.1 ✨
Inactivity Timer: A single shot timer whose firing indicates that no Hello Packet has been seen from this neighbor recently. The length of the timer is RouterDeadInterval seconds ⏰
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 rides along in the neighbor's Hello packets, and it's used when picking the Designated Router for the attached network. Main character energy 👑
Neighbor IP address 🌸: The IP address of the neighbor's interface to the attached network. It's the Destination IP address for protocol packets sent as unicasts along this adjacency. It also shows up in router links advertisements as the Link ID for the attached network, but only if that neighbor gets picked as Designated Router (see Section 12.4.1). You learn it from Hello packets. For virtual links, though, it's learned during the routing table build process instead (see Section 15). 🧚
Neighbor Options ✨: The optional OSPF capabilities the neighbor supports. You learn these during the Database Exchange process (see Section 10.6), but they're also listed in the neighbor's Hello packets. That's the iconic part 😭 If there's a mismatch in certain crucial OSPF capabilities, received Hello packets can get rejected, so neighbor relationships won't even start forming (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 the neighbor is the one being looked at, this matters for working out the Designated Router locally. It's only defined on multi-access networks. 🫶
Neighbor's Backup Designated Router 🌈: The neighbor's idea of the Backup Designated Router. Same deal as above: if the neighbor is itself, it matters for working out the Backup Designated Router locally, and it's only defined on multi-access networks. 💀
Master/Slave 💖: When two neighbors swap databases, they form a master/slave relationship, and it's giving hierarchy 👑 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 relationship gets negotiated in state ExStart. 🔥
DD Sequence Number 🦋: A 32-bit number that identifies individual Database Description packets. When the neighbor enters ExStart, the DD sequence number should be set to a value the neighboring router hasn't seen before. One option is to use the machine's time of day counter. ⭐ After that, the master increments the DD sequence number with every new Database Description packet it sends. The slave's DD sequence number tells you the last packet it received from the master. Only one packet is allowed to be outstanding at a time, bestie 🙈
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), and AS external links (stored in the global data structure). Okay, that's a lot, but it's lowkey organized 🌸
Link state retransmission list 🎀: The list of link state advertisements that have been flooded but not acknowledged on this adjacency. They keep getting 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 is 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 both neighbors' topological databases get synchronized. It's built as Database Description packets come in, and then it's sent to the neighbor in Link State Request packets. It gets depleted as the right Link State Update packets arrive. 🍓
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. So the inoperative state comes first, then a bunch of intermediate states, and finally the fully functional state. The spec uses this ordering by sometimes saying things like "those neighbors/adjacencies in state greater than X". Figures 12 and 13 show the graph of neighbor state changes. The arcs are labelled with the event that causes each state change, and 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 is responsible for neighbor acquisition and maintenance, and for making sure two-way communication happens between neighbors. 💖
+----+
|Down|
+----+
| | Start
| +-------+
Hello | +---->|Attempt|
Received | +-------+
| |
+----+<-+ |HelloReceived
|Init|<---------------+
+----+<--------+
| |
|2-Way |1-Way
|Received |Received
| |
+-------+ | +-----+
|ExStart|<--------+------->|2-Way|
+-------+ +-----+Figure 12: Neighbor state changes (Hello Protocol)
In addition to the state transitions pictured, these events also force a change:
KillNbralways forces Down State 💀InactivityTimeralways forces Down State 💀LLDownalways forces Down State 💀
The graph in Figure 13 shows how an adjacency forms. Not every two neighboring routers become adjacent (see Section 10.4). The adjacency starts to form when the neighbor is in state ExStart. Once the two routers have worked out their master/slave status, the state moves to Exchange. At that point the neighbor starts getting 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. Only then does the adjacency show up in link state advertisements. 🔥
+-------+
|ExStart|
+-------+
|
NegotiationDone|
+->+--------+
|Exchange|
+--+--------+
|
Exchange|
Done |
+----+ | +-------+
|Full|<---------+----->|Loading|
+----+<-+ +-------+
| LoadingDone |
+------------------+Figure 13: Neighbor state changes (Database Exchange)
In addition to the state transitions pictured, these events also force a change or start something:
SeqNumberMismatchforces ExStart state 🙈BadLSReqforces ExStart state 🙈1-Wayforces Init state 🙈KillNbralways forces Down State 💀InactivityTimeralways forces Down State 💀LLDownalways forces Down State 💀AdjOK?leads to adjacency forming/breaking ✨
For a more detailed look at neighbor state changes, plus the extra actions that happen with each change, check out Section 10.3. 🦋
Down 🌸
This is the initial state of a neighbor conversation. It means no recent information has come in from the neighbor. On non-broadcast networks, Hello packets may still get 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 come in from the neighbor, but a more concerted effort should be made to reach them. That 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. Bidirectional communication isn't established yet, though, because the router itself didn't show up in the neighbor's Hello packet. Every neighbor in this state (or higher) gets 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 that. It's 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 DD 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 DD sequence number and gets explicitly acknowledged. Only one Database Description Packet is allowed to be outstanding at any one time. In this state, Link State Request Packets may also be sent asking for the neighbor's more recent advertisements. All adjacencies in Exchange state or greater are used by the flooding procedure. These adjacencies are fully capable of transmitting and receiving all types of OSPF routing protocol packets, so they're literally doing it all 💅
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) in the Exchange state. 💜
Full 💖 okay this is the big one, bestie! Both routers are fully adjacent now ✨, and those adjacencies will show up in the router links and network links advertisements 🌸.
10.2. Events causing neighbor state changes ✨
Neighbor states don't just change randomly 💅. There's a whole list of events that make it happen, and you can spot them as the labels on the arcs in Figures 12 and 13. Here's what each one means:
HelloReceived 🫶 A Hello packet just came in from a neighbor. Easy.
Start 🚦 This is the green light: Hello Packets SHOULD now go out to the neighbor at intervals of HelloInterval seconds. Only neighbors on non-broadcast networks ever get this one 🙈.
2-WayReceived 🙌 Two-way communication is confirmed! This happens when this router spots itself in the other router's Hello packet 👀.
NegotiationDone 🎀 The Master/Slave roles are sorted and the DD sequence numbers have been exchanged. This kicks off the sending and receiving of Database Description packets. For how this one gets generated, check out Section 10.8.
ExchangeDone 📦 Both routers have sent a complete run of Database Description packets. Now each one knows which parts of its link state database are outdated. More on how this fires is in Section 10.8.
BadLSReq 😬 A Link State Request came in asking for an advertisement the database doesn't even have. That's a sign something went sideways in the Database Exchange process.
Loading Done 🎉 Link State Updates have landed for every outdated part of the database. You can tell because the Link state request list is finally empty once the Database Exchange wraps up.
AdjOK? 💅 A decision MUST be made (again) about whether an adjacency SHOULD be established or maintained with the neighbor. This one's the drama queen: it can start some adjacencies forming and destroy others.
These next ones knock well-developed neighbors back down to lesser states 😭. Unlike the ones above, these MAY happen no matter which state the neighbor conversation is currently in.
SeqNumberMismatch 💀 A Database Description packet shows up and either a) has a DD sequence number nobody expected, b) unexpectedly has the Init bit set, or c) has an Options field that's different from the last Options field received in a Database Description packet. Any of these means something went wrong during adjacency establishment.
1-Way 🙈 A Hello packet from the neighbor shows up and this router isn't mentioned in it. So the conversation isn't going both ways.
KillNbr 🚫 All communication with the neighbor is now impossible, so the neighbor gets forced back to Down state.
InactivityTimer ⏰ The inactivity Timer went off. Translation: no Hello packets from the neighbor lately, so it's back to Down.
LLDown 🚩 The lower level protocols are waving a flag: the neighbor is unreachable now. For example, on an X.25 network this could show up as an X.25 clear indication with appropriate cause and diagnostic fields. Either way, the neighbor gets shoved into Down state.
10.3. The Neighbor state machine 🦋
Here's the detailed rundown of how neighbor states change. Each state change is kicked off by an event (Section 10.2). That event MAY produce different effects depending on the neighbor's current state, which is why the state machine below is organized by current neighbor state and received event. Each entry tells you the resulting new neighbor state and the REQUIRED set of additional actions.
When a neighbor's state changes, it MAY be necessary to rerun the Designated Router election algorithm. Whether that happens depends on if the interface NeighborChange event is generated (see Section 9.2). Also, if the Interface is in DR state (meaning the router is itself the Designated Router), neighbor state changes 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). That keeps things simple, since it makes sure neither state machine gets executed recursively 🧚.
- State(s): Down
- Event:
Start - New state: Attempt
- Action: Fire off a Hello Packet to the neighbor (this one's always on a non-broadcast network 🌈) and start the Inactivity Timer for it. If that timer goes off later, it means communication never got going.
- State(s): Attempt
- Event:
HelloReceived - New state: Init
- Action: Restart the Inactivity Timer, since we've finally heard from the neighbor 👂.
- State(s): Down
- Event:
HelloReceived - New state: Init
- Action: Start the Inactivity Timer. If it ever fires later, the neighbor is considered dead 💀.
- State(s): Init or greater
- Event:
HelloReceived - New state: No state change.
- Action: Restart the Inactivity Timer again, since the neighbor has been heard from once more.
- State(s): Init
- Event:
2-WayReceived - New state: Depends upon action routine.
- Action: Work 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. As soon as it gets there, the router increments the DD sequence number for this neighbor. If this is the very first time an adjacency has been attempted, that DD sequence number SHOULD be assigned some unique value (like the time of day clock 🕰️). Then it 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. That packet SHOULD otherwise be empty. It SHOULD be retransmitted at intervals of RxmtInterval until the next state gets entered (see Section 10.8).
- State(s): ExStart
- Event:
NegotiationDone - 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 is made up of 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 Database Description Packet has a DD sequence number and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. For more on sending and receiving Database Description packets, see Sections 10.8 and 10.6.
- State(s): Exchange
- Event:
ExchangeDone - New state: Depends upon action routine.
- Action: If the neighbor Link state request list is empty, the new neighbor state is Full. No other action is REQUIRED. This is an adjacency's final state.
Otherwise, the new neighbor state is Loading. Start (or keep going with) sending Link State Request packets to the neighbor (see Section 10.9). These ask for the neighbor's more recent advertisements, which 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 an adjacency's final state.
- State(s): 2-Way
- Event:
AdjOK? - New state: Depends upon action routine.
- Action: Work 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, move the neighbor state to ExStart and carry out the actions tied to the Init state entry above for the
2-WayReceivedevent. - State(s): ExStart or greater
- Event:
AdjOK? - New state: Depends upon action routine.
- Action: Figure out 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 all get cleared of link state advertisements.
- State(s): Exchange or greater
- Event:
SeqNumberMismatch - New state: ExStart
You're doing amazing, bestie! 🌈👑
Okay so the (possibly partially formed) adjacency gets torn down, and then the router tries to reestablish it 🔄. The neighbor state first flips to ExStart. The Link state retransmission list, Database summary list and Link state request list all get cleared of link state advertisements 🧹. Then the router increments the DD 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 ✨. This Database Description Packet should be otherwise empty (see Section 10.8). 🎀
State(s): Exchange or greater
Event: BadLSReq
New state: ExStart
Action: Bestie, BadLSReq is exactly the same as the neighbor event SeqNumberMismatch 🫶. The (possibly partially formed) adjacency is torn down, and then an attempt is made at reestablishment. For more information, see the neighbor state machine entry that is invoked when event 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 are 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 are cleared of link state advertisements. Also, the Inactivity Timer is disabled. 💀
State(s): Any state
Event: InactivityTimer
New state: Down
Action: The Link state retransmission list, Database summary list and Link state request list are cleared of link state advertisements. 🥀
State(s): 2-Way or greater
Event: 1-WayReceived
New state: Init
Action: The Link state retransmission list, Database summary list and Link state request list are cleared of link state advertisements. 🧼
State(s): 2-Way or greater
Event: 2-WayReceived
New state: No state change.
Action: No action required. ✅
State(s): Init
Event: 1-WayReceived
New state: No state change.
Action: No action required. 🌸
10.4. Whether to become adjacent 🦋
Okay, so adjacencies get set up with some subset of the router's neighbors, not all of them 💅. 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. First, when bidirectional communication is initially established with the neighbor, and secondly, when the identity of the attached network's (Backup) Designated Router changes. If the decision is made 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 checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, HelloInterval, and RouterDeadInterval 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, the above fields are really describing the attached network's configuration. However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored. 🧐
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 Options field must match this area's ExternalRoutingCapability. 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 Hello Packets, otherwise the E-bit must be set. A mismatch causes processing to stop and the packet to be dropped. The setting of the rest of the bits in the Hello Packet's Options field should be ignored. 🌿
At this point, an attempt is made to match the source of the Hello Packet 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 found 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 found in the Hello's OSPF packet header. The interface's current list of neighbors is contained in the interface's data structure. If a matching neighbor structure cannot be found, (i.e., this is the first time the neighbor has been detected), one is created. The initial state of a newly created neighbor is set to Down. 🔍
When receiving an Hello Packet from a neighbor on a multi-access network (broadcast or non-broadcast), set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. 🪪
Now the rest of the Hello Packet is examined, generating events to be given to the neighbor and interface state machines. These state machines are specified either to be 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 may be effected by a single received Hello: 🤯
- Each Hello Packet causes the neighbor state machine to be executed with the event
HelloReceived. 📨 - 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-WayReceived. Otherwise, the neighbor state machine should be executed with the event1-WayReceived, 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 updated 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 eventBackupSeen. 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 eventNeighborChange. In any case, the Neighbors' Designated Router item in the neighbor structure is updated 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 eventNeighborChange. In any case, the Neighbor's Backup Designated Router item in the neighbor structure is updated accordingly. 🥈
On non-broadcast multi-access networks, receipt of an Hello Packet may also cause an Hello Packet to be sent back to the neighbor in response. See Section 9.5.1 for more details. 📬
10.6. Receiving Database Description Packets 🧁
This section explains the detailed processing of a received Database Description Packet. The incoming Database Description Packet has already been associated with a neighbor and receiving interface by the generic input packet processing (Section 8.2). The further processing of the Database Description Packet depends on the neighbor state. If the neighbor's state is Down or Attempt the packet should be ignored. Otherwise, if the state is: 💌
Init
The neighbor state machine should be executed with the event 2-WayReceived. This causes an immediate state change to either state 2-Way or state ExStart. If the new state is ExStart, the processing of the current packet should then continue in this new state by falling through to case ExStart below. ⚡
2-Way
The packet should be ignored. Database Description Packets are used only for the purpose of bringing up adjacencies.[7] 🙃
ExStart 🌸
Okay so, if the incoming packet matches one of these cases, the neighbor state machine should run the event NegotiationDone (which moves the state over to Exchange). The packet's Options field gets saved into the neighbor structure's Neighbor Options field, and the packet gets accepted as next in sequence and processed further (see below). If it doesn't match, the packet should be ignored. 🙈
- The I (initialize), M (more), and MS (master) bits are all set, the packet contents are empty, and the neighbor's Router ID is bigger than the router's own. 🧚 In this case the router is now Slave. Set the master/slave bit to slave, and set the DD sequence number to whatever the master specified.
- The I and MS bits are off, the packet's DD sequence number equals the router's own DD sequence number (that's the acknowledgment 💅), and the neighbor's Router ID is smaller than the router's own. In this case the router is Master. 👑
Exchange 🦋
If the MS-bit doesn't match the master/slave state of the connection, generate the neighbor event SeqNumberMismatch and stop processing the packet. Otherwise:
- If the I (initialize) bit is set, generate the neighbor event SeqNumberMismatch and stop processing the packet. 💀
- If the packet's Options field shows a different set of optional OSPF capabilities than what was previously received from the neighbor (recorded in the Neighbor Options field of the neighbor structure), generate the neighbor event SeqNumberMismatch and stop processing the packet.
- If the router is master, and the packet's DD sequence number equals the router's own DD 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 DD sequence number is one less than the router's DD sequence number, the packet is a duplicate. Duplicates should be discarded by the master.
- If the router is slave, and the packet's DD sequence number is one more than the router's own DD 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 DD sequence number equals the router's DD sequence number, the packet is a duplicate. The slave must respond to duplicates by repeating the last Database Description packet that it had sent. 🫶
- Else, generate the neighbor event SeqNumberMismatch and stop processing the packet.
Loading or Full 🌈
In this state, the router has sent and received an entire sequence of Database Description Packets. The only packets that should show up are duplicates (see above). Specifically, the packet's Options field should match the set of optional OSPF capabilities the neighbor previously indicated (stored in the neighbor structure's Neighbor Options field). Any other packets, including one with the Initialize (I) bit set, should generate the neighbor event SeqNumberMismatch.[8] Duplicates should be discarded by the master. The slave must respond to duplicates by repeating the last Database Description packet that it had sent. 😭
When the router accepts a received Database Description Packet as the next in sequence, the packet contents get processed like this. For each link state advertisement listed, the advertisement's LS type gets checked for validity. If the LS type is unknown (for example, 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 SeqNumberMismatch and stop processing the packet. Otherwise, the router looks the advertisement up in its database to see whether it also has an instance of that link state advertisement. If it doesn't, or if the database copy is less recent (see Section 13.1), the link state advertisement goes on the Link state request list so it can be requested (immediately or later) in Link State Request Packets. 🎀
When the router accepts a received Database Description Packet as the next in sequence, it also does the following, depending on whether it's master or slave:
Master 👑
Increments the DD sequence number. If the router has already sent its entire sequence of Database Description Packets, and the just accepted packet has the more bit (M) set to 0, the neighbor event ExchangeDone is generated. Otherwise, it should send a new Database Description to the slave.
Slave 🧚
Sets the DD sequence number to the DD sequence number that appears in the received packet. The slave must send a Database Description Packet in reply. If the received packet has the more bit (M) set to 0, and the packet the slave is about to send will also have the M-bit set to 0, the neighbor event ExchangeDone 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 can't be found in the database, something has gone wrong with the Database Exchange process, and neighbor event BadLSReq should be generated. 🙈
10.8. Sending Database Description Packets 💜
This section describes how Database Description Packets get 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 keep 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. 🎀
Whether a Database Description packet gets sent depends on the neighbor's state. In state ExStart, the router sends empty Database Description packets with the initialize (I), more (M), and master (MS) bits set. These packets are retransmitted every RxmtInterval seconds. 🔁
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 moment 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 DD 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 when the previous packet is acknowledged. ✨
In state Exchange, the decision about when to send a Database Description packet depends on whether the router is master or slave:
Master 👑
Database Description packets are sent when either a) the slave acknowledges the previous Database Description packet by echoing the DD sequence number, or b) RxmtInterval seconds elapse without an acknowledgment, in which case the previous Database Description packet is retransmitted.
Slave 🧚
Database Description packets are sent only in response to Database Description packets received from the master. If the Database Description packet received from the master is new, a new Database Description packet is sent. Otherwise, the previous Database Description packet is resent.
In states Loading and Full, the slave must resend its last Database Description packet in response to duplicate Database Description packets received from the master. For this reason, the slave must wait RouterDeadInterval seconds before freeing the last Database Description packet. Reception of a Database Description packet from the master after this interval will generate a SeqNumberMismatch neighbor event. 😭
10.9. Sending Link State Request Packets 🌷
In neighbor states Exchange or Loading, the Link state request list contains the 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 gets truncated and a new Link State Request packet is sent. This keeps going until the Link state request list is empty. Unsatisfied Link State Request packets 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 sent to and 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. 👀
okay so the neighbor state changes each router goes through are written on the sides of the figure 🦋
At the very start of Figure 14, Router RT1's interface to the network becomes operational 🌸 It starts blasting out Hello Packets, even though it has no clue who the Designated Router is or who any of its other neighbors are 💀 RT2 hears that hello (so RT2 moves the neighbor to Init state 👀). In its next Hello Packet, RT2 says it IS the Designated Router and that it has heard Hello Packets from RT1 💅 That's what makes RT1 go to state ExStart, because now it's starting to bring up the adjacency ✨
RT1 starts off by declaring itself the master 👑 Then it notices RT2 is actually the master (since RT2 has the higher Router ID), so RT1 switches to slave and adopts its neighbor's DD sequence number 🫶 Database Description packets get swapped next, with the master (RT2) doing the polls and the slave (RT1) replying. This back-and-forth only wraps up when both the poll and its response have the M-bit off 🎀
In this example, RT2 already has a totally up-to-date database, so RT2 goes straight to Full state 🔥 RT1 gets to Full too, but only after it fixes up the parts of its database that need it 💖 It does that by sending Link State Request Packets and then getting Link State Update Packets back 🦋 Quick bonus: RT1 waited until it had the full set of Database Description Packets from RT2 before sending any Link State Request Packets, but that doesn't have to be how it goes. RT1 could have mixed sending Link State Request Packets in with receiving Database Description Packets 💜
+---+ +---+
|RT1| |RT2|
+---+ +---+
Down Down
Hello(DR=0,seen=0)
------------------------------>
Hello (DR=RT2,seen=RT1,...) Init
<------------------------------
ExStart D-D (Seq=x,I,M,Master)
------------------------------>
D-D (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange D-D (Seq=y,M,Slave)
------------------------------>
D-D (Seq=y+1,M,Master) Exchange
<------------------------------
D-D (Seq=y+1,M,Slave)
------------------------------>
...
...
...
D-D (Seq=y+n, Master)
<------------------------------
D-D (Seq=y+n, Slave)
Loading ------------------------------>
LS Request Full
------------------------------>
LS Update
<------------------------------
LS Request
------------------------------>
LS Update
<------------------------------
Full
Figure 14: An adjacency bring-up example11. The Routing Table Structure ✨
okay so the routing table is where the router keeps everything it needs to forward an IP data packet toward its destination 🗺 Each routing table entry describes the whole collection of best paths to one particular destination 💅 When a packet needs forwarding, the router finds the entry that best matches the packet's IP destination 👀 That matching entry then gives the next hop towards the destination 🦋 OSPF also supports a default route (Destination ID = DefaultDestination, Address Mask = 0x00000000) 🌈 When that default route exists, it matches every IP destination, though any other matching entry is an even better match 💜 Figuring out which entry best matches an IP destination is covered in Section 11.1 🧚
There's exactly one routing table in each router 👑 Two sample routing tables show up in Sections 11.2 and 11.3 🍓 The routing table gets built in Section 16 ✨
The rest of this section defines the fields in a routing table entry 🎀 The first set of fields is all about the entry's destination 💖
Destination Type
The destination can be one of three types 🧚 Only the first type, Network, actually gets used when forwarding IP data traffic 😭 The other two are just intermediate steps in the routing table build process 💅
- Network: A range of IP addresses that IP data traffic may be forwarded to 🦋 That covers IP networks (class A, B, or C), IP subnets, IP supernets and single IP hosts 🌸 The default route also counts as one of these 🫶
- Area border router: Routers that are connected to multiple OSPF areas 👑 These routers originate summary link advertisements 📣 These routing table entries get used when calculating the inter-area routes (see Section 16.2) ✨ They may also be associated with configured virtual links 🌈
- AS boundary router: Routers that originate AS external link advertisements 💜 These entries get used when calculating the AS external routes (see Section 16.4) 💅
Destination ID
The destination's identifier or name 🦋 What it looks like depends on the Destination Type 🌸 For networks it's their associated IP address, and for all the other types it's 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 gets called 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 shows which optional OSPF capabilities that router supports 🧠 The two optional capabilities this specification currently defines are the ability to route based on IP TOS and the ability to process AS external link advertisements ✨ For more on OSPF's optional capabilities, see Section 4.5 🔥
The set of paths to use for a destination can change based on IP Type of Service and on which OSPF area the paths belong to 💅 So one destination can have several routing table entries, 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 🫶 How TOS gets encoded in OSPF link state advertisements is described in Section 12.3 🦋
Area
This field says which area's link state information led to the entry's collection of paths 🗺 That's called the entry's associated area 🌸 For sets of AS external paths, this field isn't defined 😭 For "area border router" destinations there can be separate sets of paths (and so separate entries) for each of several areas. That happens 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 entry describes the set of paths to the destination 💖 The following fields apply to the set of paths as a whole. Put another way, each path inside a routing table entry has the same path-type and cost (see below) 💜
Path-type
There are four possible types of paths for routing 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. They're discovered by examining received summary link advertisements 🦋 AS external paths are paths to destinations external to the AS, and they're detected by examining 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 only 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 🫶 That cost was advertised by an AS boundary router, and it's the most significant part of the total path cost 👑 For example, a type 2 external 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 🎀 The Link State Origin field is not used by the OSPF protocol, but it is used by the routing table calculation in OSPF's Multicast routing extensions (MOSPF) 🌈
When multiple paths of equal path-type and cost exist to a destination (called "equal-cost" paths elsewhere), they're stored in a single routing table entry 👯 Each one of the "equal-cost" paths is distinguished by the following fields 💅
Next hop
The 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 any) in the path towards the destination 🌐 That next router will always be one of the adjacent neighbors 🫶
Advertising router
Valid only for inter-area and AS external paths 📣 This field indicates the Router ID of the router advertising the summary link or AS external link that led to this path 👑
11.1. Routing table lookup 🔍
When an IP data packet lands on an OSPF router 📦, the router has to hunt down the routing table entry that best matches the packet's destination 🔍. That entry hands over the outgoing interface and the next hop router to forward the packet through ✨. This section walks through the search. It's a bunch of steps where the list of routing table entries gets progressively pruned 💅, and whatever single entry is left standing is called the best match 👑.
Heads up 🙈: the steps can fail to produce a best match. That happens when every routing table entry gets pruned for one reason or another. When it does, the packet's IP destination counts as unreachable 💀. So instead of being forwarded, the packet gets dropped, and an ICMP destination unreachable message should be sent back to the packet's source.
(1) Start by selecting the complete set of "matching" routing table entries 🎯. 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 multiple 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 this particular area address range is active 🦋. "Active" here means there are one or more reachable (by intra-area paths) networks contained in the area address range. The packet's IP destination is then required to belong to one of those constituent networks. So only matching routing table entries with path-type of intra-area are considered, and everything else gets 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 provides the longest (most specific) match 🔎. Another way of saying this is to choose the remaining entry that specifies the narrowest range of IP addresses. Say you've got the address/mask pair (128.185.1.0, 0xffffff00) and the pair (128.185.0.0, 0xffff0000). The first one is more specific 💖 [10]. The default route is the least specific match, since it matches all destinations 🥹.
(5) At this point, there may still be multiple routing table entries left 🫠. Each one specifies the same range of IP addresses, but a different IP Type of Service. Select the entry whose TOS value matches the TOS found in the packet header 🎀. If there's no routing table entry for that TOS, select the routing table entry for TOS 0. In other words, 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 from 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 of Router RT6's routing table follows Section 2.1, and the result is shown in Table 12. Destination types are abbreviated: Network as "N", area border router as "BR", and AS boundary router as "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 Routers RT5 and RT7, which lets external routes be calculated to the destinations they advertise (Networks N12, N13, N14 and N15). It's assumed that all AS external advertisements originated by RT5 and RT7 are advertising type 1 external metrics. So type 1 external paths get calculated to destinations N12-N15 💅.
11.3. Sample routing table, with areas 🗺️
Now take the previous example and split it into OSPF areas 🧩. An OSPF area configuration is pictured in Figure 6. We'll describe Router RT4's routing table for this area configuration. Router RT4 has a connection to Area 1 and a backbone connection, which makes RT4 view the AS as the concatenation of the two graphs shown in Figures 7 and 8. The resulting routing table is displayed 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 table entries (in this case with identical paths) for Router RT7, since it's both an area border router and an AS boundary router. Also note there are two routing entries for the 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 are used when determining the inter-area routes. All of the inter-area routes are associated with the backbone, and that's always the case when the calculating 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 to a single route when advertised into the backbone (by Router RT11). Note that the cost of this route is
Type Dest Area Path Type Cost Next Adv.
Hop(s) 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 ext. 10 RT10 RT7
N N13 * type 1 ext. 14 RT5 RT5
N N14 * type 1 ext. 14 RT5 RT5
N N15 * type 1 ext. 17 RT10 RT7
Table 12: The routing table for Router RT6
(no configured areas)....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. They both use the same next hop, though (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 💜.
Type Dest Area Path Type Cost Next Adv.
Hops(s) 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 ext. 16 RT5 RT5,RT7
N N13 * type 1 ext. 16 RT5 RT5
N N14 * type 1 ext. 16 RT5 RT5
N N15 * type 1 ext. 23 RT5 RT7
Table 13: Router RT4's routing table
in the presence of areas.12. Link State Advertisements ✨
Okay so every router in the Autonomous System originates one or more link state advertisements 🌸. There are five distinct types, all explained in Section 4.3 ✨. Together they make up the link state or topological database 🗺️. Each type has its own special job, and this table of changes from an additional virtual link shows that off 👀:
Table 14: Changes resulting from an
additional virtual link.Wait, I need to put the table in the proper spot. Here's the full table exactly as it appears:
Type Dest Area Path Type Cost Next Adv.
Hop(s) 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 RT11
Table 14: Changes resulting from an
additional virtual link.Now for the jobs, bestie 💅: router links and network links advertisements describe how an area's routers and networks are interconnected 🔗. Summary link advertisements give us a way to condense an area's routing information 📦. AS external advertisements transparently share externally-derived routing information across the whole Autonomous System 🌍.
Each link state advertisement begins with a standard 20-byte header 🎀. We'll go through it right now.
12.1. The Link State Advertisement Header 🎀
The header holds the LS type, Link State ID and Advertising Router fields 💖. Put those three together and you uniquely identify the advertisement ✨.
There can be several instances of one advertisement floating around the Autonomous System at the same time 🙈. When that happens, it MUST then be figured out which instance is more recent. That call is made by looking at the LS sequence, LS checksum and LS age fields, which also live in that same 20-byte header 🔍.
Several OSPF packet types list link state advertisements 📋. When the instance doesn't matter, you refer to an advertisement by its LS type, Link State ID and Advertising Router (see Link State Request Packets). Otherwise the LS sequence number, LS age and LS checksum fields MUST also be referenced 💅.
Here's the detailed breakdown of each header field 👇
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 is originated. 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 is never incremented past MaxAge 🛑. Advertisements at MaxAge aren't used in the routing table calculation. When an advertisement's age first reaches MaxAge, it gets reflooded 📣. An advertisement at MaxAge is finally flushed from the database once it's no longer needed to keep the database synchronized 🧹. For more on aging, see Section 14.
The LS age field gets checked when a router receives two instances with identical LS sequence numbers and LS checksums 🔎. An instance at MaxAge is always accepted as most recent, which lets old advertisements get flushed quickly from the routing domain 👋. Otherwise, if the ages differ by more than MaxAgeDiff, the instance with the smaller age is accepted as most recent.[11] See Section 13.1 for more details.
12.1.2. Options 🎛️
The Options field tells you which optional capabilities go with the advertisement. OSPF's optional capabilities are described in Section 4.5 💫. There are currently two defined: the T-bit and E-bit, both found in the Options field. The rest of the Options field SHOULD be set to zero 0️⃣.
The E-bit represents OSPF's ExternalRoutingCapability 🌐. It SHOULD be set in all advertisements tied to the backbone, and in all advertisements for non-stub areas (see Section 3.6). It SHOULD also be set in all AS external link advertisements. It SHOULD be reset in router links, network links and summary link advertisements that belong to a stub area. For all link state advertisements, the E-bit is just for informational purposes; it doesn't affect the routing table calculation 🤷♀️.
The T-bit represents OSPF's TOS routing capability 🧭. It SHOULD be set in a router links advertisement 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. It SHOULD be set in summary link and AS external link advertisements if and only if the advertisement describes paths for all TOS values, not just the TOS 0 path. Note that even with the T-bit set, there can still be only a single metric in the advertisement (the TOS 0 metric). That would mean paths for non-zero TOS exist but are equivalent to the TOS 0 path 🤓. A link state advertisement's T-bit gets examined when calculating the routing table's non-zero TOS paths (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 📛. All types except AS external link advertisements (LS type = 5) are flooded throughout a single area only 🏠. AS external link advertisements get flooded throughout the entire Autonomous System, except for stub areas (see Section 3.6) 🌍. Each type is briefly described below in Table 15 👇.
12.1.4. Link State ID 🆔
This field identifies the piece of the routing domain that the advertisement is describing 🔭. Depending on the advertisement's LS type, the Link State ID takes on the values listed in Table 16 🎯.
Actually, for Type 3 summary link (LS type = 3) advertisements and AS external link (LS type = 5) advertisements, the Link State ID can also have one or more of the destination network's "host" bits set 🫢. For example, when originating an AS external link for the network 10.0.0.0 with mask of 255.0.0.0, the Link State ID
LS Type Advertisement description
__________________________________________________
1 These are the router links
advertisements. They describe the
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. 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....can be set to anything in the range 10.0.0.0 through 10.255.255.255 inclusive (although 10.0.0.0 SHOULD be used whenever possible) 🌈. The freedom to set certain host bits lets a router originate separate advertisements for two networks that share an address but have different masks 🪞. See Appendix F for details ✨.
When the advertisement is describing a network (LS type = 2, 3 or 5), the network's IP address is easily derived by masking the Link State ID with the network/subnet mask in the body of the advertisement 🧮. When it's describing a router (LS type = 1 or 4), the Link State ID is always the described router's OSPF Router ID 🆔.
When an AS external advertisement (LS Type = 5) is describing a default route, its Link State ID is set to DefaultDestination (0.0.0.0) 🚪.
12.1.5. Advertising Router 📣
This field specifies the OSPF Router ID of the advertisement's originator 🖊️. For router links advertisements, this field is identical to the Link State ID field 👯. Network link advertisements are originated by the network's Designated Router 👑. Summary link advertisements are originated by area border routers 🏰. AS external link advertisements are originated by AS boundary routers 🚀.
12.1.6. LS sequence number 🔢
The sequence number field is a signed 32-bit integer 🧮. It's used to detect old and duplicate link state advertisements 🕵️♀️💖.
The sequence number space is linearly ordered, which means the bigger the sequence number (compared as signed 32-bit integers), the newer the advertisement 🦋✨. To describe the space more precisely, let N in the discussion below stand for the constant 2**31 💅.
The sequence number -N (0x80000000) is reserved and unused 🙈. That leaves -N + 1 (0x80000001) as the smallest, and therefore oldest, sequence number 🌸. A router uses this one the first time it originates any link state advertisement. After that, the sequence number goes up by one each time the router originates a new instance of that advertisement 💜. When someone tries to increment past the maximum value of N - 1 (0x7fffffff), the current instance has to be flushed from the routing domain first 😭. That happens 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 the sequence number -N + 1 (0x80000001) 🎀.
The router might be forced to promote the sequence number of one of its advertisements when a more recent instance of it shows up unexpectedly during flooding 👀. This should be a rare event, and it may mean that an out-of-date advertisement, originated by the router itself before its last restart or reload, is still floating around the Autonomous System 💀. For more information, see Section 13.4 🧚.
12.1.7. LS checksum ✨
This field is the checksum of the complete contents of the advertisement, except the LS age field 🌈. The LS age field is skipped so that an advertisement's age can go up without the checksum having to be recalculated 🫶. The checksum used is the same one used for ISO connectionless datagrams, commonly called the Fletcher checksum 🍓. It's documented in Annex B of [RFC 905]. The link state advertisement header also contains the advertisement's length in bytes, and subtracting the size of the LS age field (two bytes) gives you the amount of data to checksum 🧮.
The checksum is there to detect data corruption in an advertisement 🔍. Corruption can happen while the advertisement is being flooded, or while it's sitting in a router's memory 💅. The LS checksum field cannot be zero, and seeing that value should be considered a checksum failure 🙅♀️. In other words, calculating the checksum is not optional 🔥.
The checksum of a link state advertisement gets verified in two cases: 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 triggers different actions in each case, so check out Sections 13 and 14 for the full details 📚.
Whenever the LS sequence number field says two instances of an advertisement are the same, the LS checksum field gets checked 👯. If the checksums differ, the instance with the larger LS checksum is considered the most recent one 👑[12]. See Section 13.1 for more details 🌸.
12.2. The link state database 🗂️
A router has a separate link state database for every area it belongs to 💖. Elsewhere in the text, this link state database has been called the topological database 🧠. All routers in the same area have identical topological databases for that area ✨.
The databases for each area are always handled separately 🙌. The shortest path calculation runs separately for each area (see Section 16) 🛣️. Components of an area's topological database are flooded throughout that area only 🚫🌍. Finally, when an adjacency belonging to Area A is being brought up, only the Area A database gets synchronized between the two routers 🤝.
The area database is made up of router links advertisements, network links advertisements, and summary link advertisements (all listed in the area data structure) 📋. On top of that, external routes (AS external advertisements) are included in all non-stub area databases (see Section 3.6) 🌍.
An implementation of OSPF must be able to access individual pieces of an area database 🔑. This lookup is based on an advertisement's LS type, Link State ID and Advertising Router[13] 🪪. There will be a single instance (the most up-to-date one) of each link state advertisement in the database 💯. The lookup function gets invoked during the link state flooding procedure (Section 13) and the routing table calculation (Section 16) 🔄. Using this same lookup, a router can also figure out whether it has ever originated a particular link state advertisement and, if so, which 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 from the database when either a) it's been overwritten by a newer instance 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 an advertisement is deleted from the database, it must also be removed from all neighbors' Link state retransmission lists (see Section 10) 🧹.
12.3. Representation of TOS 🎨
All OSPF link state advertisements (except network links advertisements) specify metrics 📏. In router links advertisements, the metrics show the costs of the described interfaces 🔌. In summary link and AS external link advertisements, the metric shows the cost of the described path 🛤️. In all of these advertisements, a separate metric can be specified for each IP TOS 💝. The encoding of TOS in OSPF link state advertisements is specified in Table 17 📊. That table connects the OSPF encoding to the IP packet header's TOS field (defined in [RFC 1349]) 🎀. The OSPF encoding is written as a decimal integer, while the IP packet header's TOS field is written in the binary TOS values used in [RFC 1349] 🔢.
OSPF encoding RFC 1349 TOS values
___________________________________________
0 0000 normal service
2 0001 minimize monetary cost
4 0010 maximize reliability
6 0011
8 0100 maximize throughput
10 0101
12 0110
14 0111
16 1000 minimize delay
18 1001
20 1010
22 1011
24 1100
26 1101
28 1110
30 1111
Table 17: Representing TOS in OSPF.Every OSPF link state advertisement must specify the TOS 0 metric 💅. Other TOS metrics, if they appear, must show up in order of increasing TOS encoding 📈. For example, the TOS 8 (maximize throughput) metric must always come before the TOS 16 (minimize 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) 🌟.
12.4. Originating link state advertisements 🚀
Into any given OSPF area, a router will originate several link state advertisements 💌. Each router originates a router links advertisement 🙋♀️. If the router is also the Designated Router for any of the area's networks, it will originate network links advertisements for those networks 👑.
Area border routers originate a single summary link advertisement for each known inter-area destination 🌉. AS boundary routers originate a single AS external link advertisement for each known AS external destination 🌍. Destinations are advertised one at a time, so a change in 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 📦.
Take 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 advertisement, plus one summary link for each of the networks N1-N4) 🌷. It also originates 8 distinct link state advertisements into Area 1 (one router links advertisement and seven summary link advertisements, as pictured in Figure 7) 🎀. If RT4 has been selected as Designated Router for Network N3, it will also originate a network links advertisement for N3 into Area 1 👸.
In that same figure, Router RT5 originates 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 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) 🧸. That 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 ten events that can cause a new instance of a link state advertisement to be originated are: ✨
(1) okay bestie, so if the LS age field on one of the router's self-originated advertisements hits LSRefreshTime ⏰, the router makes a brand new instance of that link state advertisement, even if everything in it (apart from the link state advertisement header) is exactly the same 🔁. That's what guarantees every link state advertisement gets originated on a regular schedule, and the periodic refreshing is what makes the link state algorithm so robust 💪✨. Link state advertisements that solely describe unreachable destinations SHOULD NOT be refreshed. They SHOULD instead be flushed from the routing domain (see Section 14.1) 🗑️.
When whatever a link state advertisement describes changes, a new one gets originated 🔄. BUT two instances of the same link state advertisement may not be originated within MinLSInterval ⏳, so the next instance can get delayed by up to MinLSInterval. These events can change the contents of a link state advertisement, and they SHOULD cause new originations if and only if the contents of the new advertisement would be different 🧐:
(2) An interface's state changes (see Section 9.1) 🔌. This may mean that a new instance of the router links advertisement is needed.
(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. If the router itself is no longer the Designated Router, any network links advertisement it might have originated for the network SHOULD be flushed from the routing domain (see Section 14.1) 🧹.
(4) One of the neighboring routers changes to/from the FULL state 🤝. This may mean that a new instance of the router links advertisement is needed. Also, if the router is itself the Designated Router for the attached network, a new network links advertisement SHOULD be produced.
The next four events concern area border routers only 🌉:
(5) An intra-area route has been added/deleted/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 (possibly including the backbone).
(6) An inter-area route has been added/deleted/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 the router's routing table. See Section 12.4.3 for more details 📚.
(8) When the state of one of the router's configured virtual links changes 🔀, it may be necessary to originate a new router links advertisement into the virtual link's transit area (see the discussion of the router links advertisement's bit V in Section 12.4.1), as well as originating a new router links advertisement into the backbone.
The last two events concern AS boundary routers (and former AS boundary routers) only 🚪:
(9) An external route gained through direct experience with an external routing protocol (like EGP) changes 🌍. This will cause an AS boundary router to originate a new instance of an AS external link advertisement.
(10) A router ceases to be an AS boundary router, perhaps after restarting 🔄. In this situation the router SHOULD flush all AS external link advertisements that it had previously originated. These advertisements can be flushed via the premature aging procedure specified in Section 14.1 🌅.
The construction of each type of link state advertisement is explained in detail below 🔍. In general, these sections describe the contents of the advertisement body (i.e., the part coming after the 20-byte advertisement header). For information about 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 🏠. This advertisement describes the collected states of the router's links to the area 🔗. It gets flooded throughout the particular area, and no further 🌊.
....................................
. 192.1.2 Area 1 .
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ .
. | _______N3 .
. + / . 1+---+
. * 192.1.1 *------|RT4|
. + /_______/ . +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+8 . 6+---+
. | |RT3|----------------|RT6|
. + +---+ . +---+
. 192.1.3 |2 . 18.10.0.6|7
. | . |
. +------------+ .
. 192.1.4 (N4) .
....................................Figure 15: Area 1 with IP addresses shown 🖼️
The format of a router links advertisement is in Appendix A (Section A.4.2) 💅. The first 20 bytes are the generic link state advertisement header we talked about in Section 12.1. Router links advertisements have LS type = 1 🔢. The router says 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 flags whether it's an area border router or an AS boundary router, by setting the right bits (bit B and bit E, respectively) in its router links advertisements 🚩. This lets paths to those router types get saved in the routing table, for later processing of summary link advertisements and AS external link advertisements 🧠. Bit B SHOULD be set whenever the router is actively attached to two or more areas, even if the router is not currently attached to the OSPF backbone area. Bit E SHOULD never be set in a router links advertisement for a stub area, because stub areas cannot contain AS boundary routers 🙅♀️. The router also sets bit V in its router links advertisement for Area A if and only if it is the endpoint of an active virtual link using Area A as its Transit area 🌉. That way the other routers attached to Area A can figure out whether the area supports any virtual links (i.e., is a transit area) 🕵️♀️.
The router links advertisement then describes the router's working connections (i.e., interfaces or links) to the area 🔌. Each link is typed according to the kind of attached network 🏷️, and labelled with its Link ID. The Link 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 Neighbor Router ID
link
2 Link to transit Interface address of
network Designated Router
3 Link to stub IP network number
network
4 Virtual link Neighbor Router ID
Table 18: Link descriptions in the
router links advertisement.On top of that, the Link Data field is specified for each link 🎁. It gives 32 bits of extra information for the link. For links to transit networks, numbered links to routers and virtual links, this field specifies the IP interface address of the associated router interface (this is needed by the routing table calculation, see Section 16.1.1) 🧮. For links to stub networks, this field specifies the network's IP address mask 🎭. For unnumbered point-to-point networks, the Link Data field SHOULD be set to the unnumbered interface's MIB-II [RFC 1213] ifIndex value 🔢.
Finally, the cost of using the link for output (possibly specifying a different cost for each Type of Service) is specified 💸. The output cost of a link is configurable, and it MUST always be non-zero ⚠️.
To break down how the list of link descriptions gets built, say a router wants to build a router links advertisement for Area A 🧩. The router looks through its collection of interface data structures, and for each interface these steps happen 👀:
- If the attached network does not belong to Area A, no links are 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. For virtual links and numbered point-to-point networks, the Link Data SHOULD specify the IP interface address. For unnumbered point-to-point networks, the Link Data field SHOULD specify the interface's MIB-II [RFC 1213] ifIndex value 💖.
- 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 0xffffffff indicating 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 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 router's own IP interface 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. Note that in the case of serial lines, multiple links may be generated by a single interface. ✨
After consideration of all the router interfaces, host links are added to the advertisement by examining 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, consider the router links advertisements generated by Router RT3, as pictured in Figure 6. The area containing Router RT3 (Area 1) has been redrawn, with actual network addresses, in Figure 15. Assume that 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. In addition, 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 then shown below. It indicates that RT3 has two connections to Area 1, the first a link to the transit network 192.1.1.0 and the second a link to the stub network 192.1.4.0. Note that 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). Note also that RT3 has indicated that it is capable of calculating separate routes based on IP TOS, through setting the T-bit in the Options field. It has also 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 ;area border router
#links = 2
Link ID = 192.1.1.4 ;IP address of Desig. Rtr.
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 RT3's router links advertisement for the backbone is shown. It indicates that RT3 has a single attachment to the backbone. This attachment is 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 ;area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link
Type = 1 ;connects to router
# other metrics = 0
TOS 0 metric = 8Even though Router RT3 has indicated that it is TOS-capable in the above examples, 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 the appropriate TOS value. Router RT3 would then originate the following router links advertisement for the backbone (TOS 8 = maximize throughput): 🚀
; 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 ;area border router
#links = 1
Link ID = 18.10.0.6 ;Neighbor's Router ID
Link Data = 0.0.0.3 ;MIB-II ifIndex of P-P link
Type = 1 ;connects to router
# other metrics = 1
TOS 0 metric = 8
TOS = 8 ;maximize throughput
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; 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 is flushed by prematurely incrementing the advertisement's age to MaxAge and reflooding (see Section 14.1). In addition, in those rare cases where a router's Router ID has changed, any network links advertisements that were originated with the router's previous Router ID must be flushed. Since the router may have no idea what its previous Router ID might have been, these network links advertisements are indicated by having their Link State ID equal to one of the router's IP interface addresses and their Advertising Router not equal to the router's current Router ID (see Section 13.4 for more details). 😭
As an example of a network links advertisement, again consider 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 Desig. Rtr.
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
Summary link advertisements are lowkey the gossip of the area 🎀 Each one describes a route to just one destination. They only get flooded throughout a single area, never further. The destination lives outside the area but still belongs to the Autonomous System ✨
Summary link advertisements are originated by area border routers 🦋 The exact summary routes to push into an area come from checking the routing table structure (see Section 11) using the algorithm below. Only intra-area routes get advertised into the backbone, while both intra-area and inter-area routes go into the other areas 💜
To figure out what to advertise into an attached Area A, we process each routing table entry like this. Each entry describes a set of equal-cost best paths to a particular destination, so keep that in mind 🫶
- Only Destination Types of network and AS boundary router are advertised in summary link advertisements. If the entry's Destination Type is area border router, skip to the next entry 💀
- AS external routes are never advertised in summary link advertisements. If the entry has Path-type of type 1 external or type 2 external, skip to the next entry 🙈
- Else, if the area associated with this set of paths is Area A itself, don't generate a summary link advertisement for the route.[14]
- Else, if the next hops associated with this set of paths belong to Area A itself, don't generate a summary link advertisement for the route.[15] This is the logical equivalent of a Distance Vector protocol's split horizon logic, iykyk 🌸
- Else, if the routing table cost equals or exceeds the value LSInfinity, a summary link advertisement can't be generated for this route 😭
- 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 Router 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 (if necessary, the Link State ID can also have one or more of the network's host bits set; see Appendix F for details) and metric equal to the routing table cost 🧚
- The one remaining case is an intra-area route to a network. This means the network is contained in one of the router's directly attached areas. This info usually has to 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 with a status indication of either Advertise or DoNotAdvertise. At most a single Type 3 advertisement is made for each range. When the range's status is Advertise, a Type 3 advertisement is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix F for details) and cost equal to the smallest cost of any of the component networks. When the range's status is DoNotAdvertise, the Type 3 advertisement is suppressed and the component networks stay hidden from other areas 🙈
By default, if a network isn't contained in any explicitly configured address range, a Type 3 advertisement is generated with Link State ID equal to the network's address (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix F for details) and metric equal to the network's routing table cost 💅
If virtual links are being used to provide or increase connectivity of the backbone, routing information about the backbone networks shouldn't be condensed before being summarized into the virtual links' Transit areas. The advertisement of backbone networks into Transit areas shouldn't be suppressed either. In other words, the backbone's configured ranges get ignored when originating summary links into Transit areas. The existence of virtual links is determined during the shortest path calculation for the Transit areas (see Section 16.1) ✨
If a router advertises a summary advertisement for a destination that then becomes unreachable, the router has to 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 according to the procedure above (for example, it's now an inter-area route when it used to be an intra-area route associated with 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, look at the area configuration in Figure 6 again. Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, so they're originating summary link advertisements. Let's zoom in on Router 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 originates separate advertisements for each of the networks N1-N4. Into Area 1, RT4 originates 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 link advertisement. Finally, the routes to networks N9,N10,N11 and Host H1 are advertised by a single summary link advertisement. This condensation was originally performed 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 shown 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 ;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 ;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 can be separate sets of paths, and so separate routing table entries, for each Type of Service. All of these entries have to be considered when building the summary link advertisement for the destination. A single advertisement has to 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 indicates that 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. Originating summary links into stub areas ✨
The algorithm in Section 12.4.3 is optional when Area A is an OSPF stub area. Area border routers connecting to a stub area can originate summary link advertisements into the area according to the above Section's algorithm, or they can choose to originate only a subset of the advertisements, possibly under configuration control. The fewer advertisements originated, the smaller the stub area's link state database, which further reduces the demands on its routers' resources 🧚 However, omitting advertisements may also lead to sub-optimal inter-area routing, although routing will continue to function 😭
As specified in Section 12.4.3, Type 4 link state advertisements (ASBR summary links) are never originated into stub areas 💀
In a stub area, instead of importing external routes, each area border router originates a "default summary link" into the area. The Link State ID for the default summary link is set to DefaultDestination, and the metric is set to the (per-area) configurable parameter StubDefaultCost. Note that StubDefaultCost doesn't need to be configured identically in all of the stub area's area border routers 🌸
12.4.5. AS external links 🦋
AS external link advertisements are how you tell the whole AS about routes to destinations OUTSIDE it 🌍✨ Most of them describe one specific external destination, so the Link State ID is set to that destination network's IP address 💖 (if needed, the Link State ID can also have one or more of the network's "host" bits set, see Appendix F for the deets 🙈). But if you want to describe a default route for the whole AS, you set the Link State ID to DefaultDestination (0.0.0.0) 🧚 AS boundary routers originate these, and each AS boundary router makes ONE AS external link advertisement for every external route it has learned, whether that came from another routing protocol (like EGP) or from configuration 💅
Lowkey the most iconic thing about these: they're the ONLY type of link state advertisement that gets flooded through the entire AS 👑 Everything else stays inside its own area. BUT AS external link advertisements are NOT flooded into or throughout stub areas (see Section 3.6) 🌸 That's how the link state database gets smaller for routers sitting inside stub areas 🫶
The metric on 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 bigger than the cost of any intra-AS path. Same as 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). And if the T-bit of the advertisement's Options field is clear, no non-zero TOS paths to the destination exist 🙅♀️
Now the big one: if a router advertised an AS external link advertisement for a destination that then becomes unreachable, the router MUST then flush it from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1) 😭 no ghosting allowed, you have to clean up your own mess 🧹
For an example, look at the AS pictured in Figure 6 again ✨ There are two AS boundary routers, RT5 and RT7. RT5 originates three external link advertisements, for networks N12-N14. RT7 originates two, for N12 and N15. Say RT7 learned its route to N12 via EGP and wants to advertise a Type 2 metric to the AS. RT7 would then originate this 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) 🦋 Honestly that's not always the move 🙈 Check out the setup in Figure 16. There are three OSPF routers (RTA, RTB and RTC) hanging off a common network. Only RTA is swapping EGP info with the non-OSPF router RTX. So RTA MUST then originate AS external link advertisements for the destinations it learned from RTX. By using the forwarding address field, RTA can say "send packets for these destinations straight to RTX" 🎀 Without that, RTB and RTC would take an extra hop to get there, and nobody wants that 💀
+
|
+---+.....|.EGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
Figure 16: Forwarding address exampleNote that when the forwarding address field is non-zero, it SHOULD point to a router belonging to another Autonomous System 🌈
You can also set a forwarding address 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 advertisement is below, and 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 suppose instead that both RTA and RTB swap EGP info with RTX ✨ Then RTA and RTB would both originate the same set of AS external link advertisements. If they specify the same metric, those advertisements are functionally equivalent, since they 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 them, or else neither MAY, or the originator could keep flip-flopping 🙃 So the rule is: if two routers, both reachable from one another, originate functionally equivalent AS external advertisements (i.e., same destination, cost and non-zero forwarding address), then the advertisement originated by the router with the highest OSPF Router ID is used 🏆 The router with the lower OSPF Router ID can then flush its advertisement. Flushing is discussed in Section 14.1 🧹
13. The Flooding Procedure ✨
Link State Update packets are the delivery vehicle for flooding link state advertisements 🚚 A Link State Update packet MAY contain several distinct advertisements, and it floods each one a hop further from where it started. To make flooding reliable, each advertisement MUST be acknowledged separately 🫶 Acknowledgments travel in Link State Acknowledgment packets, and a bunch of separate acknowledgments can get bundled together into one packet 📦
The flooding procedure kicks off when a Link State Update packet has been received 💖 A ton of consistency checks have already happened before the packet reaches flooding (see Section 8.2). Most importantly, the packet has been tied to a particular neighbor and a particular area. If the neighbor is in a lesser state than Exchange, the packet SHOULD be dropped without any further processing 🙅♀️
Every link state advertisement is tied to a specific area EXCEPT AS external link advertisements 🌸 The catch is that link state advertisements don't have an area field, so the area MUST be deduced from the Link State Update packet header 🕵️♀️
For each link state advertisement in the packet, you do the following:
(1) Validate the advertisement's LS checksum. If the checksum is invalid, discard that advertisement and grab the next one from the Link State Update packet 💅
(2) Check the advertisement's LS type. If it's an unknown type, discard 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 link advertisement (LS type = 5) and the area is configured as a stub area, discard it and grab the next one from the Link State Update Packet. AS external link advertisements are not flooded into or throughout stub areas (see Section 3.6) 🌸
(4) Else, if the advertisement's LS age is equal to MaxAge, and the router's link state database has no current instance of it, then do the following:
- (a) Acknowledge receipt 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
MaxAgeadvertisement in the link state database. Otherwise, simply discard it. Either way, look at the next advertisement (if any) 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's no database copy, or the received advertisement is more recent than the database copy (see Section 13.1 below for how "more recent" is decided), the following steps MUST be performed:
- (a) If there is already a database copy, and it was installed less than
MinLSIntervalseconds ago, discard the new advertisement (without acknowledging it) and examine the next advertisement (if any) listed in the Link State Update packet 🙈
(b) Okay so, next up: immediately flood the new advertisement out some subset of the router's interfaces (see Section 13.3). Sometimes the advertisement gets flooded right back out the interface it came in on (e.g., the receiving interface is DR and the advertisement came from a router other than the Backup DR) 🙈. Make sure to note that, because the acknowledgment process (Section 13.5) needs it later 📝.
(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 copy 💖. This might schedule the routing table calculation ✨. Also, timestamp the new advertisement with the current time (aka the time it was received) ⏰. The flooding procedure can't overwrite the newly installed advertisement until MinLSInterval seconds have passed 🫶. The install process gets more detail in Section 13.2 💅.
(e) Possibly acknowledge receipt of the advertisement by sending a Link State Acknowledgment packet back out the receiving interface 📬. More on this in Section 13.5 below 🌸.
(f) If the new link state advertisement says the receiving router originated it (aka it's a self-originated advertisement), the router must take special action 😭. That means either updating the advertisement or, in some cases, flushing it from the routing domain 🧼. Section 13.4 explains how self-originated advertisements get detected and handled 🔍.
(6) Else, if there's an instance of the advertisement on the sending neighbor's Link state request list, something went wrong in the Database Exchange process 💀. To fix it, restart Database Exchange 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 (neither one is more recent), do the following two steps 🪞:
(a) If the advertisement is on the Link state retransmission list for the receiving adjacency, the router is waiting for an acknowledgment for it 👀. So the router should treat the received advertisement as an acknowledgment and remove 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 💌. Details are below in Section 13.5 🌈.
(8) Else, the database copy is more recent 🙅♀️. Note an unusual event to network management, discard the advertisement, and move on to the next link state advertisement in the Link State Update 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 its database copy 🔁. The same comparison also has to happen during the Database Exchange procedure, which runs during adjacency bring-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 instance is more recent 🔢:
- The advertisement with the newer LS sequence number is more recent 🏆. See Section 12.1.6 for how the LS sequence number space works 📚. 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 instance has its LS age field set to
MaxAge, that instance (the one with ageMaxAge) is considered more recent 🌟. - Else, if the LS age fields of the two instances differ by more than
MaxAgeDiff, the instance with the smaller (younger) LS 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 can cause the OSPF routing table structure to be recalculated 🧮. That happens whether the advertisement came from flooding or was newly self-originated 🔄. The new advertisement should be compared to the old instance, if there is one 👩👧. If there's no difference, there's no need to recalculate the routing table 🙌. (Heads up: even when 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 parts of the routing table must be recalculated, depending on the new advertisement's LS type field 🗺️:
Router links and network links advertisements The entire routing table must be recalculated, starting with the shortest path calculations for each area (not just the area whose topological database changed) 🌍. Why not just the one changed area? AS boundary routers can belong to multiple areas 🧩. So a change in the area currently providing the best route may force the router to use an intra-area route from a different area 🔀.[16]
Summary link advertisements The best route to the destination described by the summary link advertisement must be recalculated (see Section 16.5) 🎯. If that destination is an AS boundary router, it may also be necessary to re-examine all the AS external link advertisements 🔎.
AS external link advertisements The best route to the destination described by the AS external link advertisement must be recalculated (see Section 16.6) 🛣️.
Also, any old instance of the advertisement must be removed from the database when the new one gets 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 is the processing in Section 13) 🫧. Specifically, it's about picking the outgoing interfaces and adding the advertisement to the right neighbors' Link state retransmission lists 📋. This part of the procedure also maintains the neighbors' Link state request lists 🗂️.
This section also applies to flooding an advertisement the router has just originated itself (see Section 12.4) 🪄. For those, this section is the entire flooding procedure 🎬. Section 13 doesn't run, because the advertisement never came from a neighbor, so it doesn't need to be acknowledged 🙅♀️.
Depending on the advertisement's LS type, it can only be flooded out certain interfaces 🚦. Those are called the eligible interfaces, and they're defined like this 💁♀️:
AS external link advertisements (LS Type = 5) AS external link advertisements 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 LS 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, that includes all the virtual links 🔗.
Link state databases must stay synchronized over all the adjacencies on those eligible interfaces 🫶. To make that happen, run these steps on each eligible interface 🔁. Heads up: the procedure might decide not to flood an advertisement out a particular interface if the attached neighbors have a high probability of already having it 🤷♀️. But the flooding procedure has to be absolutely sure the neighbors eventually get it, so the advertisement still gets added to each adjacency's Link state retransmission list 💪. For each eligible interface:
(1) Check each neighbor attached to this interface, to see if they must receive the new advertisement 👀. Do the following for each neighbor:
(a) If the neighbor is in a lesser state than Exchange, it doesn't take part in flooding, so move on to the next neighbor 🙃.
(b) Else, if the adjacency isn't full yet (neighbor state is Exchange or Loading), look at the Link state request list for this adjacency 🔍. If an instance of the new advertisement is on that list, the neighbor already has an instance of the advertisement 🙌. Compare the new advertisement to the neighbor's copy:
- If the new advertisement is less recent, examine the next neighbor 👋.
- If the two copies are the same instance, delete the advertisement from the Link state request list, then examine the next neighbor 🗑️.[17]
- Else, the new advertisement is more recent. Delete the advertisement from the Link state request list 🧹.
(c) If the new advertisement came from this neighbor, examine the next neighbor 🫠.
(d) At this point we're not positive the neighbor has an up-to-date instance of this new advertisement 🥺. So add the new advertisement to the Link state retransmission list for the adjacency 📥. This keeps flooding reliable: the advertisement gets retransmitted at intervals until the neighbor's acknowledgment shows up ✅.
okay so the router has to decide whether to flood the new link state advertisement out this interface 🤔 if back in the previous step the advertisement was NOT added to any of the Link state retransmission lists, there's no reason to flood it out here. just check the next interface 💅
(3) if the new advertisement came in on this interface and from either the Designated Router or the Backup Designated Router, chances are every neighbor already has it 🫶 so skip this interface and move on to the next one.
(4) if the new advertisement came in on this interface and the interface state is Backup (aka the router itself is the Backup Designated Router), skip it too 🦋 the Designated Router is the one doing the flooding on this interface. if the Designated Router fails, this router ends up retransmitting the updates instead, so it's a backup for a reason 😭
(5) okay, if we've made it this far, the advertisement has to be flooded out the interface 🔥 send a Link State Update packet (with the new advertisement as its contents) out the interface. the advertisement's LS age must be incremented by InfTransDelay (which must be > 0) when it gets copied into the outgoing Link State Update packet, until the LS age field hits its max value of MaxAge 🌈
on broadcast networks, Link State Update packets are multicast 📣 the destination IP address depends on the interface state. if the interface state is DR or Backup, use AllSPFRouters. otherwise, use AllDRouters.
on non-broadcast, multi-access networks, it's a different vibe 🌸 separate Link State Update packets must be sent as unicasts to each adjacent neighbor (aka the ones 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 super common for a router to get its own link state advertisements back through the flooding procedure 🙈 an advertisement counts as self-originated when either 1) its Advertising Router equals the router's own Router ID, or 2) it's a network links advertisement and its Link State ID equals one of the router's own IP interface addresses.
but here's the tea ☕ if the self-originated advertisement it received is newer 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 router last restarted 😱 in most cases, the router must advance the advertisement's LS sequence number one past the received LS sequence number, and originate a new instance of the advertisement.
BUT the router might not want to originate the received advertisement anymore, and that's valid too 💀 for example: 1) the advertisement is a summary link or AS external link and the router no longer has an (advertisable) route to the destination, 2) the advertisement is a network links advertisement but the router is no longer Designated Router for the network, or 3) the advertisement is a network links advertisement whose Link State ID is one of the router's own IP interface addresses, but whose Advertising Router isn't equal to the router's own Router ID. (that third one should be rare, and it means the router's Router ID changed since it originated the advertisement 👀)
in all of these cases, instead of updating the advertisement, it should be flushed from the routing domain. to do that, increment the received advertisement's LS age to MaxAge and reflood it (see Section 14.1) 🧹✨
13.5. Sending Link State Acknowledgment packets 💌
every newly received link state advertisement must be acknowledged 🫶 this is usually done by sending Link State Acknowledgment packets. acknowledgments can also happen implicitly, by sending Link State Update packets (see step 7a of Section 13).
lots of acknowledgments can get grouped into one Link State Acknowledgment packet 📦 that packet gets sent back out the interface that received the advertisements. it can go out in one of two ways: delayed and sent on an interval timer, or sent directly (as a unicast) to a particular neighbor. which one gets used depends on the circumstances around the receipt of the advertisement.
delayed acks are lowkey genius 🧠 they let you package multiple acks into one packet, they let one packet acknowledge several neighbors at once (through multicasting), and they randomize when the various routers on a multi-access network send their Link State Acknowledgment packets 🎲 the fixed interval between a router's delayed transmissions must be short (less than RxmtInterval) or needless retransmissions will ensue 🙃
direct acks go to one particular neighbor when a duplicate link state advertisement shows up 🎯 they're sent as unicasts, and they go out immediately when the duplicate is received.
the precise procedure is in Table 19 💖 the circumstances of receiving the advertisement are in the left column, and the ack action is in one of the two right columns. the action depends on the interface state, and interfaces in state Backup act differently from interfaces in all other states. delayed acks must be delivered to all adjacent routers associated with the interface. on broadcast networks, that means sending the delayed Link State Acknowledgment packets as multicasts. the Destination IP address depends on the interface state: if it's DR or Backup, the destination is AllSPFRouters; in other states, it's AllDRouters. on non-broadcast networks, delayed Link State Acknowledgment packets must be unicast separately over each adjacency (aka each neighbor whose state is >= Exchange).
why multicast? let me explain with an example 🧚 imagine the network configuration in Figure 15. say RT4 got elected as Designated Router, and RT3 as Backup Designated Router, for network N3. when RT4 floods a new advertisement to N3, it's received by RT1, RT2, and RT3. these routers won't flood it back onto net N3, but they still need to keep their topological databases synchronized with their adjacent neighbors 🔄 so RT1, RT2, and RT4 are all waiting to see an acknowledgment from RT3. likewise, RT4 and RT3 are both waiting to see acks from RT1 and RT2. the best way to make everyone happy is to send the acks as multicasts 🎀
the reason the Backup DR's ack logic is slightly different is that they behave differently during flooding (see Section 13.3, step 4) 🛡️
13.6. Retransmitting link state advertisements 🔁
advertisements flooded out an adjacency get placed on that adjacency's Link state retransmission list 📋 to make flooding reliable, these advertisements get retransmitted until they're acknowledged. the time between retransmissions is a configurable per-interface value called RxmtInterval. if it's 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
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 acknowledg- Delayed ack-
more recent than ment sent if adver- nowledgment sent.
database copy, but tisement received
was not flooded from Designated
back out receiving Router, otherwise
interface do nothing
_______________________________________________________________
Advertisement is a Delayed acknowledg- No acknowledgment
duplicate, and was ment sent if adver- sent.
treated as an im- tisement received
plied acknowledg- from Designated
ment (see Section Router, otherwise
13, step 7a). do nothing
_______________________________________________________________
Advertisement is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
_______________________________________________________________
Advertisement's LS Direct acknowledg- Direct acknowledg-
age is equal to ment sent. ment sent.
MaxAge, 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.affected 🥺
several retransmitted advertisements can fit into a single Link State Update packet 📦 when advertisements need retransmitting, only the number that fits in one Link State Update packet should be sent. another packet of retransmissions can go out once some of the advertisements get 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 it's copied into the outgoing Link State Update packet, until the LS age field reaches MaxAge.
if the adjacent router goes down, retransmissions may keep happening until OSPF's Hello Protocol destroys the adjacency 👋 once the adjacency is destroyed, the Link state retransmission list gets cleared 🧹
13.7. Receiving link state acknowledgments 🫧
Okay so, before a Link State Acknowledgment packet even gets handed to the flooding procedure 💅, it has to pass a bunch of consistency checks. The big one is that it has to be tied to a particular neighbor. If that neighbor is in a state lesser than Exchange, the packet gets tossed. No drama, just bye 👋
Otherwise, the router goes through each acknowledgment in the packet, one at a time:
- Does the acknowledged advertisement have an instance on the Link state retransmission list for that neighbor? If not, skip to the next acknowledgment. Otherwise:
- If the acknowledgment is for the same instance that's on the list, remove the item from the list and move on to the next acknowledgment. Otherwise:
- Log the questionable acknowledgment, and move on to the next one. 📝
14. Aging The Link State Database ✨
Every link state advertisement has an LS age field 🕰️, and it's measured in seconds. The LS age goes up while the advertisement is sitting in a router's database. It also goes up when the advertisement gets copied into a Link State Update Packet for flooding out a particular interface, and in that case it's bumped by InfTransDelay.
An advertisement's LS age is never incremented past MaxAge. Advertisements that have hit MaxAge aren't used in the routing table calculation, which is giving "not invited to the party" energy 💀. As a router ages its database, an advertisement's LS age can reach MaxAge.[18] When that happens, the router must attempt to flush the advertisement from the routing domain. The way it does this is simple: it refloods the MaxAge advertisement just like it's a brand new one (see Section 13.3). 🧹
When a router builds a Database summary list for a newly forming adjacency, 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 must be removed right away from the router's link state database, as soon as both of these are true: a) it's no longer on any neighbor's Link state retransmission lists, and b) none of the router's neighbors are in states Exchange or Loading. ✅
When, during aging, an advertisement's LS age hits a multiple of CheckAge, its LS checksum should be verified. If the checksum is wrong, that means a program or memory error has happened, and at the very least the router itself should be restarted. Yikes 😭
14.1. Premature aging of advertisements 💅
A link state advertisement can be flushed from the routing domain by setting its LS age to MaxAge and then refloodng it. This follows the same course as flushing an advertisement whose LS age naturally hit MaxAge (see Section 14). In particular, the MaxAge advertisement gets removed from the router's link state database as soon as a) it's no longer on any neighbor Link state retransmission lists, and b) none of the router's neighbors are in states Exchange or Loading. We call setting an advertisement's LS 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 instance (the one with LS sequence number 0x7fffffff) has to 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 also gets used in other situations. For example, if one of the router's previously advertised external routes is no longer reachable, the router can flush its external advertisement from the routing domain by prematurely aging it. This is way more preferable than the alternative, which is originating a new advertisement for that destination with a metric of LSInfinity. Premature aging is also used when self-originated advertisements show up unexpectedly during the flooding procedure (see Section 13.4). 🧠
A router may only prematurely age its own self-originated link state advertisements. It may not prematurely age advertisements that were originated by other routers. An advertisement counts as self-originated when either 1) its Advertising Router is equal to the router's own Router ID, or 2) it's a network links advertisement and its Link State ID is equal to one of the router's own IP interface addresses. 🪞
15. Virtual Links 🦋
The single backbone area (Area ID = 0.0.0.0) cannot be disconnected, or some areas of the Autonomous System will become unreachable. 😱 To establish and maintain backbone connectivity, virtual links can be configured through non-backbone areas. Virtual links connect physically separate pieces of the backbone. Both endpoints of a virtual link are area border routers, and the virtual link has to be configured in both routers. Each router's configuration has 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 is 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 document calls such an adjacency a "virtual adjacency". 🌈
Each endpoint router figures out the cost and viability of the virtual link by checking the routing table entry for the other endpoint router. The entry's associated area has to be the configured transit area. There can 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 InterfaceUp event happens for a virtual link when its corresponding TOS 0 routing table entry becomes reachable. The InterfaceDown event happens when that TOS 0 entry becomes unreachable.[19] So basically, the virtual link is viable as long as an intra-area path exists through the transit area between the two endpoints. Also, a virtual link whose underlying path has a cost greater than hexadecimal 0xffff (the maximum size of an interface cost in a router links advertisement) should be considered inoperational, meaning it's treated as if the path didn't exist at all. 🙅♀️
Here are the other virtual link details:
- AS external links are never flooded over virtual adjacencies. That would be duplicated effort, since the same AS external links are already flooded throughout the virtual link's transit area. For that 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. It's defined as the cost of the intra-area path between the two defining area border routers, and that cost shows up in the virtual link's corresponding routing table entry. When the virtual link's cost changes, a new router links advertisement should be originated for the backbone area. 📈
- The virtual link's cost and viability are determined by the routing table build process, which constructs the routing table entry for the other endpoint. The IP interface address for the virtual interface and the virtual neighbor's IP address are figured out the same way. These get used when sending OSPF protocol packets over the virtual link. If one or both virtual link endpoints connect to the transit area over an unnumbered point-to-point link, it may be impossible to calculate the virtual interface's IP address and/or the virtual neighbor's IP address, which can make the virtual link fail. 🥲
- In each endpoint's router links advertisement for the backbone, the virtual link shows up as a Type 4 link. Its Link ID is set to the virtual neighbor's OSPF Router ID, and its Link Data is set to the virtual interface's IP address. See Section 12.4.1 for more information. There may be a TOS 0 path but no non-zero TOS paths between the two endpoint routers. In that case, both routers must revert to being non-TOS-capable, which means clearing the T-bit in the Options field of their backbone router links advertisements. 🔧
- 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 into the transit areas in its own separate summary link advertisement, no matter what the backbone's configured area address ranges are. 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. That 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. A router takes its attached areas' link state databases as input and runs the algorithm below, building its routing table step by step. At each step, the router needs to access individual pieces of the link state databases (for example, a router links advertisement originated by a certain router). That access happens through the lookup function discussed in Section 12.2. The lookup process might 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 gets treated just as if the lookup 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. The process breaks down into these 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. 🍓
(2) Okay so the intra-area routes get calculated by building the shortest-path tree for each attached area 🌸. Every routing table entry whose Destination Type is "area border router" gets worked out in this step. The whole thing happens in two parts: first the tree is built using only the links between routers and transit networks, and then the stub networks get tucked in. While the area's tree is being calculated, the area's TransitCapability gets figured out too, for later use in Step 4 ✨.
(3) The inter-area routes are calculated by looking through the summary link advertisements 💅. If the router is attached to multiple areas (i.e., it is an area border router), only the backbone summary link advertisements get examined. Bestie, it's giving backbone focus 👑.
(4) In area border routers connecting to one or more transit areas (i.e, non-backbone areas whose TransitCapability is found to be TRUE), the transit areas' summary link advertisements get examined to see whether better paths exist through those transit areas than the ones found in Steps 2-3 above 🦋.
(5) Routes to external destinations are calculated by looking through the AS external link advertisements 🌈. The locations of the AS boundary routers (the ones that originate the AS external link advertisements) were already pinned down in steps 2-4, so we're good to go 🫶.
Steps 2-5 get explained in more detail below 💖. The explanations only describe the calculations for TOS 0. It may also be necessary to perform each step (separately) for each of the non-zero TOS values.[20] For more on building the non-zero TOS routes, see Section 16.9 🎀.
Changes made to routing table entries from these calculations can make the OSPF protocol 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 the complete list of OSPF protocol actions that result from routing table changes 🧚.
16.1. Calculating the shortest-path tree for an area ✨
This calculation gives 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.[21] The tree is built in two stages. In the first stage, only the links between routers and transit networks are considered, and a tree is formed from this subset of the link state database using the Dijkstra algorithm 💜. In the second stage, leaves get added to the tree by looking at the links to stub networks 🌸.
The procedure uses 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 only deals with the transit vertices (routers and transit networks) and their connecting links. Throughout the shortest path calculation, each transit vertex also has the following data attached to it:
Vertex (node) ID A 32-bit number that uniquely identifies the vertex. For router vertices, this is the router's OSPF Router ID. For network vertices, this is the IP address of the network's Designated Router. 🫶
A link state advertisement Each transit vertex has an associated link state advertisement. For router vertices, this is a router links advertisement. For transit networks, this is 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 Vertex ID above 🔥.
List of next hops The list of next hops for the current set of shortest paths from the root to this vertex. There can be multiple shortest paths thanks to the equal-cost multipath capability 🌈. Each next hop shows the 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 The link state cost of the current set of shortest paths from the root to the vertex. The link state cost of a path is the sum of the costs of the path's constituent links (as advertised in router links and network links advertisements). One path is "shorter" than another if it has a smaller link state cost 👑.
The first stage (the Dijkstra algorithm) works like this, and it's honestly so elegant 😭. At each iteration there's a list of candidate vertices. Paths from the root to these vertices have been found, but they aren't necessarily the shortest ones yet. However, the path to whichever candidate is closest to the root is guaranteed to be shortest. That vertex gets added to the shortest-path tree and removed from the candidate list, and its adjacent vertices get examined for possible addition to or modification of the candidate list. Then the algorithm goes around again, and it stops when the candidate list is empty ✨.
The steps below spell it out in detail. Remember that we're computing the shortest path tree for Area A. Every link state database lookup below happens in Area A's database 🎀.
(1) Initialize the algorithm's data structures 🧚. Clear the list of candidate vertices. Set the shortest-path tree to only the root (the router doing the calculation). Set Area A's TransitCapability to FALSE.
(2) Call the vertex just added to the tree vertex V 🦋. Examine the link state advertisement associated with vertex V. This is a lookup in Area A's link state database based on the Vertex ID. If this is a router links advertisement and bit V of the router links advertisement (see Section A.4.2) is set, set Area A's TransitCapability to TRUE. In any case, each link described by the advertisement gives the cost to an adjacent vertex. For each described link (say it joins vertex V to vertex W):
- (a) If this is a link to a stub network, examine the next link in V's advertisement. Links to stub networks get considered in the second stage of the shortest path calculation 🌸.
- (b) Otherwise, W is a transit vertex (router or transit network). Look up vertex W's link state advertisement (router links or network links) in Area A's link state database. If the advertisement doesn't exist, or its LS age is equal to MaxAge, or it doesn't have a link back to vertex V, examine the next link in V's advertisement.[22] 💀
- (c) If vertex W is already on the shortest-path tree, examine the next link in the advertisement 🍓.
- (d) Calculate 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 vertices V and W. Then compare D:
- If D is greater than the value that already appears for vertex W on the candidate list, examine the next link.
- If D is equal to the value that appears for vertex W on the candidate list, calculate the set of next hops that result 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 that appear for W on the candidate list 💖.
- If D is less than the value that appears for vertex W on the candidate list, or if W doesn't yet appear on the candidate list, set the entry for W on the candidate list to indicate a distance of D from the root. Also calculate the list of next hops that result 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 as input the destination (W) and its parent (V) 🌈.
(3) If the candidate list is empty at this step, the shortest-path tree (of transit vertices) is completely built, and this stage ends 🎉. Otherwise, choose the vertex on the candidate list that's closest to the root, add it to the shortest-path tree, and remove it from the candidate list in the process. When there's a tie for closest to the root, network vertices must be chosen before router vertices so that all equal-cost paths get found. This matches the tie-breakers introduced in the modified Dijkstra algorithm used by OSPF's Multicast routing extensions (MOSPF) 🧠.
(4) Possibly modify the routing table 💅. For each routing table entry that gets 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 (call it ABR), a routing table entry is added whose destination type is "area border router". The Options field found in ABR's associated router links advertisement gets copied into the routing table entry's Optional capabilities field. And if ABR is also the endpoint of one of the calculating router's configured virtual links that uses Area A as its Transit area, a few things happen at once 🦋. The virtual link is declared up. The IP address of the virtual interface is set to the IP address of the outgoing interface calculated above for ABR. The virtual neighbor's IP address is set to the ABR interface address (contained in ABR's router links advertisement) that points back to the root of the shortest-path tree. Equivalently, this is the interface that points back to ABR's parent vertex on the shortest-path tree (similar to the calculation in Section 16.1.1) 🫶✨
Okay so when the newly added vertex is an AS boundary router, you go hunt down its routing table entry of type "AS boundary router" for the destination 🔍. Routers can belong to more than one area, so there might be several sets of intra-area paths to that ASBR, each one using a different area. Plot twist: the ASBR's entry has to end up with a set of paths that all use a single area 💖. The area gets picked like this: the area with the shortest path always wins ✨. If two or more areas tie on the minimum cost, the one with the largest OSPF Area ID (read as an unsigned 32-bit integer) takes the crown 👑. Also, whenever an ASBR's routing table entry gets added or modified, the Options from its associated router links advertisement get copied into the entry's Optional capabilities field 🎀.
If the newly added vertex is a transit network, you look up the routing table entry for that network 🌸. The entry's Destination ID is the IP network number, and you get it by masking the Vertex ID (Link State ID) with its subnet mask (which lives in the body of the associated network links advertisement) 🧚. Now, if the entry already exists, that means there's already an intra-area route to that destination in the table, so multiple vertices got 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 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' link state advertisement. Very particular, very iconic 💅.
If there's no routing table entry for the network (the usual case, honestly), you add one for the IP network 🍓. Its Link State Origin gets set to the newly added vertex' link state advertisement 💜.
(5) Then you loop back to Step 2 and keep the algorithm going 🔁.
The stub networks get added to the tree in the second stage of the procedure 🌈. In this stage, every router vertex gets checked again. The ones that were already marked unreachable in the first phase get tossed out 🗑️. For each reachable router vertex (let's call it V), you find its router links advertisement in the link state database. Then you examine every stub network link in that advertisement and run these steps:
(1) Calculate the distance D of the stub network from the root. D is the distance from the root to the router vertex (from stage 1), plus the stub network link's advertised cost ✨. Compare that to the current best cost to the stub network by looking up its current routing table entry. If D is larger, skip ahead and examine the next stub network link in the advertisement 🙅♀️.
(2) If you've reached this step, the stub network's routing table entry needs an update 🦋. Calculate the set of next hops you'd get from using the stub network link. That calculation is shown in Section 16.1.1, and its 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 that 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, so you overwrite the current entry: set its cost to D, and set its list of next hops to the newly calculated set 🔥. Set its Link State Origin to V's router links advertisement too. Then go examine the next stub network link 🏃♀️.
For all routing table entries added or modified in the second stage, the associated area gets set to Area A and the path type gets set to intra-area 💖. When the list of reachable router links runs out, the second stage is complete 🎉. At that point, every intra-area route associated with Area A has been determined ✨.
The specification does not require this two-stage method for calculating the shortest path tree 🙌. However, if some other 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 ordered to be included in the above tree 🦋. It's also worth mentioning that more efficient algorithms exist for calculating the tree. For example, there's the incremental SPF algorithm described in [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 of two things: the outgoing interface to use when forwarding packets to the destination, plus 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 turns up when the destination gets added to the candidate list, or when the destination's entry on the candidate list gets modified (Step 2d of Stage 1) 🌸. In stage 2, a shorter path is discovered each time the destination's routing table entry gets modified (Step 2 of Stage 2) 💜.
The set of next hops for the destination may get recalculated several times during the shortest-path tree calculation, as shorter and shorter paths keep showing up 🌈. In the end, though, the destination's routing table entry always reflects the next hops from the absolute shortest path(s) 👑.
The 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) and the destination 🧚. The parent is always a transit vertex, meaning it's always a router or a transit network 🫶.
If there's at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from its parent 🦋. Otherwise, there are two cases 🙈. In the first case, the parent vertex is the root (the calculating router itself). That means the destination is either a directly connected network or a directly connected router 🍓. The next hop here is simply the OSPF interface connecting to that network or router, and no next hop router is required 💖. If the connecting OSPF interface in this case is a virtual link, setting the next hop should be deferred until the calculation in Section 16.3 🔥.
In the second case, the parent vertex is a network that directly connects the calculating router to the destination router 🌟. The list of next hops is then determined by examining 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 the IP address of a next hop router 🤝. The outgoing interface to use can then be derived from that next hop IP address, or it can be inherited from the parent network 🎀.
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 (let's call it Area A) 🧠.
Summary link advertisements are originated by the area border routers 🏰. Each summary link advertisement in Area A gets 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:
(1) If the cost specified by the advertisement is LSInfinity, or if the advertisement's LS age is equal to MaxAge, then examine the the next advertisement 🙅♀️.
(2) If the advertisement was originated by the calculating router itself, examine the next advertisement 🪞.
(3) If the collection of destinations described by the summary link advertisement 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 advertisement 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 🫶.
(4) Else, call the destination described by the advertisement N, and call the area border originating the advertisement BR. (For Type 3 summary links, N's address is obtained by masking the advertisement's Link State ID with the network/subnet mask contained in the body of the advertisement 🧮.) Look up the routing table entry for BR that has Area A as its associated area 🔍. If no such entry exists for router BR (meaning BR is unreachable in Area A), do nothing with this advertisement and consider the next one in the list 😭. Otherwise, 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 💖.
(5) Okay, next up: look up the routing table entry for destination N, bestie. 💅 Its Destination Type is either Network or AS boundary router. If there's no entry for N, or the entry's path type is "type 1 external" or "type 2 external," then install the inter-area path to N. Give it associated area Area A, cost IAC, next hop equal to the list of next hops to router BR, and Advertising router equal to BR. 🦋
(6) Else, if the paths already in the table are intra-area paths, do nothing with the advertisement. Intra-area paths are always preferred, no debate. 👑
(7) Else, the paths in the routing table are also inter-area paths. Install the new path through BR if it's cheaper, overriding the paths in the table. Otherwise, if the new path has the same cost, add it to the list of paths in the routing table entry. Main character energy in the routing table. ✨
16.3. Examining transit areas' summary links
This step is only performed by area border routers attached to one or more transit areas. Transit areas are the areas supporting one or more virtual links, and their TransitCapability parameter was set to TRUE in Step 2 of the Dijkstra algorithm (see Section 16.1). They're the only non-backbone areas that can carry data traffic that neither originates nor terminates in the area itself. Think of them as the chill pass-through zones. 🌸
The goal of this calculation is to check the transit areas for any better (shorter) paths than the ones we already found in Sections 16.1 and 16.2. Any paths that are better than or equal to what we already found get installed in the routing table. Slay. 💖
Here's how it goes. All the transit areas' summary link advertisements get examined one at a time. Each one describes a route through a transit area Area A to a Network N (N's address is obtained by masking the advertisement's Link State ID with the network/subnet mask contained in the body of the advertisement). Or, if it's a Type 4 summary link advertisement, it describes a route to an AS boundary router N. The summary link advertisement was originated by an area border router BR. 🫶
(1) If the cost advertised by the summary link advertisement is LSInfinity, or if the advertisement's LS age is equal to MaxAge, then examine the next advertisement. 🙈
(2) If the summary link advertisement was originated by the calculating router itself, examine the next advertisement. No talking to yourself. 💀
(3) Look up the routing table entry for N. If it doesn't exist, or if the route type is other than intra-area or inter-area, or if the area associated with the routing table entry is not the backbone area, then examine the next advertisement. In other words, this calculation only updates backbone intra-area routes found in Section 16.1 and inter-area routes found in Section 16.2. 🎀
(4) Look up the routing table entry for the advertising router BR associated with Area A. If it's unreachable, examine the next advertisement. Otherwise, the cost to destination N is the sum of the cost in BR's Area A routing table entry and the cost advertised in the advertisement. Call this cost IAC. 🧮
(5) If this cost is less than the cost in N's routing table entry, overwrite N's list of next hops with the ones used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also stay the same. Stability is everything. 🔥
It's really important to note that this calculation never makes unreachable destinations reachable. It only potentially finds better paths to destinations that are already reachable. Also, unlike Section 16.3 of [RFC 1247], this calculation installs any better cost it finds into the routing table entry, so it can get readvertised in summary link advertisements to other areas. Iconic. 🌈
Okay, let's do an example. Picture the Autonomous System in Figure 17. There's a single non-backbone area (Area 1) that physically splits the backbone into two separate pieces. To keep the backbone connected, a virtual link is configured between routers RT1 and RT4. On the right side of the figure, Network N1 belongs to the backbone. The dotted lines show there's a much shorter intra-area backbone path between router RT5 and Network N1 (cost 20) than between Router RT4 and Network N1 (cost 100). Both Router RT4 and Router RT5 inject summary link advertisements for Network N1 into Area 1. 🧚
........................
. Area 1 (transit) . +
. . |
. +---+1 1+---+100 |
. |RT2|----------|RT4|=========|
. 1/+---+********* +---+ |
. /******* . |
. 1/*Virtual . |
1+---+/* Link . Net|work
=======|RT1|* . | N1
+---+\ . |
. \ . |
. \ . |
. 1\+---+1 1+---+20 |
. |RT3|----------|RT5|=========|
. +---+ +---+ |
. . |
........................ +Figure 17: Routing through transit areas
After the shortest-path tree is calculated for the backbone in Section 16.1, Router RT1 (the left end of the virtual link) will have calculated a path through Router RT4 for all data traffic destined for Network N1. But since Router RT5 is so much closer to Network N1, all routers inside Area 1 (e.g., Routers RT2 and RT3) forward their Network N1 traffic towards Router RT5 instead of RT4. And yep, after examining Area 1's summary link advertisements with the calculation above, Router RT1 also forwards Network N1 traffic towards RT5. 🎯 Note that in this example the virtual link lets Network N1 traffic be forwarded through the transit area Area 1, but the path the data traffic actually takes doesn't follow the virtual link. In other words, virtual links allow transit traffic to be forwarded through an area, but they don't dictate the precise path that the traffic takes. Not the link being the boss, lol. 🦋
16.4. Calculating AS external routes
AS external routes are calculated by examining AS external link advertisements. Each AS external link advertisement is considered in turn. Most of them describe routes to specific IP destinations. An AS external link advertisement can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS external link advertisement: 🌸
(1) If the cost specified by the advertisement is LSInfinity, or if the advertisement's LS age is equal to MaxAge, then examine the next advertisement. 🙈
(2) If the advertisement was originated by the calculating router itself, examine the next advertisement. 💀
(3) Call the destination described by the advertisement N. N's address is obtained by masking the advertisement's Link State ID with the network/subnet mask contained in the body of the advertisement. Look up the routing table entry for the AS boundary router (ASBR) that originated the advertisement. If no entry exists for router ASBR (meaning ASBR is unreachable), do nothing with this advertisement and consider the next one in the list.
Otherwise, this advertisement describes an AS external path to destination N. Examine the forwarding address specified in the AS external link advertisement. This is the IP address that packets for the destination should be forwarded to. 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.[23] 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. 🧁
(4) 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, the path type is set to type 1 external and the cost is equal to X+Y. If the external metric type is 2, 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. ✨
(5) Else, if the paths in the table are not type 1 or type 2 external paths, do nothing. AS external paths have the lowest priority, so they're basically the background characters. 🌈
(6) Otherwise, compare the cost of this new AS external path to the ones in the table. Type 1 external paths are always shorter than type 2 external paths. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths are compared by looking at the advertised type 2 metrics first, and then, if necessary, the distance to the forwarding addresses. 🔥
If the new path is shorter, it replaces the present paths in the routing table entry. If the new path has the same cost, it's added to the routing table entry's list of paths. 💅
16.5. Incremental updates -- summary link advertisements
When a new summary link advertisement shows up, we don't have to redo the whole routing table 😭✨ We just look at the one destination it's talking about. Call that destination N (we get N's address by masking the advertisement's Link State ID with the network/subnet mask in the body of the advertisement), and let Area A be the area the advertisement belongs to. There are two cases, so let's go 💅
Case 1: Area A is the backbone and/or the router is not an area border router.
Okay so in this case, the following calculations MUST be performed 🫶 First, if there's already an inter-area route to N, we invalidate N's routing table entry, but we save the entry's values first so we can compare later 📝 Then we run the calculation in Section 16.2 again, just for the single destination N. In that calculation, we look at all of Area A's summary link advertisements that describe a route to N. Also, if the router is an area border router attached to one or more transit areas, the calculation in Section 16.3 MUST be run again for the single destination. If those results changed the cost or path to an AS boundary router (like with a Type 4 summary link advertisement) or to any forwarding addresses, then all AS external link advertisements have to be reexamined by rerunning the calculation in Section 16.4. Otherwise, if N is now newly unreachable, the calculation in Section 16.4 MUST be rerun for the single destination N, in case there's an alternate external route to N 👀
Case 2: Area A is a transit area and the router is an area border router.
Here the following calculations MUST be performed 💖 First, if N's routing table entry has one or more inter-area paths that go through the transit area Area A, those paths SHOULD be removed 🗑️ If that removes every path from the entry, the entry SHOULD be invalidated. The entry's old values SHOULD be saved for later comparisons too. Next, the calculation in Section 16.3 MUST be run again for the single destination N. If this calculation made the cost to N go up, the complete routing table calculation MUST be rerun, starting with the Dijkstra algorithm in Section 16.1 💀 Otherwise, if the cost or path to an AS boundary router (like with a Type 4 summary link advertisement) or to any forwarding addresses has changed, all AS external link advertisements have to be reexamined by rerunning the calculation in Section 16.4. Otherwise, if N is now newly unreachable, the calculation in Section 16.4 MUST be rerun for the single destination N, in case an alternate external route to N exists.
16.6. Incremental updates -- AS external link advertisements ✨
When a new AS external link advertisement arrives, we don't need to recalculate the entire routing table either 🙌 Call the destination it describes N. N's address comes from masking the advertisement's Link State ID with the network/subnet mask in the body of the advertisement. If there's already an intra-area or inter-area route to that destination, no recalculation is necessary, because internal routes take precedence 💅
Otherwise, the procedure in Section 16.4 has to be performed, but only for those AS external link advertisements whose destination is N. Before that procedure runs, the present routing table entry for N SHOULD be invalidated.
16.7. Events generated as a result of routing table changes 🌸
Routing table changes can make OSPF area border routers take extra actions. These routers need to act on the following routing table 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 is not simply a change of AS external routes, new summary link advertisements MAY have to be generated (potentially one for each attached area, including the backbone). See Section 12.4.3 for more information. If a previously advertised entry has been deleted, or is no longer advertisable to a particular area, the advertisement MUST be flushed from the routing domain by setting its LS age to
MaxAgeand reflooding (see Section 14.1). - A routing table entry associated with a configured virtual link has changed. The destination of such an entry is an area border router. The change indicates a modification to the virtual link's cost or viability.
- If the entry indicates that the area border router is newly reachable (via TOS 0), the corresponding virtual link is now operational. An
InterfaceUpevent SHOULD be generated for the virtual link, which will cause a virtual adjacency to begin to form (see Section 10.3). At this time, the virtual link's IP interface address and the virtual neighbor's Neighbor IP address are also calculated. - If the entry indicates that the area border router is no longer reachable (via TOS 0), the virtual link and its associated adjacency SHOULD be destroyed. This means an
InterfaceDownevent SHOULD be generated for the associated virtual link. - If the cost of the entry has changed, and there is a fully established virtual adjacency, a new router links advertisement for the backbone MUST be originated. This in turn MAY cause further routing table changes.
- If the entry indicates that the area border router is newly reachable (via TOS 0), the corresponding virtual link is now operational. An
16.8. Equal-cost multipath 🦋
The OSPF protocol maintains multiple equal-cost routes to all destinations. You can see this in the steps used above to calculate the routing table, and in the definition of the routing table structure.
Each one of the multiple routes is of the same type (intra-area, inter-area, type 1 external or type 2 external), has the same cost, and has the same associated area. However, each route specifies a separate next hop and Advertising router.
There's no requirement that a router running OSPF keep track of all possible equal-cost routes to a destination. An implementation MAY choose to keep only a fixed number of routes to any given destination. This doesn't affect any of the algorithms presented in this specification.
16.9. Building the non-zero-TOS portion of the routing table 🎀
The OSPF protocol can calculate a different set of routes for each IP TOS (see Section 2.4). Support for TOS-based routing is OPTIONAL. TOS-capable and non-TOS-capable routers can be mixed in an OSPF routing domain. Routers that don't support TOS calculate only the TOS 0 route to each destination. Those routes are then used to forward all data traffic, regardless of the TOS indications 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 sections above that detail the routing table calculations handle the TOS 0 case only. In general, for routers supporting TOS-based routing, each piece of the routing table calculation MUST 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 (a cost for TOS 0 MUST always be specified). The encoding of TOS in OSPF link state advertisements is described in Section 12.3.
An advertisement can specify that it is restricted to TOS 0 (i.e., non-zero TOS is not 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. For this reason, it's possible that a destination is unreachable for some non-zero TOS. In that case, the TOS 0 path is used when forwarding packets (see Section 11.1).
The following lists the modifications needed when running the routing table calculation for a non-zero TOS value (called TOS X). In general, routers and advertisements that do not support TOS are omitted from the calculation.
Calculating the shortest-path tree (Section 16.1). Routers that do not support TOS-based routing SHOULD be omitted from the shortest-path tree calculation. These routers are identified as those having the T-bit reset in the Options field of their router links advertisements. Such routers SHOULD never be added to the Dijkstra algorithm's candidate list, nor SHOULD their router links advertisements be examined when adding the stub networks to the tree. In particular, if the T-bit is reset in the calculating router's own router links advertisement, it does not run the shortest-path tree calculation for non-zero TOS values.
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 MUST also specify TOS X. In other words, 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. Note that this means summary link advertisements having the T-bit reset in their Options field are not considered 🙈
Examining transit areas' summary links (Section 16.3). This calculation again considers the concatenation of a path to an area border router with a summary link. As 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). This calculation considers the concatenation of a path to a forwarding address with an AS external link. Only TOS X paths to the forwarding address are examined, and the AS boundary router MUST be advertising a TOS X route to the destination. Note that this means AS external link advertisements having the T-bit reset in their Options field are not considered.
In addition, the advertising AS boundary router MUST also be reachable for its advertisements to be considered (see Section 16.4). However, if the advertising router and the forwarding address are not one and the same, the advertising router need only be reachable via TOS 0 💜
Footnotes 🫧
okay so bestie, these footnotes are full of the good stuff 🤓 I'm going to go one by one so nothing gets lost 💅
[1] The graph's vertices are routers, transit networks, or stub networks 🕸️ Since a router can belong to multiple areas, you literally cannot color the graph's vertices 🙅♀️
[2] It's possible for every single one of a router's interfaces to be unnumbered point-to-point links 🤯 When that happens, an IP address must be assigned to the router. That address then gets advertised in the router's router links advertisement as a host route ✨
[3] In these cases, the non-virtual interface and the virtual interface would both have the same IP address 👯
[4] No host route gets generated for interfaces to unnumbered point-to-point networks, and no IP packets can be addressed to them 🚫 This is true regardless of that interface's state 💀
[5] Okay this one is so instructive 🥹 Picture the Designated Router for the network crashing. Let's call that DR RT1, and its Backup Designated Router RT2. If RT1 crashes (or its interface to the network just dies), the other routers on the network will notice RT1 is missing within RouterDeadInterval seconds. But they won't all notice at the exact same moment 🕰️ The routers that catch RT1's absence before RT2 does will, for a little while, pick RT2 to be both Designated Router and Backup Designated Router. Then once RT2 realizes RT1 is gone, it moves itself up to Designated Router 👑 And at that point, the remaining router with the highest Router Priority gets picked as the Backup Designated Router 🎀
[6] On point-to-point networks, the lower level protocols tell you whether the neighbor is up and running 🛰️ Same deal for virtual links, where the routing table calculation shows whether the neighbor exists. BUT the Hello Protocol still gets used in both cases 🫶 That's how you make sure communication between the neighbors is bidirectional, and that each neighbor has a working routing protocol layer 💜
[7] When the identity of the Designated Router is changing, it's pretty common for a neighbor in this state to send the router a Database Description packet 📨 That just means there's a little momentary disagreement about who the Designated Router is 🙈
[8] Here's a fun one 🔁 A router can resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart. That makes the other end of the adjacency process a SeqNumberMismatch event, which means it also goes back to ExStart state 🔄
[9] Plot twist 🌀 The address space of IP networks and the address space of OSPF Router IDs can overlap! So a network might have an IP address that's identical (when you treat it as a 32-bit number) to some router's Router ID 🧚
[10] This one's a rule 📏 It's assumed that, for two different address ranges matching the destination, one range is more specific than the other. You can configure non-contiguous subnet masks to break that assumption, but OSPF can't handle those subnet mask configurations 😭
[11] MaxAgeDiff is an architectural constant 🏛️ It tells you the maximum dispersion of ages, in seconds, that can happen for a single link state instance as it gets flooded throughout 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 the advertisement's previous LS sequence number. See Section 13.4 for more details ✨
[12] When two advertisements have different LS checksums, they're assumed to be separate instances 🧩 This can also happen when a router restarts and loses track of the advertisement's previous LS sequence number. If the two advertisements have the same LS sequence number, it's impossible to tell which link state is actually newer 🤷♀️ If the wrong one gets accepted as newer, the originating router will originate another instance. See Section 13.4 for further details 💅
[13] There's exactly one spot where you have to do a lookup using only partial information 🔍 That's during the routing table calculation, when a network links advertisement has to be found based solely on its Link State ID. The lookup still works perfectly, though, because no two network links 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] This clause only kicks in when Area A is a Transit area supporting one or more virtual links 🚇 For example, in the area configuration of Figure 6, Router RT11 only needs to originate a single summary link with the (collapsed) destination N9-N11,H1 into its connected Transit area, Area 2 🌸 That's because all of its other eligible routes have next hops belonging to Area 2, so they only need to be advertised by other area border routers. In this case, those are Routers RT10 and RT7 🫧
[16] By keeping more information in the routing table, an implementation can recalculate the shortest path tree for just a single area 🌳 In fact, there are incremental algorithms that let an implementation recalculate only a portion of a single area's shortest path tree [BBN]. Those algorithms are beyond the scope of this specification, though 🙈
[17] 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.
[18] It should be a pretty rare occurrence for an advertisement's LS age to reach MaxAge this way 🙏 Usually, the advertisement gets replaced by a more recent instance before it ages out ⏳
[19] Only the TOS 0 routes matter here, because all OSPF protocol packets are sent with TOS = 0 📦 See Appendix A.
[20] Some destinations' paths may not vary based on TOS 🛤️ For those, 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 those destinations, instead of a separate entry for each TOS value 🧠
[21] 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 📚
[22] Note that the presence of any link back to V is enough. It doesn't need to be the matching half of the link under consideration from V to W 🔗 That's enough to make sure that, before data traffic flows between a pair of neighboring routers, their link state databases are synchronized 💜
[23] When the forwarding address is non-zero, it should point to a router belonging to another Autonomous System 🌍 See Section 12.4.5 for more details.
References 📚
Here are all the references, copied exactly as they were written 🫶
[BBN] McQuillan, J., I. Richer and E. Rosen, "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, R., "Fault-Tolerant Broadcast of Routing
Information", Computer Networks, December 1983.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[RFC 905] McKenzie, A., "ISO Transport Protocol specification
ISO DP 8073", RFC 905, ISO, April 1984.
[RFC 1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, Stanford University, May 1988.
[RFC 1213] McCloghrie, K., and M. Rose, "Management Information
Base for network management of TCP/IP-based
internets: MIB-II", STD 17, RFC 1213, Hughes LAN
Systems, Performance Systems International, March
1991.
[RFC 1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
July 1991.
[RFC 1519] Fuller, V., T. Li, J. Yu, and K. Varadhan,
"Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy", RFC1519,
BARRNet, cisco, MERIT, OARnet, September 1993.
[RFC 1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD
2, RFC 1340, USC/Information Sciences Institute,
July 1992.
[RFC 1349] Almquist, P., "Type of Service in the Internet
Protocol Suite", RFC 1349, July 1992.
[RS-85-153] Leiner, B., et.al., "The DARPA Internet Protocol
Suite", DDN Protocol Handbook, April 1985.A. OSPF data formats 🎀
okay now we're in the appendix, and this part is the intro for the 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 first.
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. The OSPF Options field shows up in OSPF Hello packets, Database Description packets, and OSPF link state advertisements 💖
OSPF packet formats are detailed in Section A.3 📦 And a description of OSPF link state advertisements shows up in Section A.4 ✨
A.1 Encapsulation of OSPF packets ✨
okay so OSPF runs directly on top of the Internet Protocol's network layer 🌐 which means OSPF packets only get wrapped in IP and local data-link headers. no extra layers, very clean, very iconic 💅
OSPF doesn't have its own way to fragment packets 🙈 so when a packet is bigger than the network MTU it just relies on IP fragmentation. the big packet types (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several smaller protocol packets without losing any functionality 🫶 and that's the recommended move. IP fragmentation should be avoided whenever possible, bestie. with that in mind, we should try to keep packets sent over virtual links to 576 bytes. but if it's really necessary, an OSPF packet can be up to 65,535 bytes long (IP header included) 🧚
there are a few other super important features of OSPF's IP encapsulation:
- Use of IP multicast. some OSPF messages go out as multicast when they're sent over multi-access networks 🦋 two different IP multicast addresses get used here. these packets should never be forwarded, because they're only meant to travel a single hop. to make sure they don't wander off over multiple hops, their IP TTL must be set to 1.
- AllSPFRouters: this multicast address is 224.0.0.5. every router running OSPF should be ready to receive packets sent here. Hello packets always go to this destination, and certain OSPF protocol packets are sent here during the flooding procedure 🌸
- AllDRouters: this multicast address is 224.0.0.6. both the Designated Router and the Backup Designated Router need to be ready to receive packets sent to this address. certain OSPF protocol packets go here during the flooding procedure 💜
- Protocol number. OSPF is IP protocol number 89 🔥 that number was registered with the Network Information Center, and the IP protocol number assignments are documented in [RFC 1340].
- TOS. routing protocol packets are sent with an IP TOS of 0. the OSPF protocol does support TOS-based routing, so routes to a particular destination can vary based on TOS 👑 but all OSPF routing protocol packets are sent using the normal service TOS value of binary 0000 defined in [RFC 1349] 💅
- Precedence. routing protocol packets are sent with IP precedence set to Internetwork Control. OSPF protocol packets should get 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] can help make this happen 🎀
A.2 The Options field 🌈
the OSPF Options field shows up in OSPF Hello packets, Database Description packets, and all link state advertisements 💖 it's how OSPF routers say whether they support optional capabilities (or don't), and how they tell other OSPF routers what their capability level is. this is the magic that lets routers with different capabilities hang out together in one OSPF routing domain 🫶
in Hello packets, the Options field lets a router reject a neighbor because of a capability mismatch 🙅♀️ or, when capabilities get exchanged in Database Description packets, a router can choose not to forward certain link state advertisements to a neighbor because that neighbor has reduced functionality. and lastly, listing capabilities in link state advertisements lets routers route traffic around the reduced functionality routers by leaving them out of parts of the routing table calculation 🧠
two capabilities are defined right now 🦋 for each one, the effect of it showing up (or not showing up) in Hello packets, Database Description packets, and link state advertisements is spelled out below. like, the ExternalRoutingCapability (called the E-bit below) only has meaning in OSPF Hello packets. routers should reset (clear) the unassigned part of the capability field when they send Hello packets or Database Description packets, and when they originate link state advertisements ✨
more capabilities may get assigned in the future 👀 so if a router runs into an unrecognized capability in a received Hello packet, Database Description packet, or link state advertisement, it should ignore that capability and just process the packet or advertisement normally 💅
+-+-+-+-+-+-+-+-+
| | | | | | |E|T|
+-+-+-+-+-+-+-+-+
The Options field- T-bit: this describes the router's TOS capability. if the T-bit is reset, the router supports only a single TOS (TOS 0). that kind of router is also called incapable of TOS-routing, and elsewhere in this document it's referred to as a TOS-0-only router 🍓 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 that can't do TOS routing will be avoided as much as possible when forwarding data traffic that asks for a non-zero TOS 🙈 and the absence of the T-bit in a summary link advertisement or an AS external link advertisement means that the advertisement is describing a TOS 0 route only (not routes for non-zero TOS).
- E-bit: this bit reflects the associated area's ExternalRoutingCapability 🌸 AS external link advertisements are not flooded into or through OSPF stub areas (see Section 3.6). the E-bit makes sure all members of a stub area agree on that area's configuration. the E-bit is only meaningful in OSPF Hello packets. when the E-bit is reset in a Hello packet sent out a particular interface, it means the router will neither send nor receive AS external link state advertisements on that interface (basically, the interface connects to a stub area) 🫧 and 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 🎀 every single one begins with a standard 24 byte header, which gets described first. after that, each packet type gets its own section, where you can see how that packet is divided into fields and then read the field definitions 🧚
all OSPF packet types (except Hello packets) deal with lists of link state advertisements. for example, Link State Update packets are what carry the flooding of advertisements throughout the OSPF routing domain 🌈 which means OSPF protocol packets can't be parsed unless you also understand the format of link state advertisements. that format is described in Section A.4 💖
the receive processing of OSPF packets is detailed in Section 8.2, and 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 has all the info needed to decide whether the packet should be accepted for further processing. that decision 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 spec documents version 2 of the protocol 🍓
- Type: the OSPF packet types are below. each one's format is described in a succeeding section 💅
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment- Packet 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 a (potential) adjacency 🤝
- Area ID: a 32 bit number identifying the area this packet belongs to. all OSPF packets are associated with a single area, and most travel a single hop only. packets travelling over a virtual link are labelled with the backbone Area ID of 0.0.0.0 🌸
- Checksum: the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. it's calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excluding the authentication field. if the packet's length isn't an integral number of 16-bit words, the packet gets padded with a byte of zero before checksumming 🔢
- AuType: identifies the authentication scheme used for the packet. authentication is discussed in Appendix D of the specification, and that's where you'll find the list of currently defined authentication types 🔐
- Authentication: a 64-bit field for use by the authentication scheme 🫧
A.3.2 The Hello packet 🦋
okay so Hello packets are OSPF packet type 1 🎀 they get sent periodically on all interfaces (virtual links included) to establish and maintain neighbor relationships. On top of that, they get multicast on physical networks that have multicast or broadcast capability, so routers can dynamically discover their neighbors. main character energy for sure 💅
All routers on a common network have to agree on certain parameters: Network mask, HelloInterval and RouterDeadInterval. These parameters ride along in Hello packets, so if they don't match, neighbor relationships can't form 🙈 The receive processing for Hello packets is explained in Section 10.5, and the sending side 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network mask 🌸 This is the network mask for the interface. For example, if the interface points at a class B network whose third byte gets used for subnetting, the mask is 0xffffff00.
Options 💜 The optional capabilities the router supports, documented in Section A.2.
HelloInterval ⏱️ How many seconds between this router's Hello packets.
Rtr Pri 👑 This router's Router Priority, used when electing the (Backup) Designated Router. If it's set to 0, the router is not eligible to become the (Backup) Designated Router 💀
RouterDeadInterval 🫥 How many seconds pass before a silent router gets declared down.
Designated Router 🧚 The Designated Router for this network, as seen by the advertising router. It's identified by its IP interface address on the network. If there's no Designated Router, set it to 0.0.0.0.
Backup Designated Router 🍓 The Backup Designated Router for this network, as seen by the advertising router, also identified by its IP interface address on the network. If there isn't one, set it to 0.0.0.0.
Neighbor 🫶 The Router IDs of every router whose valid Hello packets have been seen recently on the network. "Recently" means within the last RouterDeadInterval seconds.
A.3.3 The Database Description packet 🌈
Database Description packets are OSPF packet type 2 ✨ They get exchanged when an adjacency is being initialized, and they describe the contents of the topological database. It can take several packets to describe the whole thing, so they use a poll-response procedure. One router is the master and the other is the slave. The master sends Database Description packets (the polls), and the slave answers with its own Database Description packets (the responses). The responses link back to the polls through the DD sequence numbers 🔥
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 |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |The format of the Database Description packet is super similar to the Link State Request and Link State Acknowledgment packets 🎀 All three are basically a list of items, and each item describes a piece of the topological database. Sending Database Description packets is documented in Section 10.8, and receiving them is documented in Section 10.6 💖
0 🫧 These fields are reserved. They must be 0.
Options 💜 The optional capabilities the router supports, 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 Description packets.
M-bit 🍑 The More bit. When it's set to 1, it means more Database Description packets are coming.
MS-bit 👑 The Master/Slave bit. When it's set to 1, the router is the master during the Database Exchange process. Otherwise, the router is the slave.
DD sequence number 🔢 Used to sequence the collection of Database Description packets. The initial value (the one marked by the Init bit being set) should be unique. After that, the DD sequence number increments until the whole database description has been sent.
The rest of the packet is a (possibly partial) list of the topological database's pieces. Each link state advertisement in the database is described by its link state advertisement 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 🌸 After a router swaps Database Description packets with a neighbor, it might notice that parts of its topological database are out of date. That's where the Link State Request packet comes in: it asks the neighbor for the pieces that are more up to date. You might need several of these packets. Sending Link State Request packets is the last step in bringing up an adjacency, so it's kind of the finale 🎉
A router that sends a Link State Request packet has a specific instance of each database piece in mind. That instance is defined by LS sequence number, LS checksum, and LS age, even though those fields aren't actually in the Link State Request packet itself. The router might end up getting even newer instances back 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 advertisement being requested is specified by its LS type, Link State ID, and Advertising Router 🧚 Those three together uniquely identify the advertisement, but not its instance. So Link State Request packets are understood as 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, and they're the ones doing the flooding of link state advertisements 🚀. Each one carries a bundle of link state advertisements, each one hop further away from where it started, and a single packet can hold several advertisements at once 💅.
On physical networks that support multicast or broadcast, these packets get multicast 📡. To make flooding reliable, the flooded advertisements get acknowledged in Link State Acknowledgment packets 🫶. If some advertisements need to be sent again, the retransmitted ones always travel in unicast Link State Update packets 💌. Want the full tea on reliable flooding? Go read 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 🔢 This is how many link state advertisements are packed into this update.
The body of a Link State Update packet is a list of link state advertisements 📦. Every advertisement kicks off with the same 20 byte header, the link state advertisement header 🎀, which you can read about in Section A.4.1. After that, each of the five types of link state advertisement has its own format, and those are all covered in Section A.4 🦋.
A.3.6 The Link State Acknowledgment packet 🌸
Link State Acknowledgment packets are OSPF packet type 5 🫧. To keep flooding reliable, flooded advertisements get explicitly acknowledged, and that happens by sending and receiving these packets 🤝. One Link State Acknowledgment packet can acknowledge multiple link state advertisements at once 🙌.
Where the acknowledgment goes depends on the state of the sending interface and where the advertisements came from 🗺️. It's either sent to the multicast address AllSPFRouters, sent to the multicast address AllDRouters, or sent as a unicast. Sending these is documented in Section 13.5, and receiving them is documented in Section 13.7 💖.
The format is pretty similar to the Data Description packet 👯. In both, the body is just a list of link state advertisement headers 💜.
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 advertisement is described by its link state advertisement header 🏷️. That header is documented in Section A.4.1 and holds everything needed to uniquely identify both the advertisement and its current instance 🕵️♀️✨.
A.4 Link state advertisement formats 💎
There are five distinct types of link state advertisements 🌈. Every one starts with the standard 20-byte link state advertisement header, which is explained in Section A.4.1 📋. The sections after that diagram each of the separate types 🎨.
Each link state advertisement describes a piece of the OSPF routing domain 🗺️. Every router originates a router links advertisement 🖥️. On top of that, whenever a router gets elected Designated Router, it also originates a network links advertisement 👑. Other types can be originated too (see Section 12.4) 🍓. All of them then get flooded throughout the OSPF routing domain 🌊. The flooding algorithm is reliable, which means every router ends up with the same collection of link state advertisements (see Section 13 for more on the flooding algorithm) 🤞. This collection is called the link state (or topological) database 🗃️.
From the link state database, each router builds a shortest path tree with itself as the root 🌳. That gives you a routing table (see Section 11) 🛣️. For the nitty-gritty of how the routing table gets built, see Section 16 💅.
A.4.1 The Link State Advertisement header 🎀
All link state advertisements begin with a common 20 byte header 🧁. This header has enough info to uniquely identify the advertisement: the LS type, the Link State ID, and the Advertising Router 🔑. Multiple instances of the same advertisement can exist in the routing domain at once 👯♀️, so you need a way to tell which one is newer 🤔. That's handled by looking at the LS age, LS sequence number and LS checksum fields, which also live in this 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 its own 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 the advertisement is describing 🌐. What goes in here depends 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 (and the network's IP address can be derived from that) 👑. The Link State ID gets more discussion 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 🔢 This detects old or duplicate link state advertisements 🕰️. Successive instances of a link state advertisement get 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. That includes the link state advertisement header but skips the LS age field. 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 advertisement header 🫶.
A.4.2 Router links advertisements
Okay, router links advertisements are the Type 1 link state advertisements, and they're so important 💅. Every router in an area originates one. It describes the state and cost of the router's links (aka interfaces) to that area. ALL of the router's links to the area have to be described in a single router links advertisement, no exceptions 🫶. If you want the nitty gritty on how to build these, check out Section 12.4.1 🎀.
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 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | TOS 0 metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Now the juicy bit ✨. In router links advertisements, the Link State ID is set to the router's OSPF Router ID 🌸. The T-bit gets set in the advertisement's Option field if and only if the router can calculate a separate set of routes for each IP TOS 🔥. And these advertisements only get flooded throughout a single area. Just one area, bestie 🦋.
bit V When this is set, the router is an endpoint of an active virtual link that's using the described area as a Transit area. (V is for virtual link endpoint 🧚.)
bit E When this is set, the router is an AS boundary router. (E is for external 👑.)
bit B When this is set, the router is an area border router. (B is for border 🍓.)
# links This is the number of router links described by this advertisement. It's the total collection of router links (aka interfaces) to the area, so it has to be complete 💖.
Each router link gets described by the fields below, and every link has a Type 🎀. The Type field tells you what kind of link it is. It could be a link to a transit network, to another router, or to a stub network 🌈. Here's the tea: the values of all the other fields depend on the link's Type. Every link has a 32-bit data field, and for links to stub networks, that field holds the network's IP address mask. For all the other link types, Link Data holds the router's associated IP interface address 🫶.
Type A quick description of the router link, and it's one of the following. Host routes count as links to stub networks whose network mask is 0xffffffff, so keep that in mind 🙈.
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 This identifies the object that this router link connects to, and its value depends on the link's Type 🧚. When the link connects to an object that also originates a link state advertisement (so another router or a transit network), the Link ID equals the neighboring advertisement's Link State ID. That's the key for looking that advertisement up in the link state database 🔑. Check Section 12.2 for more details.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router IDLink Data The contents depend on the link's Type field again 💅. For connections to stub networks, it specifies the network's IP address mask. For unnumbered point-to-point connections, it specifies the interface's MIB-II [RFC 1213] ifIndex value. For the other link types, it specifies the router's associated IP interface address. That last piece of info is needed during the routing table build process, when you're calculating the IP address of the next hop 🦋. See Section 16.1.1 for more details.
# TOS This is the number of different TOS metrics given for this link, NOT counting the required metric for TOS 0 🌸. So 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 💖.
Each link can have separate metrics for each Type of Service (TOS) ✨. The metric for TOS 0 must always be included (we already talked about it above 💜). Metrics for non-zero TOS get described below. The encoding of TOS in OSPF link state advertisements is in Section 12.3 🎀. And if a non-zero TOS value isn't specified, its cost defaults to the TOS 0 cost, so no stress there 🫶. The 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 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 transit network vibes 🦋. You get one of these for each transit network in the area. A transit network is a multi-access network with more than one attached router 🧚. The Designated Router of that network is the one who originates the network links advertisement 👑. It describes ALL the routers attached to the network, Designated Router included. And 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 🍓. That's why the TOS and metric fields don't need to be specified in the network links advertisement 🫶. For the full build details, 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 The IP address mask for the network. For example, a class A network would have the mask 0xff000000 🌸.
Attached Router The Router IDs of each of the routers attached to the network 🧚. Actually, only the routers that are fully adjacent to the Designated Router get listed. The Designated Router includes itself in this list 🫶. The number of routers included can be deduced from the link state advertisement header's length field 💜.
A.4.4 Summary link advertisements ✨
Okay bestie, summary link advertisements are the Type 3 and 4 link state advertisements 🦋 They get originated by area border routers, and each router makes a separate one for every destination it knows about that belongs to the AS but sits outside the area. For how to actually build them, check out Section 12.4.3 📖
Type 3 is used when the destination is an IP network. The Link State ID is that IP network number (and if needed, it can also have one or more of the network's "host" bits set, which Appendix F explains 🌸). When the destination is an AS boundary router, you use Type 4 instead, and the Link State ID is that ASBR's OSPF Router ID. Wondering why we need to advertise where every ASBR lives? Section 16.4 has the tea 🍵 Other than the Link State ID, Type 3 and 4 are formatted exactly the same 💅
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |For stub areas, Type 3 summaries can also describe a per-area default route 🧚 Stub areas use default summary routes instead of flooding a full set of external routes. When you're describing a default summary 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 can be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is in Section 12.3. Note that the cost for TOS 0 must be included, and it's always listed first 🎀 If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described. Otherwise, routes for the other TOS values are described too. If a cost for a certain TOS isn't included, its cost defaults to whatever was specified for TOS 0.
Network Mask For Type 3 link state advertisements, this is the destination network's IP address mask. For example, for a class A network you'd use 0xff000000 💖 For Type 4, this field isn't meaningful and must be zero.
For each specified Type of Service, the following fields are defined. The number of TOS routes included can be worked out from the link state advertisement header's length field. Values for TOS 0 must be specified and get listed first. Everything else goes in order of increasing TOS encoding. For example, the cost for TOS 16 must always come after the cost for TOS 8 when both are specified 🌈
TOS The Type of Service that the following cost is about. The encoding is 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, and AS boundary routers are the ones who originate them. Each destination that's external to the AS (and known to the router) gets its own advertisement. For how these get built, see Section 12.4.3 🦋
These usually describe one particular external destination. For these, the Link State ID field holds an IP network number (and again, if needed, it can have one or more of the network's "host" bits set; see Appendix F 🌸). AS external link advertisements are also used to describe a default route, which comes into play when there's no specific route to the destination. For a default route, the Link State ID is always DefaultDestination (0.0.0.0) and the Network Mask is 0.0.0.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Separate costs can be advertised for each IP Type of Service. The encoding of TOS in OSPF link state advertisements is in Section 12.3. Note that the cost for TOS 0 must be included, and it's always listed first 💅 If the T-bit is reset in the advertisement's Option field, only a route for TOS 0 is described. Otherwise, the other TOS values get described too. If a cost for a certain TOS isn't included, it defaults to the TOS 0 cost.
Network Mask The IP address mask for the advertised destination. For example, for a class A network you'd use the mask 0xff000000 🌸
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 header's length field. Values for TOS 0 must be specified and get listed first. Everything else goes 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 is a Type 2 external metric, which means it's considered larger than any link state path 😭 If bit E is zero, the metric is a Type 1 external metric, which means it's comparable directly (without translation) to the link state metric 💜
Forwarding address Data traffic for the advertised destination gets forwarded to this address. If the Forwarding address is 0.0.0.0, the traffic gets forwarded to the advertisement's originator instead, which is the responsible AS boundary router 🧚
TOS The Type of Service that the following cost is about. The encoding is in Section 12.3.
metric The cost of this route. What it means depends on the external type indication (bit E above) 🔥
External Route Tag A 32-bit field attached to each external route. The OSPF protocol doesn't use it itself. It may be used to pass information between AS boundary routers, but the precise nature of that information is outside the scope of this specification 🫶
B. Architectural Constants 💖
okay bestie, so OSPF has a bunch of fixed architectural values 🧚 The spec refers to them by names like LSRefreshTime, and the configurable knobs follow the same naming style. Those are defined in Appendix C. Each constant below comes with its name, its value, and what it does ✨
LSRefreshTime
This is the maximum time between distinct originations of any particular link state advertisement 🔁 When the LS age field of one of the router's self-originated advertisements reaches LSRefreshTime, a new instance of that advertisement gets originated, even though the contents (apart from the link state header) stay the same. LSRefreshTime is set to 30 minutes ⏰
MinLSInterval
This is the minimum time between distinct originations of any particular link state advertisement. MinLSInterval is set to 5 seconds 🌸
MaxAge
This is the maximum age a link state advertisement can reach. When an advertisement's LS age field hits MaxAge, it gets reflooded to try to flush it out of the routing domain (see Section 14) 🧹 Advertisements of age MaxAge are not used in the routing table calculation. The value of MaxAge must be greater than LSRefreshTime. MaxAge is set to 1 hour 🕐
CheckAge
When the age of a link state advertisement sitting in the link state database hits a multiple of CheckAge, its checksum gets verified. An incorrect checksum at that moment indicates a serious error 🚨 CheckAge is set to 5 minutes.
MaxAgeDiff
This is the maximum time dispersion that can happen while a link state advertisement is flooded throughout the AS 🌊 Most of that time is spent with the advertisements sitting on router output queues, which means they aren't aging during the flood. MaxAgeDiff is set to 15 minutes.
LSInfinity
This is the metric value meaning the destination described by a link state advertisement is unreachable 🙅♀️ It's used in summary link advertisements and AS external link advertisements as an alternative to premature aging (see Section 14.1). It's defined as the 24-bit binary value of all ones, which is 0xffffff.
DefaultDestination
This is the Destination ID that indicates the default route 🛣️ The default 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 stub areas' type 3 summary link advertisements. Its value is the IP address 0.0.0.0.
C. Configurable Constants 🎀
okay so OSPF has quite a few configurable parameters 💅 They're grouped into general functional categories (area parameters, interface parameters, and so on), and 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 decided by router algorithms outside of this specification (for example, the address of a host connected to the router over a SLIP line). From OSPF's point of view, these items are still configurable ✨
C.1 Global parameters
Normally a separate copy of the OSPF protocol runs for each area, so most configuration parameters are defined per area. The few global ones are listed below 🌈
Router ID
This is a 32-bit number that uniquely identifies the router in the Autonomous System 🪪 One way to assign a Router ID is to pick 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. Before restarting to change its Router ID, the router should flush its self-originated link state advertisements from the routing domain (see Section 14.1). Otherwise they'll persist for up to MaxAge minutes 😭
TOS capability
This item says whether the router will calculate separate routes based on TOS 🍓 For more information, 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 between them can't form, and that gets in the way of both routing protocol traffic and data traffic 💀 The following items must be configured for an area:
Area ID
This is a 32-bit number that identifies the area 🆔 The Area ID of 0.0.0.0 is reserved for the backbone. If the area represents a subnetted network, the IP network number of that subnetted network may be used as the Area ID.
List of address ranges
An OSPF area is defined as a list of address ranges 🗺️ Each address range consists of the following items:
[IP address, mask]
This describes the collection of IP addresses contained in the address range. Networks and hosts are assigned to an area depending on whether their addresses fall into one of the area's defining address ranges. Routers are viewed as belonging to multiple areas, depending on their attached networks' area membership.
Status
This is set to either Advertise or DoNotAdvertise 🙈 Routing information gets condensed at area boundaries. Outside the area, at most a single route is advertised (via a summary link advertisement) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges let you intentionally hide the existence of certain networks from other areas 🫣 Status is set to Advertise by default.
As an example, suppose an IP subnetted network is going to be its own OSPF area 🧁 The area would be configured as a single address range, whose IP address is the address of the subnetted network, and whose mask is the natural class A, B, or C address mask. A single route would be advertised outside the area, describing the entire subnetted network.
AuType
Each area can be configured with a separate type of authentication 🔐 See Appendix D for a discussion of the defined authentication types.
ExternalRoutingCapability
This controls 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. 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 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.
C.3 Router interface parameters
Some of the configurable router interface parameters (like the IP interface address and subnet mask) actually imply properties of the attached networks 🧩 That means they must be consistent across all the routers attached to that network. The parameters that must be configured for a router interface are:
IP interface address
This is the IP protocol address for this interface 📍 It uniquely identifies the router over the entire internet. An IP address is not required on serial lines. A serial line like that is called "unnumbered" 🧷
IP interface mask
Also called the subnet mask, this indicates the portion of the IP interface address that identifies the attached network 🎭 Masking the IP interface address with the IP interface mask yields the IP network number of the attached network. On point-to-point networks and virtual links, the IP interface mask is not defined. On those networks, the link itself isn't assigned an IP network number, so the addresses on each side of the link are assigned independently, if they're assigned at all.
Interface output cost(s)
This 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
This 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. It should be well over the expected round-trip delay between any two routers on the attached network. Keep the setting conservative, or you'll get needless retransmissions 🙄 It will need to be larger on low speed serial lines and virtual links. Sample value for a local area network: 5 seconds.
InfTransDelay
This is the estimated number of seconds it takes to transmit a Link State Update Packet over this interface 🚚 Link state advertisements contained 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 of the interface. It must be greater than 0. Sample value for a local area network: 1 second ⚡
Router Priority
This 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 is only configured for interfaces to multi-access networks.
okay so bestie, the HelloInterval is the gap between each Hello Packet the router sends on an interface 💌 It gets advertised inside those Hello Packets too, and it has to match on every router sharing a common network 🫶 Lowkey the smaller it is, the faster topology changes get spotted, but ngl that means more OSPF routing protocol traffic 🔥 Sample values: 30 seconds for an X.25 PDN network, and 10 seconds for a local area network ✨
RouterDeadInterval is how long neighbors wait after they stop hearing a router's Hello Packets before they declare it down 💀 That number is also advertised in the router's Hello Packets, in the RouterDeadInterval field 🎀 It should be some multiple of the HelloInterval (say 4), and yep, it has to match across every router on a common network too 💅
Authentication key is the configured data that lets the authentication procedure generate and/or verify the authentication field in the OSPF header 🔐 It also has to be the same for every router on a common network 🌸 For example, if the AuType says simple password, the Authentication key is a 64-bit password, inserted straight into the OSPF header whenever routing protocol packets get originated 🦋 Each network can have its own password, so no one-size-fits-all vibes here 👑
C.4 Virtual link parameters
Virtual links exist to restore or boost connectivity of the backbone 🧚 You can configure them between any pair of area border routers that have interfaces to a common (non-backbone) area 💜 In the backbone graph, the virtual link shows up as an unnumbered point-to-point link ✨ And it MUST be configured in both of the area border routers 🙈
Okay wait, I need to fix that: the original word is "must", lowercase, so it reads: the virtual link must be configured in both of the area border routers 🙈
A virtual link shows up in router links advertisements (for the backbone) as if it were a separate router interface to the backbone 🦋 So it has all the parameters a router interface has (see Section C.3) 🫶 Even though it acts like an unnumbered point-to-point link, it still has an associated IP interface address 🌈 That address is the IP source in the OSPF protocol packets it sends along the virtual link, and it gets set dynamically during the routing table build process 💖 Interface output cost on virtual links is also set dynamically, to the cost of the intra-area path between the two routers 🍓 The parameter RxmtInterval must be configured, and 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 😭 Router Priority is not used on virtual links 💅
A virtual link is defined by two configurable parameters: the Router ID of the virtual link's other endpoint, and the (non-backbone) area the virtual link runs through, called the virtual link's Transit area 🎀 Virtual links cannot be configured through stub areas 🚫
C.5 Non-broadcast, multi-access network parameters
OSPF treats a non-broadcast, multi-access network pretty much like a broadcast network 🌸 Since lots of routers might be attached, a Designated Router gets selected for the network 👑 That Designated Router then originates a networks links advertisement, which lists all routers attached to the non-broadcast network ✨
Because there's no broadcast capability, configuration parameters are needed for the Designated Router selection 💅 These only need to be configured in routers that are themselves eligible to become Designated Router (i.e., those router's whose Router Priority for the network is non-zero) 🦋
List of all other attached routers 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, and for each one, its eligibility to become Designated Router must be defined 🫶 When an interface to a non-broadcast network comes up, the router only sends Hello Packets to neighbors eligible to become Designated Router, until it discovers who the Designated Router is 🧚
PollInterval covers the case where a neighboring router has gone inactive (no Hello Packets seen for RouterDeadInterval seconds) 💀 It may still be necessary to send Hello Packets to that dead neighbor anyway 🙈 Those go out at the reduced rate 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 router links advertisements as stub networks with mask 0xffffffff 🎀 They can indicate router interfaces to point-to-point networks, looped router interfaces, or IP hosts directly connected to the router (e.g., via a SLIP line) 🌈 For each host directly connected to the router, the following items must be configured:
Host IP address is just the IP address of the host 🏠
Cost of link to host is the cost of sending a packet to the host, in terms of the link state metric 💜 There can be multiple costs configured, one for each IP TOS 🍓 But since the host probably has only a single connection to the internet, the configured cost(s) are often unimportant (i.e., they will have no effect on routing) 🤷♀️
D. 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 whatever authentication scheme the type field picks 💖
The authentication type is configurable on a per-area basis 🌸 Extra authentication data is configurable on a per-interface basis 🦋 So if an area uses a simple password scheme, a separate password can be configured for each network in that 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 is in Table 20 below 📋
AuType Description
___________________________________________
0 No authentication
1 Simple password
All others Reserved for assignment by the
IANA (iana@ISI.EDU)
Table 20: OSPF authentication types.D.1 AuType 0 -- No authentication
With this authentication type, routing exchanges in the area aren't authenticated 🙃 The 64-bit field in the OSPF header can contain anything, and it isn't examined on packet reception 🫠
D.2 AuType 1 -- Simple password
With this type, a 64-bit field is configured on a per-network basis 🔑 All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field 🎀 Basically it's a "clear" 64-bit password 🪪
This guards against routers accidentally joining the area 🚧 They have to be configured with their attached networks' passwords first before they can take part in the routing domain 💅
E. Differences from RFC 1247
This section documents the differences between this memo and RFC 1247 📚 They include a fix for a problem with OSPF virtual links, plus minor enhancements and clarifications to the protocol 🦋 Every difference is backward-compatible, so implementations of this memo and of RFC 1247 will interoperate 🫶
E.1 A fix for a problem with OSPF Virtual links
In RFC 1247, certain configurations of OSPF virtual links can cause routing loops 😱 The root of the problem is that while there's an information mismatch at the boundary of any virtual link's Transit area, a backbone path can still cross that boundary 💀 RFC 1247 tried to compensate by adjusting any backbone path as it enters the transit area (see Section 16.3 in RFC 1247) 🙈 But that wasn't enough 😤 This memo fixes it by having all area border routers determine, by looking at summary links, whether better backbone paths can be found through the transit areas 👑
This fix simplifies the OSPF virtual link logic and has these components:
- A new bit has been defined in the router links advertisement, called bit V. Bit V is set in a router's router links advertisement for Area A if and only if the router is an endpoint of an active virtual link that uses Area A as its Transit area (see Sections 12.4.1 and A.4.2) ✨ This lets the other routers attached to Area A discover whether the area supports any virtual links (i.e., is a transit area) 🔍 That discovery happens during the calculation of Area A's shortest-path tree (see Section 16.1) 🌳
- To help describe the algorithm, a new parameter has been added to the OSPF area structure: TransitCapability 🧠 It indicates whether the area supports any active virtual links, or equivalently, whether the area can carry traffic that neither originates nor terminates in the area itself 🚚
- The calculation in Section 16.3 of RFC 1247 has been replaced 🔄 The new calculation, performed by area border routers only, examines the summary links belonging to all attached transit areas to see whether they can provide better paths than the ones already found in Sections 16.1 and 16.2 🏆
- The incremental calculations in Section 16.5 have been updated because of the new calculations in Section 16.3 🆙
E.2 Supporting supernetting and subnet 0
In RFC 1247, an OSPF router can't originate separate AS external link advertisements (or separate summary link advertisements) for two networks that have the same address but different masks 🙅♀️ This can happen when subnet 0 of a network has been assigned (a practice that's generally discouraged), when using supernetting as described in [RFC 1519] (a practice that's generally encouraged to shrink routing tables), or even when transitioning from one mask to another on a subnet 🌀 For supernetting, say you want to aggregate the four class C networks 192.9.4.0-192.9.7.0, advertising one route for the aggregation and another for the single class C network 192.9.4.0 🍰
The reason behind this limitation is that in RFC 1247, the Link State ID of AS external link advertisements and summary link advertisements is set equal to the described network's IP address 🎀. In the example above, RFC 1247 would give both advertisements a Link State ID of 192.9.4.0, which makes them basically the same advertisement 🙈. This memo fixes that by relaxing how the Link State ID gets set, so any of the "host" bits of the network address can also be set. That lets you tell apart advertisements for networks that share an address but have different masks ✨. Given an AS external link advertisement (or a summary link advertisement), you can now find the described network's address by masking the Link State ID with the network mask carried in the body of the advertisement. Using the same example again, the aggregate can now be advertised with a Link State ID of 192.9.4.0, while the single class C network is advertised at the same time with a Link State ID of 192.9.4.255 💖.
Appendix F gives one possible algorithm for setting one or more "host" bits in the Link State ID to disambiguate advertisements 🧚. It's worth noting that this is a local decision. Each router in an OSPF system is free to use its own algorithm, since only those advertisements originated by the router itself are affected 🦋.
It is believed that this change will be more or less compatible with implementations of RFC 1247 🌸. Implementations of RFC 1247 will probably either a) install routing table entries that won't be used, or b) do the correct processing as outlined in this memo, or c) mark the advertisement as unusable when presented with a Link State ID that has one or more of the host bits set 👀. However, in the interest of interoperability, implementations of this memo should only set the host bits in Link State IDs when absolutely necessary 🫶.
The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3, 16.4, 16.5, 16.6, A.4.4 and A.4.5 💅.
E.3 Obsoleting LSInfinity in router links advertisements ✨
The metric of LSInfinity can no longer be used in router links advertisements to indicate unusable links 🚫. This is being done for several reasons:
- It removes any possible confusion in an OSPF area about exactly which routers and networks are reachable in the area 🧐. For example, the above virtual link fix relies on detecting the existence of virtual links when running the Dijkstra. However, when one-directional links (i.e., cost of
LSInfinityin one direction, but not the other) are possible, some routers may detect the existence of virtual links while others may not. That could defeat the fix for the virtual link problem 😭. - It also helps OSPF's Multicast routing extensions (MOSPF), because one-way reachability can lead to places that are reachable via unicast but not multicast, or vice versa 🌈.
The two prior justifications for using LSInfinity in router links advertisements were 1) it was a way to not support TOS before TOS was optional, and 2) it went along with strong TOS interpretations. Those justifications are no longer valid 💀. However, LSInfinity will continue to mean "unreachable" in summary link advertisements and AS external link advertisements, since some implementations use this as an alternative to the premature aging procedure specified in Section 14.1 🌸.
This change has one other side effect. When two routers are connected via a virtual link whose underlying path is non-TOS-capable, they must now revert to being non-TOS-capable routers themselves 🙃. Previously they advertised the non-zero TOS costs of the virtual link as LSInfinity. See Section 15 for details 🔍.
E.4 TOS encoding updated 🍓
The encoding of TOS in OSPF link state advertisements has been updated to reflect the new TOS value (minimize monetary cost) defined by [RFC 1349] 💜. The OSPF encoding is defined in Section 12.3, which is identical in content to Section A.5 of [RFC 1349] 📚.
E.5 Summarizing routes into transit areas 🦋
RFC 1247 mandated that routes associated with Area A are never summarized back into Area A 🚧. This memo goes further and reduces the number of summary links originated by refusing to summarize into Area A those routes having next hops that belong to Area A 🌷. This is an optimization over RFC 1247 behavior when virtual links are present.
For example, in the area configuration of Figure 6, Router RT11 need only originate a single summary link having the (collapsed) destination N9-N11,H1 into its connected transit area, Area 2 🧩. That's because all of its other eligible routes have next hops belonging to Area 2, so they only need to be advertised by other area border routers. In this case, those are Routers RT10 and RT7 💖. This is the logical equivalent of a Distance Vector protocol's split horizon logic 🙌.
This change appears in Section 12.4.3 ✨.
E.6 Summarizing routes into stub areas 🌈
RFC 1247 mandated that area border routers attached to stub areas must summarize all inter-area routes into the stub areas 📦. However, while area border routers connected to OSPF stub areas must originate default summary links into the stub area, they need not summarize other routes into it 🙌. The amount of summarization done into stub areas can instead be put under configuration control 🎛️. That means the network administrator can make the trade-off between optimal routing and database size 🧠.
This change appears in Sections 12.4.3 and 12.4.4 💅.
E.7 Flushing anomalous network links advertisements 🧹
Text was added indicating that a network links advertisement whose Link State ID is equal to one of the router's own IP interface addresses should be considered self-originated, regardless of the setting of the advertisement's Advertising Router 🪞. If the Advertising Router of such an advertisement is not equal to the router's own Router ID, the advertisement should be flushed from the routing domain using the premature aging procedure specified in Section 14.1 🗑️. This case should be rare, and it indicates that the router's Router ID has changed since the advertisement was originated 🔄.
Failure to flush these anomalous advertisements could lead to multiple network links advertisements having the same Link State ID 😱. This in turn could cause the Dijkstra calculation in Section 16.1 to fail, since it would be impossible to tell which network links advertisement is valid (i.e., more recent) 💀.
This change appears in Sections 13.4 and 14.1 ✨.
E.8 Required Statistics appendix deleted 👋
Appendix D of RFC 1247, which specified a list of required statistics for an OSPF implementation, has been deleted 🫥. That appendix has been superseded by two documents: the OSPF Version 2 Management Information Base and the OSPF Version 2 Traps 📖.
E.9 Other changes 🎀
The following small changes were also made to RFC 1247 🌸:
- When representing unnumbered point-to-point networks in router links advertisements, the corresponding Link Data field should be set to the unnumbered interface's MIB-II [RFC 1213]
ifIndexvalue 🔢. - A comment was added to Step 3 of the Dijkstra algorithm in Section 16.1 📝. When removing vertices from the candidate list, and when there is a choice of vertices closest to the root, network vertices must be chosen before router vertices in order to necessarily find all equal-cost paths 🛤️.
- A comment was added to Section 12.4.3 noting that a summary link advertisement cannot express a reachable destination whose path cost equals or exceeds
LSInfinity🚫. - A comment was added to Section 15 noting that a virtual link whose underlying path has cost greater than hexadecimal
0xffff(the maximum size of an interface cost in a router links advertisement) should be considered inoperational 🔧. - An option was added to the definition of area address ranges, letting the network administrator specify that a particular range should not be advertised to other OSPF areas 🕵️. This enables the existence of certain networks to be hidden from other areas. This change appears in Sections 12.4.3 and C.2 🦋.
- A note was added reminding implementors that bit E (the AS boundary router indication) should never be set in a router links advertisement for a stub area, since stub areas cannot contain AS boundary routers 🙅. This change appears in Section 12.4.1 💖.
F. An algorithm for assigning Link State IDs ✨
okay bestie, so in RFC 1247 the Link State ID in AS external link advertisements and summary link advertisements was just the described network's IP address 💅. this memo loosens that up: one or more of the network's host bits can now be set in the Link State ID 🦋. why? it lets a router originate separate advertisements for networks that have the same address but different masks. this can happen with supernetting and subnet 0s (see Section E.2 for more info) 🌸
this appendix gives one possible algorithm for setting those host bits. picking an algorithm is a local decision, so different routers can use different ones 🫶. the only advertisements affected are the ones the router itself originates. the one real rule: use the network's IP address as the Link State ID (the RFC 1247 behavior) whenever possible ✨
the algorithm is written for AS external link advertisements, just for clarity. the exact same thing works for summary link advertisements 💖. say the router wants to originate an AS external link advertisement for a network with address NA and mask NM1. here's how it figures out the Link State ID:
- Check whether the router is already originating an AS external link advertisement with Link State ID equal to
NA(in that advertisement, the router itself is listed as the Advertising Router). If not, set the Link State ID toNA(the RFC 1247 behavior) and the algorithm is done. Otherwise, - Grab the network mask from the body of the already existing AS external link advertisement and call it
NM2. There are then two cases:NM1is longer (more specific) thanNM2. Set the Link State ID in the new advertisement to the network[NA,NM1]with all the host bits set. That meansNAOR'ed together with all the bits that are not set inNM1, which is network[NA,NM1]'s broadcast address.NM2is longer thanNM1. Change the existing advertisement (the one with Link State IDNA) to reference the new network[NA,NM1]by incrementing the sequence number, changing the mask in the body toNM1, and using the cost for the new network. Then originate a new advertisement for the old network[NA,NM2], with Link State ID equal toNAOR'ed together with the bits that are not set inNM2(aka network[NA,NM2]'s broadcast address).
the algorithm assumes all masks are contiguous 🧩. that way, when two networks have the same address, one mask is always more specific than the other. it also assumes no network exists with an address equal to another network's broadcast address. with those two assumptions, the algorithm always produces unique Link State IDs ✨
there's also a reworded version. when originating an AS external link state advertisement, try to use the network number as the Link State ID. if that causes a conflict, look at the two networks in conflict. one will be a subset of the other. the less specific network keeps the network number as its Link State ID, and the more specific one uses its broadcast address instead (flip all the "host" bits to 1). if the most specific network was originated first, this will cause you to originate two link state advertisements at once 😭
that double-origination moment is giving chaos, so keep this part in mind!
here's an example of the algorithm in action, when this sequence happens in a single router (Router A) 🎀
(1) Router A wants to originate an AS external link advertisement
for [10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS external link
advertisement for [10.0.0.0,255.255.0.0]:
(a) The advertisement for [10.0.0,0,255.255.255.0] is
reoriginated using a new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS external link
advertisement for [10.0.0.0,255.0.0.0]:
(a) The advertisement for [10.0.0.0,255.255.0.0] is reoriginated
using a new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.Security Considerations 🔐
okay this part is SERIOUS 😤. every single OSPF protocol exchange gets authenticated. that's handled by the authentication fields sitting in the OSPF packet header 🛡️. for the full story, check out Sections 8.1, 8.2, and Appendix D 🔥
Author's Address 🧚
this is where you can reach the author, John Moy 💜
John Moy
Proteon, Inc.
9 Technology Drive
Westborough, MA 01581
Phone: 508-898-2800
Fax: 508-898-3176
Email: jmoy@proteon.comand that's the whole RFC, bestie!! 🌈💅✨
📦 where this page comes from
- ietf: rfc1583 1994-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms