RFC 2328
OSPF Version 2
Part 1 of 45 🌷
RFC 2328: OSPF Version 2 🌸
okay bestie, this is RFC 2328, and it's called OSPF Version 2 💅 It was written by J. Moy at Ascend Communications, Inc., and it came out in April 1998. It's a Standards Track document in the STD 54 series, and it obsoletes RFC 2178. The header doesn't list anything it updates. ✨
Status of This Memo ✨
so this document specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And distribution of this memo is unlimited 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (1998). All Rights Reserved. 🌈
Abstract 🧚
okay so this memo documents version 2 of the OSPF protocol 🍓 OSPF is a link-state routing protocol, and it's designed to be run internal to a single Autonomous System. Every OSPF router keeps an identical database describing that Autonomous System's topology, and from that database a routing table gets calculated by constructing a shortest-path tree 🌳
OSPF recalculates routes quickly when the topology changes, and it does it while using a minimum of routing protocol traffic ⚡ It provides support for equal-cost multipath 🛤️ An area routing capability is also provided, which gives an extra level of routing protection and cuts down on routing protocol traffic 🛡️ And, the big one, all OSPF routing protocol exchanges are authenticated 🔐 main character behavior, honestly 👑
The differences between this memo and RFC 2178 are explained in Appendix G 📖 All of those differences are backward-compatible in nature 💖
Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate 🤝
Please send comments to ospf@gated.cornell.edu 📬 ✨
Table of Contents
1 Introduction ........................................... 6
1.1 Protocol Overview ...................................... 6
1.2 Definitions of commonly used terms ..................... 8
1.3 Brief history of link-state routing technology ........ 11
1.4 Organization of this document ......................... 12
1.5 Acknowledgments ....................................... 12
2 The link-state database: organization and calculations 13
2.1 Representation of routers and networks ................ 13
2.1.1 Representation of non-broadcast networks .............. 15
2.1.2 An example link-state database ........................ 18
2.2 The shortest-path tree ................................ 21
2.3 Use of external routing information ................... 23
2.4 Equal-cost multipath .................................. 26
3 Splitting the AS into Areas ........................... 26
3.1 The backbone of the Autonomous System ................. 27
3.2 Inter-area routing .................................... 27
3.3 Classification of routers ............................. 28
3.4 A sample area configuration ........................... 29
3.5 IP subnetting support ................................. 35
3.6 Supporting stub areas ................................. 37
3.7 Partitions of areas ................................... 38
4 Functional Summary .................................... 40
4.1 Inter-area routing .................................... 41
4.2 AS external routes .................................... 41
4.3 Routing protocol packets .............................. 42
4.4 Basic implementation requirements ..................... 43
4.5 Optional OSPF capabilities ............................ 46
5 Protocol data structures .............................. 47
6 The Area Data Structure ............................... 49
7 Bringing Up Adjacencies ............................... 52
7.1 The Hello Protocol .................................... 52
7.2 The Synchronization of Databases ...................... 53
7.3 The Designated Router ................................. 54
7.4 The Backup Designated Router .......................... 56
7.5 The graph of adjacencies .............................. 56
8 Protocol Packet Processing ............................ 58
8.1 Sending protocol packets .............................. 58
8.2 Receiving protocol packets ............................ 61
9 The Interface Data Structure .......................... 63
9.1 Interface states ...................................... 67
9.2 Events causing interface state changes ................ 70
9.3 The Interface state machine ........................... 72
9.4 Electing the Designated Router ........................ 75
9.5 Sending Hello packets ................................. 77
9.5.1 Sending Hello packets on NBMA networks ................ 79
10 The Neighbor Data Structure ........................... 80
10.1 Neighbor states ....................................... 83
10.2 Events causing neighbor state changes ................. 87
10.3 The Neighbor state machine ............................ 89
10.4 Whether to become adjacent ............................ 95
10.5 Receiving Hello Packets ............................... 96
10.6 Receiving Database Description Packets ................ 99
10.7 Receiving Link State Request Packets ................. 102
10.8 Sending Database Description Packets ................. 103
10.9 Sending Link State Request Packets ................... 104
10.10 An Example ........................................... 105
11 The Routing Table Structure .......................... 107
11.1 Routing table lookup ................................. 111
11.2 Sample routing table, without areas .................. 111
11.3 Sample routing table, with areas ..................... 112
12 Link State Advertisements (LSAs) ..................... 115
12.1 The LSA Header ....................................... 116
12.1.1 LS age ............................................... 116
12.1.2 Options .............................................. 117
12.1.3 LS type .............................................. 117
12.1.4 Link State ID ........................................ 117
12.1.5 Advertising Router ................................... 119
12.1.6 LS sequence number ................................... 120
12.1.7 LS checksum .......................................... 121
12.2 The link state database .............................. 121
12.3 Representation of TOS ................................ 122
12.4 Originating LSAs ..................................... 123
12.4.1 Router-LSAs .......................................... 126
12.4.1.1 Describing point-to-point interfaces ................. 130
12.4.1.2 Describing broadcast and NBMA interfaces ............. 130
12.4.1.3 Describing virtual links ............................. 131
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 131
12.4.1.5 Examples of router-LSAs .............................. 132
12.4.2 Network-LSAs ......................................... 133
12.4.2.1 Examples of network-LSAs ............................. 134
12.4.3 Summary-LSAs ......................................... 135
12.4.3.1 Originating summary-LSAs into stub areas ............. 137
12.4.3.2 Examples of summary-LSAs ............................. 138
12.4.4 AS-external-LSAs ..................................... 139
12.4.4.1 Examples of AS-external-LSAs ......................... 140
13 The Flooding Procedure ............................... 143
13.1 Determining which LSA is newer ....................... 146
13.2 Installing LSAs in the database ...................... 147
13.3 Next step in the flooding procedure .................. 148
13.4 Receiving self-originated LSAs ....................... 151
13.5 Sending Link State Acknowledgment packets ............ 152
13.6 Retransmitting LSAs .................................. 154
13.7 Receiving link state acknowledgments ................. 155
14 Aging The Link State Database ........................ 156
14.1 Premature aging of LSAs .............................. 157
15 Virtual Links ........................................ 158
16 Calculation of the routing table ..................... 160
16.1 Calculating the shortest-path tree for an area ....... 161
16.1.1 The next hop calculation ............................. 167
16.2 Calculating the inter-area routes .................... 178
16.3 Examining transit areas' summary-LSAs ................ 170
16.4 Calculating AS external routes ....................... 173
16.4.1 External path preferences ............................ 175
16.5 Incremental updates -- summary-LSAs .................. 175
16.6 Incremental updates -- AS-external-LSAs .............. 177
16.7 Events generated as a result of routing table changes 177
16.8 Equal-cost multipath ................................. 178
Footnotes ............................................ 179
References ........................................... 183
A OSPF data formats .................................... 185
A.1 Encapsulation of OSPF packets ........................ 185
A.2 The Options field .................................... 187
A.3 OSPF Packet Formats .................................. 189
A.3.1 The OSPF packet header ............................... 190
A.3.2 The Hello packet ..................................... 193
A.3.3 The Database Description packet ...................... 195
A.3.4 The Link State Request packet ........................ 197
A.3.5 The Link State Update packet ......................... 199
A.3.6 The Link State Acknowledgment packet ................. 201
A.4 LSA formats .......................................... 203
A.4.1 The LSA header ....................................... 204
A.4.2 Router-LSAs .......................................... 206
A.4.3 Network-LSAs ......................................... 210
A.4.4 Summary-LSAs ......................................... 212
A.4.5 AS-external-LSAs ..................................... 214
B Architectural Constants .............................. 217
C Configurable Constants ............................... 219
C.1 Global parameters .................................... 219
C.2 Area parameters ...................................... 220
C.3 Router interface parameters .......................... 221
C.4 Virtual link parameters .............................. 224
C.5 NBMA network parameters .............................. 224
C.6 Point-to-MultiPoint network parameters ............... 225
C.7 Host route parameters ................................ 226
D Authentication ....................................... 227
D.1 Null authentication .................................. 227
D.2 Simple password authentication ....................... 228
D.3 Cryptographic authentication ......................... 228
D.4 Message generation ................................... 231
D.4.1 Generating Null authentication ....................... 231
D.4.2 Generating Simple password authentication ............ 232
D.4.3 Generating Cryptographic authentication .............. 232
D.5 Message verification ................................. 234
D.5.1 Verifying Null authentication ........................ 234
D.5.2 Verifying Simple password authentication ............. 234
D.5.3 Verifying Cryptographic authentication ............... 235
E An algorithm for assigning Link State IDs ............ 236
F Multiple interfaces to the same network/subnet ....... 239
G Differences from RFC 2178 ............................ 240
G.1 Flooding modifications ............................... 240
G.2 Changes to external path preferences ................. 241
G.3 Incomplete resolution of virtual next hops ........... 241
G.4 Routing table lookup ................................. 241
Security Considerations .............................. 243
Author's Address ..................................... 243
Full Copyright Statement ............................. 2441. Introduction ✨
okay so bestie, this section is the intro 💖 and it's basically the "here's what this whole doc is about" moment. This document is a spec for OSPF (Open Shortest Path First) 🦋, which is a TCP/IP internet routing protocol. OSPF is classed as an Interior Gateway Protocol (IGP) 🌸, and that just means it passes routing info around between routers that all belong to one single Autonomous System 👑. It's giving "we all live in the same neighbourhood" energy 🏘️.
The big thing? OSPF is built on link-state or SPF technology 🧠✨. That's a real glow-up from the older Bellman-Ford approach that traditional TCP/IP internet routing protocols were using 💅. Main character energy, literally 🎀.
OKAY so this part is where OSPF gets to show off 💅✨ The intro paragraph first: OSPF was built by the OSPF working group of the IETF 🎀 It was designed specifically for the TCP/IP internet, with real support for CIDR and for tagging routes that came from somewhere else 🦋 It also does authentication for routing updates, and it uses IP multicast when it sends and receives them. And honestly? The whole goal was a protocol that reacts super fast to topology changes without spamming the network with routing traffic. Iconic 👑
1.1. Protocol overview
OSPF routes IP packets based solely on the destination IP address in the packet header 🎯 The packets are routed "as is" (they're not wrapped in any extra protocol headers while they travel through the Autonomous System) 💖 OSPF is a dynamic routing protocol, which means it notices topology changes (like a router interface dying 💀) and works out new loop-free routes after a short convergence period. That convergence period is quick and barely uses any routing traffic. Main character energy, no cap ✨
Now the link-state part. Each router keeps a database that describes the Autonomous System's topology, called the link-state database 🧚 Every participating router has an identical copy of it. Each piece of that database is one router's local state (like which interfaces it can actually use and which neighbors it can reach). The router spreads its local state across the whole Autonomous System by flooding 🌊
Every router runs the exact same algorithm, in parallel 👯♀️ From the link-state database, each router builds a shortest-path tree with itself as the root. That tree is how it figures out the route to every destination in the Autonomous System. Externally derived routing info shows up on the tree as leaves 🍃
When there are several equal-cost routes to a destination, traffic gets split equally across them ⚖️ The cost of a route is one dimensionless metric. Lowkey so clean.
OSPF lets you group sets of networks together, and that grouping is called an area 🏡 The area's topology is hidden from the rest of the Autonomous System, and that info hiding means way less routing traffic 🙌 Routing inside the area depends only on the area's own topology, which protects the area from bad routing data 🛡️ An area is basically a generalization of an IP subnetted network. It's giving organized.
OSPF also makes flexible IP subnet configuration possible 🎀 Each route OSPF distributes has a destination and a mask. Two different subnets of the same IP network number can have different sizes (different masks). This is what people call variable length subnetting 🌈 A packet gets routed to the best match, meaning the longest or most specific one. Host routes count as subnets whose masks are "all ones," which is 0xffffffff 💜
Every OSPF protocol exchange is authenticated 🔐 That means only trusted routers can take part in the Autonomous System's routing. There's a bunch of authentication schemes you can use, and separate schemes can be configured for each IP subnet. Obsessed.
Externally derived routing data (like routes learned from an Exterior Gateway Protocol such as BGP; see [Ref23]) gets advertised throughout the Autonomous System 🌍 That data is kept separate from OSPF's link state data. Each external route can also be tagged by the router advertising it, which lets routers on the boundary of the Autonomous System pass extra info between each other 🏷️
1.2. Definitions of commonly used terms
This section defines the terms that mean something specific to OSPF and show up all over the text 📖 If you're new to the Internet Protocol Suite, check out [Ref13] for an intro 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're 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 🔢
Point-to-point networks A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network 🔗
Broadcast networks Networks supporting many (more than two) attached routers, together with the capability to address a single physical message to all of the attached routers (broadcast). Neighboring routers are discovered dynamically on these nets using OSPF's Hello Protocol. The Hello Protocol itself takes advantage of the broadcast capability. The OSPF protocol makes further use of multicast capabilities, if they exist. Each pair of routers on a broadcast network is assumed to be able to communicate directly. An ethernet is an example of a broadcast network 📡
Non-broadcast networks Networks supporting many (more than two) routers, but having no broadcast capability. Neighboring routers are maintained on these nets using OSPF's Hello Protocol. However, due to the lack of broadcast capability, some configuration information may be necessary to aid in the discovery of neighbors. On non-broadcast networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, in turn. An X.25 Public Data Network (PDN) is an example of a non-broadcast network 📮
OSPF runs in one of two modes over non-broadcast networks. The first mode, called non-broadcast multi-access or NBMA, simulates the operation of OSPF on a broadcast network. The second mode, called Point-to-MultiPoint, treats the non-broadcast network as a collection of point-to-point links. Non-broadcast networks are referred to as NBMA networks or Point-to-MultiPoint networks, depending on OSPF's mode of operation over the network 🦋
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. Neighbor relationships are maintained by, and usually 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 Unit of data describing the local state of a router or network. For a router, 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 link state database. Throughout this memo, link state advertisement is abbreviated as LSA 📣
Hello Protocol The part of the OSPF protocol used to establish and maintain neighbor relationships. On broadcast networks the Hello Protocol can also dynamically discover neighboring routers 👂
Flooding The part of the OSPF protocol that distributes and synchronizes the link-state database between OSPF routers 🌊
Designated Router Each broadcast and NBMA network that has at least two attached routers has a Designated Router. The Designated Router generates an LSA for the 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 cuts down the number of adjacencies required on a broadcast or NBMA network. That in turn reduces the amount of routing protocol traffic and the size of the link-state database 📉
Lower-level protocols The underlying network access protocols that provide services to the Internet Protocol and in turn the OSPF protocol. Examples 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 called SPF-based or distributed-database protocols. This section gives a brief look at the link-state developments that influenced OSPF 🎞️
The first link-state routing protocol was developed for the ARPANET packet switching network. It's described in [Ref3], and it's the starting point for every other link-state protocol 🌟 The ARPANET was a homogeneous environment (single-vendor packet switches connected by synchronous serial lines), which made the original protocol simpler to design and implement 💅
1.3. Previous work 🕰️
Okay so the history tea ☕: people already tried to level up this protocol in [Ref4]. That glow-up added a checksum to the LSAs so database corruption could get caught 🕵️♀️, and it had ways to cut routing overhead in a link-state protocol. The big trick was letting the gap between LSA originations stretch out by an entire order of magnitude 😤✨.
Then there's the ISO IS-IS link-state algorithm from [Ref2]. Its main move for broadcast networks is electing a Designated Router for each one, and that DR originates an LSA for the network, so data and routing traffic get trimmed 🎀.
The OSPF Working Group at the IETF took all of this and ran with it 🏃♀️💨. The Designated Router concept got a major upgrade to cut routing traffic even more, multicast was used to save more bandwidth 📡, an area routing scheme came in for information hiding, protection and reduction 🧱, and the algorithms got tuned for efficient operation in TCP/IP internets. Iconic 👑.
1.4. Organization of this document 📚
Quick roadmap, bestie 🗺️. The first three sections are the overview and vibe check 🧐. Sections 4-16 are the deep dive into how the mechanisms work 🤿. Packet formats, protocol constants and configuration items are all in the appendices 📎.
Labels like HelloInterval you'll spot in the text are protocol constants 🔧. They may or may not be configurable. Architectural constants are summarized in Appendix B, and configurable constants are summarized in Appendix C.
The spec explains everything in terms of data structures so it stays precise 💅. Implementations are required to support the functionality described, but they don't need to use the exact data structures in this memo. Your code, your rules, as long as it does the thing 🫶.
1.5. Acknowledgments 🫶
Huge shoutout to the whole crew 📣: Ran Atkinson, Fred Baker, Jeffrey Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui Zhang and the rest of the OSPF Working Group, for all the ideas and support they gave to this project 💖.
The OSPF Point-to-MultiPoint interface is based on work done by Fred Baker 🦋.
The OSPF Cryptographic Authentication option was developed by Fred Baker and Ran Atkinson 🔐.
2. The Link-state Database: organization and calculations 🗺️
The next few subsections explain how OSPF organizes its link-state database 🗂️, and the routing calculations that run on that database to produce a router's routing table 🧮.
2.1. Representation of routers and networks 🕸️
The Autonomous System's link-state database is basically a directed graph 🔀. The vertices are routers and networks. A graph edge connects two routers when they're attached via a physical point-to-point network. An edge from a router to a network means that router has an interface on the network.
Networks are either transit or stub. Transit networks are the ones that can carry data traffic that's neither locally originated nor locally destined 🚦. A transit network's vertex has both incoming and outgoing edges. A stub network's vertex only has incoming edges.
The neighborhood of each network node depends on the network's type (point-to-point, broadcast, NBMA or Point-to-MultiPoint) and on how many routers have an interface to it. Three cases are shown in Figure 1a 📐. Rectangles are routers, circles and oblongs are networks, router names start with RT, network names start with N, and router interface names start with I. Lines between routers mean point-to-point networks. The left side shows networks with their connected routers, and the right side shows the resulting graphs.
**FROM**
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Physical point-to-point networks
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Stub 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 | |
+---+ +---+
Broadcast or NBMA networks
Figure 1a: 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.The top of Figure 1a shows two routers on a point-to-point link. In the database graph, those two router vertices are directly connected by a pair of edges, one in each direction 🤝. Interfaces on point-to-point networks don't need to be assigned IP addresses. When they are assigned, they're modelled as stub links, with each router advertising a stub connection to the other router's interface address. Optionally, an IP subnet can be assigned to the point-to-point network. In that case, both routers advertise a stub link to the IP subnet, instead of advertising each others' IP interface addresses 🌸.
The middle of Figure 1a shows a network with only one attached router, which is a stub network 🧍. Here the network sits at the end of a stub connection in the database's graph.
When multiple routers are attached to a broadcast network, the database graph shows all of them bidirectionally connected to the network vertex 📡. That's the bottom of Figure 1a.
Each network, 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 (referred to as host routes) show up in the graph as stub networks. The network mask for a host route is always 0xffffffff, which means there's a single node.
2.1.1. Representation of non-broadcast networks 🧩
As mentioned earlier, OSPF can run over non-broadcast networks in one of two modes: NBMA or Point-to-MultiPoint. The mode you pick decides how the Hello protocol and flooding work over that non-broadcast network, and how the network gets represented in the link-state database.
In NBMA mode, OSPF emulates operation over a broadcast network 🪞. A Designated Router is elected for the NBMA network, and that DR originates an LSA for the network. The graph representation for broadcast and NBMA networks is identical, and it's pictured in the middle of Figure 1a.
NBMA mode is the most efficient way to run OSPF over non-broadcast networks, both in terms of link-state database size and the amount of routing protocol traffic 📉. But there's one big restriction: it requires all routers attached to the NBMA network to be able to communicate directly 😬. That restriction can be met on some non-broadcast networks, like an ATM subnet using SVCs. It's often not met on other ones, like PVC-only Frame Relay networks.
On non-broadcast networks where not all routers can talk directly, you can break the network into logical subnets, where the routers on each subnet can communicate directly, then run each subnet as an NBMA network (see [Ref15]) 🧠. Real talk though: this takes a lot of administrative overhead and it's prone to misconfiguration 🙈. It's probably better to run that kind of non-broadcast network in Point-to-Multipoint mode.
In Point-to-MultiPoint mode, OSPF treats all router-to-router connections over the non-broadcast network as if they were point-to-point links 🔗. No Designated Router is elected for the network, and no LSA is generated for it. In fact, a vertex for the Point-to-MultiPoint network doesn't appear in the link-state database's graph at all 👻.
Figure 1b illustrates the link-state database representation of a Point-to-MultiPoint network 🎨. On the left side of the figure, a Point-to-MultiPoint network is pictured. It's assumed that all routers can communicate directly, except for routers RT4 and RT5. I3 through I6 indicate the routers' IP interface addresses on the Point-to-MultiPoint network. In the graphical representation of the link-state database, routers that can communicate directly over the Point-to-MultiPoint network are joined by bidirectional edges. Each router also has a stub connection to its own IP interface address, which is different from real point-to-point links (see Figure 1a) 💅.
On some non-broadcast networks, using Point-to-MultiPoint mode along with data-link protocols like Inverse ARP (see [Ref14]) will let OSPF neighbors autodiscover each other, even when broadcast support isn't available 🔍✨.
2.1.2. An example link-state database ✨
okay so this is where it gets fun 🧚 Figure 1b is the Point-to-MultiPoint network example, and it's giving full mesh drama. Read it like a group chat map of who can talk to whom 💬
**FROM**
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|
+---+ +---+ * --------------------
I3| N2 |I4 * RT3| | X | X | X |
+----------------------+ T RT4| X | | | X |
I5| |I6 O RT5| X | | | X |
+---+ +---+ * RT6| X | X | X | |
|RT5| |RT6| * I3| X | | | |
+---+ +---+ I4| | X | | |
I5| | | X | |
I6| | | | X |
Figure 1b: Network map components
Point-to-MultiPoint networks
All routers can communicate directly over N2, except
routers RT4 and RT5. I3 through I6 indicate IP
interface addressesNow let's look at Figure 2, the sample map of an Autonomous System 🗺️ The rectangle labelled H1 is a host with a SLIP connection to Router RT12, so RT12 is advertising a host route 💅 Lines between routers are physical point-to-point networks. The only point-to-point network with interface addresses assigned is the one joining Routers RT6 and RT10 🎀 Routers RT5 and RT7 have BGP connections to other Autonomous Systems, and a set of BGP-learned routes is displayed for both of them 🌈
Here's the tea on costs ☕ A cost is attached to the output side of each router interface, and the system administrator is the one who configures it. The lower the cost, the more likely that interface is to get picked for forwarding data traffic 🚀 Costs also show up on externally derived routing data, like those BGP-learned routes 🫶
+
| 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 SystemOkay, so the directed graph from Figure 2 is shown in Figure 3 🕸️ Arcs are labelled with the cost of the matching router output interface. Arcs with no labelled cost have a cost of 0. Arcs going from networks to routers are always cost 0, but they still matter, no cap 🙈 The externally derived routing data shows up on the graph as stubs 🌸
**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 graph
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.Next up is how the link-state database gets put together 🧩 It's built from LSAs that the routers generate. On the graph, the neighborhood of each router or transit network lives in its own separate LSA, and Figure 4 shows those LSAs visually 📊 RT12 has an interface to two broadcast networks plus a SLIP line to a host 🖥️ Network N6 is a broadcast network with three attached routers, and the cost of every link from N6 to those routers is 0 🫧 Also, the LSA for N6 is actually generated by one of the network's attached routers, specifically the one that got elected Designated Router for that network 👑
**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-LSA N9's network-LSA
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.2.2. The shortest-path tree 🌳
Here's the main idea 💖 When no OSPF areas are configured, every router in the Autonomous System has an identical link-state database, which means they all end up with an identical graphical representation. Each router builds its routing table from that graph by calculating a tree of shortest paths with itself as the root. Obviously, the shortest-path tree depends on which router is doing the math 🙈 The shortest-path tree for Router RT6 in our example is shown in Figure 5 ✨
The tree gives the entire path to any destination network or host, but only the next hop to the destination is actually used in the forwarding process 🦋 The best route to any router also gets calculated, which is so iconic 👑 For the processing of external data, we note the next hop and distance to any router that's advertising external routes. The resulting routing table for Router RT6 is pictured in Table 2. There's a separate route for each end of a numbered point-to-point network, so in this case you get one for the serial line between Routers RT6 and RT10 💅
Routes to networks belonging to other AS'es (such as N12) appear as dashed lines on the shortest path tree in Figure 5. Use of
Okay so bestie, the SPF tree for RT6 is literally a whole vibe 🌳✨. Here's the picture:
RT6(origin)
RT5 o------------o-----------o Ib
/|\ 6 |\ 7
8/8|8\ | \
/ | \ 6| \
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 with no cost listed are the network-to-router links, and those count as zero cost 🧚. The routes to N12 through N15 are external info, and we handle that in Section 2.3 💜.
Here's RT6's local routing table, the part that lists the local destinations 🎀:
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT7 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.Once that's done, the external routing info gets considered in the next section 🌸.
2.3. Use of external routing information
Okay, after the tree is built, we look at the external routing info 👀. This info can come from another routing protocol like BGP, or it can be statically configured (static routes) 🛣️. Default routes can also be part of the Autonomous System's external routing info.
External routing info gets flooded unaltered throughout the AS, no edits, no cap 💅. In our example, every router in the AS knows that RT7 has two external routes, with metrics 2 and 9 ✨.
OSPF supports two types of external metrics 🎀. Type 1 external metrics use the same units as the OSPF interface cost (so, the link state metric) 📏. Type 2 external metrics are an order of magnitude larger, so any Type 2 metric counts as greater than the cost of any path inside the AS 💀. Using Type 2 metrics assumes that routing between AS'es is the main cost of routing a packet, which means you don't need to convert external costs into internal link state metrics. Iconic simplification, honestly 🙌.
Let's walk through Type 1 processing 🦋. Say RT7 and RT5 in Figure 2 are both advertising Type 1 external metrics. For each external route that gets advertised, RT6 works out the total cost as the advertised external cost plus the distance from RT6 to the advertising router. If two routers advertise the same external destination, RT6 picks the one with the minimum total cost 🏆. Then RT6 sets the next hop for that external destination to whatever next hop it would use to reach the chosen advertising router 🧭.
In Figure 2, both RT5 and RT7 advertise an external route to N12 👯. RT7 wins because it advertises N12 at a distance of 10 (8+2) to RT6, which beats RT5's 14 (6+8) 🏅. Table 3 shows the entries added to the routing table when external routes get 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 processing is simpler 😌. The AS boundary router advertising the smallest external metric gets chosen, no matter what its internal distance is 🎯. Say RT5 and RT7 were both advertising Type 2 external routes. Then all traffic for N12 goes 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 show up in the AS at the same time 🌈. When that happens, Type 1 external metrics always take precedence 👑.
Quick heads up, this section has assumed that packets for external destinations always go through the advertising AS boundary router 🙈. That's not always the move. For example, in Figure 2 imagine there's another router on Network N6 called RTX 🤔. Say RTX doesn't take part in OSPF routing, but it does swap BGP info with the AS boundary router RT7. Then RT7 would end up advertising OSPF external routes for all the destinations that should go to RTX. That can add an extra hop, because packets for those destinations would always have to go to RT7 first (the advertising router) 😩.
To fix this, OSPF lets an AS boundary router set a "forwarding address" in its AS-external-LSAs 🪄. In the example above, RT7 would put RTX's IP address as the "forwarding address" for all the 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 getting external routing info through a mix of static configuration and external routing protocols 🧚♀️. RT6 would then start advertising itself as an AS boundary router and would originate a set of OSPF AS-external-LSAs. In each one, RT6 would name the correct Autonomous System exit point for the destination by setting the LSA's "forwarding address" field appropriately 🦋.
2.4. Equal-cost multipath
So far we've only looked at a single route to any destination, to keep things simple 🙃. Real life is messier 😭. If multiple equal-cost routes to a destination exist, they all get discovered and used 🔥. This doesn't change the algorithm conceptually, and we'll talk about it more when we get into the tree-building process 🌸.
With equal-cost multipath, a router can have several next hops available toward any given destination 🛤️✨.
3. Splitting the AS into Areas ✨
OSPF lets you group contiguous networks and hosts together 🧁. A group like that, plus the routers with interfaces to any of the included networks, is called an area 🏡. Each area runs its own copy of the basic link-state routing algorithm 🔁. So each area has its own link-state database and matching graph, just like we covered in the last 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 🙈. That isolation of knowledge lets the protocol cut routing traffic way down compared to treating the whole AS as one link-state domain 📉✨.
With areas, it's no longer true that every router in the AS has an identical link-state database 🫨. A router actually keeps a separate link-state 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 link-state databases for that area 👯♀️.
Routing in the AS 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 in different areas (inter-area routing is used) 🗺️. With intra-area routing, the packet gets routed based only on info obtained inside the area, and routing info from outside the area can't be used 🚫. That protects intra-area routing from bad routing info getting injected 🛡️. We'll cover inter-area routing in Section 3.2 🎀.
3.1. The backbone of the Autonomous System
The OSPF backbone is the special OSPF Area 0 (often written as Area 0.0.0.0, since OSPF Area ID's are typically formatted as IP addresses) 👑. The backbone always contains all area border routers 🌉. It's responsible for distributing routing info between non-backbone areas 📦. The backbone must be contiguous 🔗. It doesn't need to be physically contiguous, though, because backbone connectivity can be set up and maintained through 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 backbone network 🫶. On the backbone's graph, 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 🔒.
3.2. Inter-area routing ✨
When a packet goes between two non-backbone areas, it always goes through the backbone 🦋. The whole trip splits into three connected 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 whichever set of these paths has the smallest total cost 💅
Another way to picture it: inter-area routing forces a star shape onto the Autonomous System ⭐, with the backbone as the hub and each non-backbone area as a spoke 🌸.
The backbone's topology decides which backbone paths get used between areas. You can level that up by adding virtual links 🎀, which gives the system administrator some control over the routes inter-area traffic takes 👑.
The right area border router to use as the packet leaves the source area gets chosen in exactly the same way routers advertising external routes get chosen 💅. Each area border router summarizes for its area what its cost is to all networks external to that area. After the SPF tree is calculated for the area, routes to all inter-area destinations are worked out by checking those area border router summaries 🧚.
3.3. Classification of routers ✨
Before areas showed up, the only OSPF routers with a specialized job were the ones advertising external routing info, like Router RT5 in Figure 2 🙈. Once the AS gets split into areas, routers get sorted by function into four overlapping categories:
- Internal routers 🍓: A router with all directly connected networks belonging to the same area. 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. They condense the topological information of their attached areas for distribution to the backbone. The backbone in turn distributes that information to the other areas.
- Backbone routers 💜: A router that has an interface to the backbone area. This includes all routers that interface to more than one area (i.e., area border routers). However, backbone routers do not have to be area border routers. Routers with all interfaces connecting to the backbone area are supported.
- AS boundary routers 👑: A router that exchanges routing information with routers belonging to other Autonomous Systems. Such a router advertises AS external routing information throughout the Autonomous System. The paths to each AS boundary router are known by every router in the AS. This classification is completely independent of the previous classifications: AS boundary routers may be internal or area border routers, and may or may not participate in the backbone 💅.
3.4. A sample area configuration ✨
Figure 6 shows a sample area configuration 🗺️. The first area consists of networks N1-N4, along with their attached routers RT1-RT4. The second area consists of networks N6-N8, along with their attached routers RT7, RT8, RT10 and RT11. The third area consists of networks N9-N11 and Host H1, along with their attached routers RT9, RT11 and RT12. The third area has been configured so that networks N9-N11 and Host H1 will all be grouped into a single route when advertised external to the area (see Section 3.5 for more details) 🫶.
In Figure 6, Routers RT1, RT2, RT5, RT6, RT8, RT9 and RT12 are internal routers. Routers RT3, RT4, RT7, RT10 and RT11 are area border routers. And, as before, Routers RT5 and RT7 are AS boundary routers 🔥.
Figure 7 shows the resulting link-state database for Area 1. The figure completely describes that area's intra-area routing. It also shows the complete view of the internet for the two internal routers RT1 and RT2. It's the job of the area border routers, RT3 and RT4, to advertise into Area 1 the distances to all destinations external to the area. These are indicated in Figure 7 by the dashed stub routes. Also, RT3 and RT4 must advertise into Area 1 the location of the AS boundary routers RT5 and RT7. Finally, AS-external-LSAs from RT5 and RT7 are flooded throughout the entire AS, and in particular throughout Area 1. These LSAs are included in Area 1's database and yield routes to Networks N12-N15 🌸.
Routers RT3 and RT4 must also summarize Area 1's topology for
...........................
. + .
. | 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 configurationdistribution to the backbone 🌊. Their backbone LSAs are shown in Table 4. These summaries show which networks are contained in Area 1 (i.e., Networks N1-N4), and the distance to these networks from the routers RT3 and RT4 respectively.
The link-state database for the backbone is shown in Figure 8. The set of routers pictured are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. In order to make the backbone connected, a virtual link has been configured between Routers R10 and R11 🎀.
The area border routers RT3, RT4, RT7, RT10 and RT11 condense the routing information of their attached non-backbone areas for distribution via the backbone. These are the dashed stubs that appear in Figure 8. Remember that the third area has been configured to condense Networks N9-N11 and Host H1 into a single route, which yields a single dashed line for networks N9-N11 and Host H1 in Figure 8 🧚. Routers RT5 and RT7 are AS boundary routers, and their externally derived information also appears on the graph in Figure 8 as stubs 💖.
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3
Table 4: Networks advertised to the backbone
by Routers RT3 and RT4. **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| | |20|27| | | |
N6| | |16|15| | | |
N7| | |20|19| | | |
N8| | |18|18| | | |
N9-N11,H1| | |29|36| | | |
N12| | | | |8 |2 | |
N13| | | | |8 | | |
N14| | | | |8 | | |
N15| | | | | |9 | |
Figure 7: Area 1's Database.Okay, so the diagram above is Area 1's database 🍓. Networks and routers are both vertices. An edge of cost X connects Vertex A to Vertex B if and only if the intersection of Column A and Row B is marked with an X ✨.
**FROM**Okay so here's the backbone's database, and it's giving main character energy 🗺️✨
|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| | | | | | |11|
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.The backbone is the squad that lets area border routers swap summaries with each other 🫶. Every area border router hears the area summaries from all the other area border routers. Then it builds a picture of the distance to every network outside its own area by checking out the collected LSAs and adding in the backbone distance to each advertising router 💅.
Let's use RT3 and RT4 as our example 🎀. First they calculate the SPF tree for the backbone. That gives them the distances to all the other area border routers. They also note the distances to the networks (Ia and Ib) and the AS boundary routers (RT5 and RT7) that belong to the backbone. This calculation is shown in Table 5.
dist from dist from
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.Next, RT3 and RT4 look at the area summaries from these area border routers, and that tells them how far away every network outside their area is 🧠. They then advertise those distances internally to the area. The advertisements that Routers RT3 and RT4 make into Area 1 are in Table 6. Table 6 assumes that an area range has been configured for the backbone which groups Ia and Ib into a single LSA 📦.
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.The info RT3 and RT4 import into Area 1 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 ⚖️.
RT1 can also work out the shortest path to the AS boundary routers RT5 and RT7 this same way 🛣️. Then, by looking at RT5 and RT7's AS-external-LSAs, RT1 can choose 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 💀. Configuring a virtual link between Routers RT7 and RT10 gives the backbone more connectivity and more resistance to such failures 💪.
3.5. IP subnetting support 🧩
OSPF attaches an IP address mask to each advertised route 🎀. The mask shows the range of addresses that a particular route describes. For example, a summary-LSA for the destination 128.185.0.0 with a mask of 0xffff0000 actually describes one route to the whole collection of destinations 128.185.0.0 - 128.185.255.255. 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 makes what people commonly call variable-length subnetting possible 🧁. This means a single IP class A, B, or C network number can be broken up into many subnets of different sizes. For example, the network 128.185.0.0 could be broken up into 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 together with their masks.
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.There are tons of ways to divide a class A, B, or C network into variable-sized subnets, but the precise procedure is beyond the scope of this specification 🙅. What this specification does establish is this guideline: when an IP packet is forwarded, it's always forwarded to the network that is the best match for the packet's destination. Here, best match means 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, yet 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.
Attaching an address mask to each route also enables IP supernetting 🌈. For example, a single physical network segment could be assigned the [address,mask] pair [192.9.4.0,0xfffffc00]. The segment would then be a single IP network, containing addresses from the four consecutive class C network numbers 192.9.4.0 through 192.9.7.0. Such addressing is now becoming commonplace with the advent of CIDR (see [Ref10]).
To get better aggregation at area boundaries, area address ranges can be used (see Section C.2 for more details) 📦. Each address range is defined as an [address,mask] pair. Many separate networks can then be contained in a single address range, just like a subnetted network is composed 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 the route is the maximum cost to any of the networks falling in the specified range 📈.
For example, an IP subnetted network might be configured as a single OSPF area 🏠. In that case, a single address range could be configured: 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. However, outside the area a single route for the entire subnetted network would be distributed, hiding even the fact that the network is subnetted at all 🙈. The cost of this route is the maximum of the set of costs to the component subnets.
3.6. Supporting stub areas 🌿
In some Autonomous Systems, the majority of the link-state database may consist of AS-external-LSAs 📚. An OSPF AS-external-LSA is usually flooded throughout the entire AS. However, OSPF allows certain areas to be configured as "stub areas" 🧸. AS-external-LSAs are not flooded into or throughout stub areas. Routing to AS external destinations in these areas is based on a (per-area) default only. This reduces the link-state 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. This works as follows: one or more of the stub area's area border routers must advertise a default route into the stub area via summary-LSAs. These summary defaults are flooded throughout the stub area, but no further. (For this reason, these defaults pertain only to the particular stub area.) These summary default routes will be used for 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 a stub when there's a single exit point from the area, or when the choice of exit point doesn't need to be made on a per-external-destination basis 🚪. For example, Area 3 in Figure 6 could be configured as a stub area, because all external traffic 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-LSA), instead of flooding the AS-external-LSAs for Networks N12-N15 into and throughout the area.
OSPF makes sure that all routers belonging to an area agree on whether the area has been configured as a stub 🤝. This guarantees that no confusion arises while flooding AS-external-LSAs.
Stub areas come with a couple of restrictions 🚧: virtual links cannot be configured through stub areas, and AS boundary routers cannot be placed internal to stub areas.
3.7. Partitions of areas 💔
OSPF doesn't actively try to repair area partitions 🛠️. When an area becomes partitioned, each component simply becomes a separate area. The backbone then performs routing between the new areas. Some destinations that were reachable via intra-area routing before the partition will now require inter-area routing 🌸.
However, in order to keep full routing after a partition, an address range must not be split across multiple pieces of the area partition 🧩 Also, the backbone itself must not partition 🙅♀️ If it does, parts of the Autonomous System 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. In either case, the edge is colored with the network's Area ID 🎨
A group of edges, all having the same color, and 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). The routing in the Autonomous System will continue to function as long as these regions of 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 having interfaces to multiple areas run multiple copies of the algorithm. A brief summary of the routing algorithm follows 👀
When a router starts, it first initializes the routing protocol data structures 🚀 The router then waits for indications from the lower-level protocols that its interfaces are functional 🔌
A router then uses the OSPF's Hello Protocol to acquire neighbors 👋 The router 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 may be necessary in order to discover neighbors 🛠️ On broadcast and NBMA networks 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 🤝 Link-state databases are synchronized between pairs of adjacent routers. On broadcast and NBMA networks, the Designated Router determines which routers should become adjacent 💅
Adjacencies control the distribution of routing information 📬 Routing updates are sent and received only on adjacencies.
A router periodically advertises its state, which is also called link state 📣 Link state is also advertised when a router's state changes 🔄 A router's adjacencies are reflected in the contents of its LSAs. This relationship between adjacencies and link state allows the protocol to detect dead routers in a timely fashion ⏰
LSAs are flooded throughout the area 🌊 The flooding algorithm is reliable, ensuring that all routers in an area have exactly the same link-state database. This database consists of the collection of LSAs originated by each router belonging to the area. From this database each router calculates a shortest-path tree, with itself as root 🌳 This shortest-path tree in turn yields a routing table for the protocol 🗂️
4.1. Inter-area routing
The previous section described the operation of the protocol within a single area. For intra-area routing, no other routing information is pertinent 🏡 In order to be able to route to destinations outside of the area, the area border routers inject additional routing information into the area. This additional information is a distillation of the rest of the Autonomous System's topology 🧃
This distillation is accomplished as follows: Each area border router is by definition connected to the backbone 🦴 Each area border router summarizes the topology of its attached non-backbone areas for transmission on the backbone, and hence to all other area border routers. An area border router then has complete topological information concerning the backbone, and the area summaries from each of the other area border routers. From this information, the router calculates paths to all inter-area destinations. The router then advertises these paths into its attached areas. This enables the area's internal routers to pick the best exit router when forwarding traffic inter-area destinations 🚪💖
4.2. AS external routes
Routers that have information regarding other Autonomous Systems can flood this information throughout the AS 🌍 This external routing information is distributed verbatim to every participating router. There is one exception: external routing information is not flooded into "stub" areas (see Section 3.6) 🙈
To utilize external routing information, the path to all routers advertising external information must be known throughout the AS (excepting the stub areas). For that reason, the locations of these AS boundary routers are 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 does not provide any explicit fragmentation/reassembly support. When fragmentation is necessary, IP fragmentation/reassembly is used. OSPF protocol packets have been designed so that large protocol packets can generally be split into several smaller protocol packets. This practice is recommended; 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 received. As an aid to accomplishing this, OSPF protocol packets should have their IP precedence field set to the value Internetwork Control (see [Ref5]) 👑
All OSPF protocol packets share a common protocol header that is described in Appendix A 📋 The OSPF packet types are listed below in Table 8. 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 the forming of 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 (LSAs) one hop further away from their point of origination 🚚 A single Link State Update packet may contain the LSAs of several routers. Each LSA is tagged with the ID of the originating router and a checksum of its link state contents 🏷️ Each LSA also has a type field; the different types of OSPF LSAs are listed below in Table 9 📝
OSPF routing packets (with the exception of Hellos) are sent only over adjacencies. This means that all OSPF protocol packets travel a single IP hop, except those that are 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 🎯
4.4. Basic implementation requirements
An implementation of OSPF requires the following pieces of system support 🧰
Timers
Two different kind 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. These are used for the sending of packets at regular intervals. A good example of this is the regular broadcast of Hello packets. 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/subtracted from the interval timer at each firing 🎲💅
Table 9: OSPF link state advertisements (LSAs).
LS LSA LSA description
type name
________________________________________________________
1 Router-LSAs Originated by all routers.
This LSA describes
the collected states of the
router's interfaces to an
area. Flooded throughout a
single area only.
________________________________________________________
2 Network-LSAs Originated for broadcast
and NBMA networks by
the Designated Router. This
LSA contains the
list of routers connected
to the network. Flooded
throughout a single area only.
________________________________________________________
3,4 Summary-LSAs Originated by area border
routers, and flooded through-
out the LSA's associated
area. Each summary-LSA
describes a route to a
destination outside the area,
yet still inside the AS
(i.e., an inter-area route).
Type 3 summary-LSAs describe
routes to networks. Type 4
summary-LSAs describe
routes to AS boundary routers.
________________________________________________________
5 AS-external-LSAs Originated by AS boundary
routers, and flooded through-
out the AS. Each
AS-external-LSA describes
a route to a destination in
another Autonomous System.
Default routes for the AS can
also be described by
AS-external-LSAs.Okay so this is the LSA squad lineup 🦋 Five types, each with its own job, and it's giving organized chaos in the best way 💅
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 [Ref7].
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; see Section 3.5 for details. Subnet sizes, but make it flexible 🌸
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 [Ref10]. Bigger networks, bigger vibes 🧚
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. Unplugged cable = instant drama 😭
Non-broadcast lower-level protocol support 📮 On non-broadcast networks, the OSPF Hello Protocol can be aided by providing an indication when an attempt is made to send a packet to a dead or non-existent router. For example, on an X.25 PDN a dead neighboring router may be indicated by the reception of a X.25 clear with an appropriate cause and diagnostic, and this information would be passed to OSPF. Receipts, but for routers 💀
List manipulation primitives 📝 Much of the OSPF functionality is described in terms of its operation on lists of LSAs. For example, the collection of LSAs that will be retransmitted to an adjacent router until acknowledged are described as a list. Any particular LSA may be on many such lists. An OSPF implementation needs to be able to manipulate these lists, adding and deleting constituent LSAs as necessary.
Tasking support ⭐ Certain procedures described in this specification invoke other procedures. At times, these other procedures should be executed in-line, that is, before the current procedure is finished. This is indicated in the text by instructions to execute a procedure. At other times, the other procedures are to be executed only when the current procedure has finished. This is indicated by instructions to schedule a task.
4.5. Optional OSPF capabilities ✨
The OSPF protocol defines several optional capabilities. A router indicates the optional capabilities that it supports in its OSPF Hello packets, Database Description packets and in its LSAs. This enables routers supporting a mix of optional capabilities to coexist in a single Autonomous System. Mixed squads, one group chat 🫶
Some capabilities must be supported by all routers attached to a specific area. In this case, a router will not accept a neighbor's Hello Packet unless there is a match in reported capabilities (i.e., a capability mismatch prevents a neighbor relationship from forming). An example of this is the ExternalRoutingCapability (see below).
Other capabilities can be negotiated during the Database Exchange process. This is accomplished by specifying the optional capabilities in Database Description packets. A capability mismatch with a neighbor in this case will result in only a subset of the link state database being exchanged between the two neighbors.
The routing table build process can also be affected by the presence/absence of optional capabilities. For example, since the optional capabilities are reported in LSAs, routers incapable of certain functions can be avoided when building the shortest path tree. Not everyone gets a seat at the shortest path tree table 🍓
The OSPF optional capabilities defined in this memo are listed below. See Section A.2 for more information.
ExternalRoutingCapability 🌸 Entire OSPF areas can be configured as "stubs" (see Section 3.6). AS-external-LSAs will not be flooded into stub areas. This capability is represented by the E-bit in the OSPF Options field (see Section A.2). In order to ensure consistent configuration of stub areas, all routers interfacing to such an area must have the E-bit clear in their Hello packets (see Sections 9.5 and 10.5).
5. Protocol Data Structures ✨
The OSPF protocol is described herein in terms of its operation on various protocol data structures. The following list comprises the top-level OSPF data structures. Any initialization that needs to be done is noted. OSPF areas, interfaces and neighbors also have associated data structures that are described later in this specification. Think of these as the main characters, with side characters coming later 👑
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 is changed, the router's OSPF software should be restarted before the new Router ID takes effect. In this case the router should flush its self-originated LSAs from the routing domain (see Section 14.1) before restarting, or they will persist for up to MaxAge minutes. Changing your ID is a whole glow-up, so flush first, bestie 🦋
Area structures 🗺️ Each one of the areas to which the router is connected has its own data structure. This data structure describes the working of the basic OSPF algorithm. Remember that each area runs a separate copy of the basic OSPF algorithm. Every area gets its own copy of the algorithm, no sharing the tea 🍵
Backbone (area) structure 🦴 The OSPF backbone area is responsible for the dissemination of inter-area routing information. The backbone is the main hub that spreads the news between areas 📣
Virtual links configured 🔗 The virtual links configured with this router as one endpoint. In order to have configured virtual links, the router itself must be an area border router. Virtual links are identified by the Router ID of the other endpoint -- which is another area border router. These two endpoint routers must be attached to a common area, called the virtual link's Transit area. Virtual links are part of the backbone, and behave as if they were unnumbered point-to-point networks between the two routers. A virtual link uses the intra-area routing of its Transit area to forward packets. Virtual links are brought up and down through the building of the shortest-path trees for the Transit area. Virtual links are the long-distance besties that somehow still feel close 🫶
List of external routes 🌍 These are routes to destinations external to the Autonomous System, that have been gained either through direct experience with another routing protocol (such as BGP), or through configuration information, or through a combination of the two (e.g., dynamic external information to be advertised by OSPF with configured metric). Any router having these external routes is called an AS boundary router. These routes are advertised by the router into the OSPF routing domain via AS-external-LSAs. Outside gossip, but make it official 📮
List of AS-external-LSAs 📜 Part of the link-state database. These have originated from the AS boundary routers. They comprise routes to destinations external to the Autonomous System. Note that, if the router is itself an AS boundary router, some of these AS-external-LSAs have been self-originated. Yes, you can be your own outside source, iykyk 🙈
The routing table 🧭 Derived from the link-state database. Each entry in the routing table is indexed by a destination, and contains the destination's cost and a set of paths to use in forwarding packets to the destination. A path is described by its type and next hop. For more information, see Section 11. The GPS of the whole network 🗺️✨
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). RT10 and RT11 are giving long-distance friendship goals 💜
6. The Area Data Structure 🦋
okay bestie, the area data structure is literally everything the basic OSPF routing algorithm needs to run 💅 Every area keeps its own link-state database, so each one has its own little world 🌸 A network belongs to one single area, a router interface connects to one single area, and each router adjacency belongs to one single area too. no sharing, no drama 🙅
The OSPF backbone is the special area that handles spreading inter-area routing info around 👑
Okay so the area link-state database is the collection of router-LSAs, network-LSAs and summary-LSAs that came from the area's routers. This info only floods throughout one area, not beyond it 🧚 The list of AS-external-LSAs (see Section 5) also counts as part of each area's link-state database, iykyk ✨
Area ID A 32-bit number that identifies the area. The Area ID of 0.0.0.0 is reserved for the backbone, no exceptions 💖
List of area address ranges To aggregate routing info at area boundaries, you can use area address ranges 🎀 Each range is specified by an [address,mask] pair plus a status of either Advertise or DoNotAdvertise (see Section 12.4.3). Main character energy for summarizing routes 💅
+----+
|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 structuresAssociated router interfaces These are 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, 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-LSAs A router-LSA is generated by each router in the area. It describes the state of that router's interfaces to the area ✨
List of network-LSAs One network-LSA is generated for each transit broadcast and NBMA network in the area. A network-LSA describes the set of routers currently connected to that network 🌈
List of summary-LSAs Summary-LSAs come from the area's area border routers. They describe routes to destinations inside the Autonomous System but outside the area (aka inter-area destinations) 🦋
Shortest-path tree The shortest-path tree for the area, with this router itself as the root. It's derived from the collected router-LSAs and network-LSAs using the Dijkstra algorithm (see Section 16.1) 🧠
TransitCapability This parameter tells you whether the area can carry data traffic that neither originates nor terminates in the area itself 🫶 It gets calculated when the area's shortest-path tree is built (see Section 16.1). TransitCapability is set to TRUE if and only if there are one or more fully adjacent virtual links using the area as Transit area. It's then used as an input to a later step of the routing table build process (see Section 16.3). When an area's TransitCapability is TRUE, the area is called a "transit area" 💜
ExternalRoutingCapability This is whether AS-external-LSAs will be flooded into and throughout the area. It's a configurable parameter ⭐ If AS-external-LSAs 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 StubDefaultCost is the cost of the default summary-LSA that the router should advertise into the area. See Section 12.4.3 for more 🍓
Unless otherwise specified, the rest of this document is about how OSPF operates within a single area 🌸
7. Bringing Up Adjacencies 🧚
okay so OSPF creates adjacencies between neighboring routers so they can swap routing info 🫶 Not every pair of neighbors will end up adjacent, and that's totally fine 💅 This section covers the generalities of creating adjacencies. For the full details, consult Section 10.
7.1. The Hello Protocol 👋
The Hello Protocol is the one in charge of establishing and maintaining neighbor relationships 💖 It also makes sure communication between neighbors is bidirectional. Hello packets get sent periodically out of all router interfaces. Bidirectional communication is indicated when a router sees itself listed in the neighbor's Hello Packet ✨ On broadcast and NBMA networks, the Hello Protocol elects a Designated Router for the network 👑
The Hello Protocol works differently depending on the network type: broadcast networks, NBMA networks and Point-to-MultiPoint networks each get their own vibe 🦋 On broadcast networks, each router advertises itself by periodically multicasting Hello Packets, which lets neighbors 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 NBMA networks, some configuration info may be 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 NBMA network first becomes operational. 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.
On Point-to-MultiPoint networks, a router sends Hello Packets to all the neighbors it can communicate with directly 🧚 These neighbors may be discovered dynamically through a protocol such as Inverse ARP (see [Ref14]), or they may be configured.
Once a neighbor has been discovered, bidirectional communication is ensured, and (if on a broadcast or NBMA 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) 💅 If an adjacency is going to be formed, the first step is to synchronize the neighbors' link-state 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 routers' link-state databases stay synchronized 😭 OSPF keeps this simple by only requiring adjacent routers to stay synchronized. 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 LSAs in the router's database. When the neighbor sees an LSA that's more recent than its own copy, it makes a note that this newer LSA 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 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 so at fixed intervals, whose length is the configured per-interface 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 has a list of the LSAs for which the neighbor has more up-to-date instances. These LSAs are requested in Link State Request Packets. Link State Request packets that aren't satisfied get retransmitted at fixed intervals of time RxmtInterval 🔁 When the Database Description Process has completed and all Link State Requests have been satisfied, the databases are deemed synchronized and the routers are marked fully adjacent 🥳 At that point the adjacency is fully functional and gets advertised in the two routers' router-LSAs ✨
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 👑
Every broadcast and NBMA network has a Designated Router, and it does two main jobs for the routing protocol 🧠
- The Designated Router originates a network-LSA on behalf of the network. This LSA lists the set of routers (including the Designated Router itself) currently attached to the network. The Link State ID for this LSA (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 network's subnet/network mask 🌈
- The Designated Router becomes adjacent to all other routers on the network. Since the link state databases are synchronized across adjacencies (through adjacency bring-up and then the flooding procedure), the Designated Router plays a central part in the synchronization process 🫶
Okay bestie, so the Designated Router gets picked by the Hello Protocol 🦋. Every router's Hello Packet carries its Router Priority, and you can set that per interface 🎀. When a router's interface to a network first comes alive, it checks whether there's already a Designated Router for that network. If there is, it just accepts that one, no matter what the priority is 💅. (Yes, this makes the DR harder to predict, but it means the DR changes way less often 🙈.) If there isn't one yet, the router makes itself the DR as long as it has the highest Router Priority on the network. A more detailed and accurate version of the election is in Section 9.4 ✨.
The DR is the endpoint of a ton of adjacencies, so it's kinda the main character 👑. To make flooding efficient on broadcast networks, the DR multicasts its Link State Update Packets to AllSPFRouters, instead of sending a separate copy over every adjacency 💜.
Section 2 talks about the directed graph of an area 🌈. Router nodes are labelled with their Router ID, and transit network nodes are labelled with the IP address of their DR. So when the DR changes, the network node on the graph looks brand new 😭. That makes the network and all its attached routers originate new LSAs, and until the link-state databases converge again, there can be some temporary loss of connectivity. That can cause ICMP unreachable messages to get sent back in response to data traffic 💀. This is why the DR should change only infrequently. Set the Router Priorities so the most dependable router on a network ends up as DR eventually 🫶.
7.4. The Backup Designated Router 🧚
Okay so to make switching to a new DR way smoother, every broadcast and NBMA network has a Backup Designated Router 🌸. The BDR is also adjacent to all the routers on the network, and it steps up to become DR when the old one fails 💖. Without a BDR, a brand new DR would have to form new adjacencies with every other router on the network. Forming an adjacency includes synchronizing link-state databases, and that can take forever ngl 😩. During all that, the network wouldn't be available for transit data traffic. The BDR basically makes those adjacencies unnecessary, since they already exist ✨. So the disruption in transit traffic only lasts as long as it takes to flood the new LSAs that announce the new DR 🔥.
The BDR does not generate a network-LSA for the network. (If it did, switching to a new DR would be even faster, but that's a tradeoff between database size and how fast things converge when the DR disappears 🤓.)
The BDR is also elected by the Hello Protocol, and each Hello Packet has a field that specifies the BDR for the network 🎀.
During some steps of the flooding procedure, the BDR plays a passive role and lets the DR do more of the work. That cuts down on the amount of local routing traffic 🍓. See Section 13.3 for more info 💅.
7.5. The graph of adjacencies 🌈
An adjacency is tied to the network that the two routers have in common. If two routers share multiple networks, they can have multiple adjacencies between them 🦋.
You can picture all the adjacencies on a network as an undirected graph ✨. The vertices are the routers, and there's an edge joining two routers if they're adjacent. This graph shows how routing protocol packets flow through the Autonomous System, especially Link State Update Packets 💜.
There are two possible graphs, and which one you get depends on whether a DR is elected for the network 👑. On physical point-to-point networks, Point-to-MultiPoint networks, and virtual links, neighboring routers become adjacent whenever they can talk to each other directly 🌸. But on broadcast and NBMA networks, only the DR and the BDR become adjacent to all the other routers attached to the network 🫶.
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3
Figure 10: The graph of adjacenciesThese graphs are shown in Figure 10 📸. It's assumed that Router RT7 has become the DR, and Router RT3 the BDR, for the Network N2 🧚. The BDR does a lesser job during the flooding procedure than the DR does (see Section 13.3), and that's why the lines connecting the BDR RT3 are dashed 🙈✨.
8. Protocol Packet Processing ✨
okay bestie, this section is all about how routers handle OSPF packets 📦 the whole point is that everyone's link-state databases stay in sync 🫶 so routing protocol packets get VIP treatment 👑 both when they go out and when they come in 💅
routing protocol packets only travel along adjacencies 🦋 the one exception is Hello packets, since those are how adjacencies get discovered in the first place 🔍 so basically all routing protocol packets travel a single IP hop, except the ones sent over virtual links 🌈
every routing protocol packet starts with a standard header 🎀 the sections below explain how to fill it in and how to verify it 🌸 after that, each packet type's own processing section is listed for the deets 🧚
8.1. Sending protocol packets
when a router sends a routing protocol packet, it fills in the standard OSPF packet header like this 💖 for more 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 gets calculated as part of the appropriate authentication procedure, and for some OSPF authentication types the checksum calculation is omitted 🙈 see Section D.4 for details.AuTypeandAuthentication: every OSPF packet exchange is authenticated 🔐 authentication types are assigned by the protocol and documented in Appendix D. a different authentication procedure can be used for each IP network/subnet.AuTypeindicates which authentication procedure is in use, and the 64-bit authentication field is then for use by the chosen procedure. this procedure should be the last one called when forming the packet to be sent 💅 see Section D.4 for details.
the IP destination address is picked like this 🎯 on physical point-to-point networks, the IP destination is always set to the address AllSPFRouters ✨ on all other network types (including virtual links), most OSPF packets are sent as unicasts, meaning directly to the other end of the adjacency 💌 in that case the IP destination is just the Neighbor IP address for that other end (see Section 10). the only packets not sent as unicasts are on broadcast networks 🙌 there, Hello packets go 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, while 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 directly to the neighbor 🎯 on multi-access networks, that means retransmissions should be sent to the neighbor's IP address 💖
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, so on those the IP source should be set to any of the other IP addresses belonging to the router 🦋 that's why there must be at least one IP address assigned to the router.[2] also, virtual links act basically the same as unnumbered point-to-point networks ✨ the difference is that each virtual link does have an IP interface address (discovered during the routing table build process), and that's what gets used as the IP source when sending packets over the virtual link 🌸
for more on the format of specific OSPF packet types, check the sections in Table 10 🧚
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5Table 10: Sections describing OSPF protocol packet transmission.
8.2. Receiving protocol packets
whenever a protocol packet comes in, the router marks it with the interface it was received on 📬 with virtual links configured it's not always obvious which interface that should be 🤔 like, say Router RT11 in Figure 6 🦋 if RT11 gets an OSPF protocol packet on its interface to Network N8, it might 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) 🌈 for the rest of this section, we assume the packet is first associated with the non-virtual link.[3]
before the packet even gets passed to OSPF, it has to pass a bunch of IP-level checks to be accepted 🛡️
- 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 up, the OSPF packet header gets verified 🔍 the fields in the header must match what's configured for the receiving interface, and if they don't, the packet should be discarded 💀
- The version number field must specify protocol version 2.
- 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:
- 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 is required to be on the same network as the receiving interface. This can be verified 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. 🦋
- 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
AuTypespecified in the packet must match theAuTypespecified for the associated area. - The packet must be authenticated. The authentication procedure is indicated by the setting of
AuType(see Appendix D). The authentication procedure may use one or more Authentication keys, which can be configured on a per-interface basis. The authentication procedure may also verify the checksum field in the OSPF packet header (which, when used, is set to the standard IP 16-bit one's complement checksum of the OSPF packet's contents after excluding the 64-bit authentication field). If the authentication procedure fails, the packet should be discarded. 🔐
if the packet type is Hello, it then gets processed further by the Hello Protocol (see Section 10.5) 💖 every other packet type is only sent and received on adjacencies, which means the packet must have come from one of the router's active neighbors 🫶 if the receiving interface connects to a broadcast network, Point-to-MultiPoint network or NBMA network, the sender is identified by the IP source address in the packet's IP header 📍 if it connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) in the packet's OSPF header 🎀 the data structure for the receiving interface holds the list of active neighbors, and packets that don't match any active neighbor get discarded 🗑️
at this point, every received protocol packet is associated with an active neighbor ✨ for the rest of the input processing of each packet type, check the sections in Table 11 🧚
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7Table 11: Sections describing OSPF protocol packet reception.
9. The Interface Data Structure 🌸
okay so an OSPF interface is the connection between a router and a network 🔌 we assume there's a single OSPF interface to each attached network/subnet 🫶 supporting multiple interfaces on one network is covered in Appendix F, so go check that out if you need it 📖 each interface structure has at most one IP interface address 💅
an OSPF interface is considered to belong to the area that contains the attached network 🗺️ all routing protocol packets the router originates over this interface get labelled with the interface's Area ID 🏷️ one or more router adjacencies may develop over an interface 🦋 and a router's LSAs reflect the state of its interfaces and their associated adjacencies, which is honestly so iconic 👑✨
9.1. Interface states ✨
Type: okay so the OSPF interface type is either point-to-point, broadcast, NBMA, Point-to-MultiPoint or virtual link 🦋
State: this is the functional level of an interface 💅 It decides whether or not full adjacencies are allowed to form over the interface, and it's also reflected in the router's LSAs 🌸
IP interface address: the IP address for the interface. It shows up as the IP source address in all routing protocol packets sent out this interface 🎀 Interfaces to unnumbered point-to-point networks don't have one, so no drama there 🧚
IP interface mask: also called the subnet mask 🍓 It marks which part 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 the attached network 💜 On point-to-point networks and virtual links the mask isn't defined. The link itself doesn't get an IP network number, so each side's addresses are assigned independently, if they're assigned at all 🫶
Area ID: the Area ID of the area that the attached network belongs to. Every routing protocol packet coming from the interface is labelled with this Area ID 🌈
HelloInterval: the number of seconds between the Hello packets the router sends on the interface ⏱️ It gets advertised in Hello packets sent out this interface ✨
RouterDeadInterval: how many seconds the router's neighbors wait, after they stop hearing its Hello Packets, before they declare it down 💀 It also gets advertised in Hello packets sent out this interface 🦋
InfTransDelay: the estimated number of seconds it takes to transmit a Link State Update Packet over this interface 🚀 LSAs inside that packet get their age incremented by this amount before transmission. 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 a network both try to become Designated Router, the one with the highest Router Priority wins. A router whose Router Priority is set to 0 is ineligible to become Designated Router on that network 🙈 It's advertised in Hello packets sent out this interface 💖
Hello Timer: an interval timer that makes the interface send a Hello packet. It fires every HelloInterval seconds 💜 Heads up: 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 and, as a result, select a Designated Router on the network 🍓 Its length is RouterDeadInterval seconds ⭐
List of neighboring routers: the other routers attached to this network 🫶 The Hello Protocol builds this list. Adjacencies will form with some of these neighbors, and you can figure out the set of adjacent neighbors by checking all of the neighbors' states 💅
Designated Router: the Designated Router selected for the attached network 👑 The Hello Protocol selects it on all broadcast and NBMA networks. Two pieces of identification get 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-LSA is labelled with the Designated Router's IP address 🦋 It starts out set to 0.0.0.0, which means there's no Designated Router yet 🧚
Backup Designated Router: also selected by the Hello Protocol on all broadcast and NBMA networks 🌈 All routers on the attached network become adjacent to both the Designated Router and the Backup Designated Router 💖 The Backup Designated Router steps up to Designated Router when the current one fails 😭 It starts out set to 0.0.0.0, which means there's no Backup Designated Router yet 🙈
Interface output cost(s): the cost of sending a data packet on the interface, expressed in the link state metric ✨ It's advertised as the link cost for this interface in the router-LSA 🔥 The cost of an interface MUST be greater than zero 💅
RxmtInterval: the number of seconds between LSA retransmissions, for adjacencies on this interface 🌸 It's also used when retransmitting Database Description and Link State Request Packets 🍓
AuType: the authentication type used on the attached network/subnet 🔐 The authentication types are defined in Appendix D 🦋 Every OSPF packet exchange is authenticated 💜 Different authentication schemes MAY be used on different networks/subnets 🌈
Authentication key: this configured data lets the authentication procedure generate and/or verify OSPF protocol packets 🫶 It can be configured on a per-interface basis 🎀 For example, if AuType says simple password, the Authentication key is a 64-bit clear password that gets inserted into the OSPF packet header 🍓 If Autype says Cryptographic authentication instead, the Authentication key is a shared secret that enables generating and/or verifying message digests, which get appended to the OSPF protocol packets 🔐 When Cryptographic authentication is used, multiple simultaneous keys are supported so the key can transition smoothly (see Section D.3) 🌟
9.1. Interface states
The various states that router interfaces can reach are covered in this section 💖 They're listed in order of increasing functionality. The inoperative state comes first, followed by a run of intermediate states, and then the final, fully functional state 🧚 The specification uses this ordering to write things like "those interfaces in state greater than X" 🌈 Figure 11 shows the graph of interface state changes. The arcs are labelled with the event that causes each change, and those events are documented in Section 9.2 🦋 The interface state machine gets a more detailed description in Section 9.3 ✨
Down
This is the initial interface state 🌸 In this state, the lower-level protocols have said the interface is unusable 💀 No protocol traffic at all gets sent or received on it. Interface parameters SHOULD be set to their initial values 🫶 All interface timers SHOULD be disabled, and there SHOULD be no adjacencies associated with the interface 🍓
Loopback
In this state, the router's interface to the network is
+----+ UnloopInd +--------+
|Down|<--------------|Loopback|
+----+ +--------+
|
|InterfaceUp
+-------+ | +--------------+
|Waiting|<-+-------------->|Point-to-point|
+-------+ +--------------+
|
WaitTimer|BackupSeen
|
|
| NeighborChange
+------+ +-+<---------------- +-------+
|Backup|<----------|?|----------------->|DROther|
+------+---------->+-+<-----+ +-------+
Neighbor | |
Change | |Neighbor
| |Change
| +--+
+---->|DR|
+--+
Figure 11: Interface State changesIn addition to the state transitions pictured, Event InterfaceDown always forces Down State, and Event LoopInd always forces Loopback State 🌈
looped back. The interface MAY be looped back in hardware or software 🔧 The interface will be unavailable for regular data traffic. However, it MAY still be desirable to gain information on the quality of this interface, either through sending ICMP pings to the interface or through something like a bit error test 🧪 For this reason, IP packets MAY still be addressed to an interface in Loopback state 💜 To make that work, such interfaces are advertised in router-LSAs as single host routes, whose destination is the IP interface address.[4] 🦋
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 is not allowed to elect a Backup Designated Router or a Designated Router until it transitions out of the Waiting state 🙅♀️ This prevents unnecessary changes of (Backup) Designated Router 🫶
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 ⭐ Once it enters this state, the router tries to form an adjacency with the neighboring router 🤝 Hello Packets are sent to the neighbor every HelloInterval seconds 🌸
DR Other
This is for an interface to a broadcast or NBMA network where another router has been selected as the Designated Router 🎀 In this state, the router itself hasn't been selected as Backup Designated Router either 💅 The router forms adjacencies to both the Designated Router and the Backup Designated Router (if they exist) 🧚
Backup
In this state, the router itself is the Backup Designated Router on the attached network 🦋 It will be promoted to Designated Router when the present Designated Router fails 😭 The router establishes adjacencies to all other routers attached to the network 🫶 The Backup Designated Router performs slightly different functions during the Flooding Procedure than the Designated Router does (see Section 13.3) 🌈 See Section 7.4 for more details on the functions the Backup Designated Router performs 👑
9. The Interface Data Structure, continued ✨
DR 💅 okay so this one is the big boss state! The router itself is the Designated Router on the attached network. It establishes adjacencies with every other router attached to the network, and it must also originate a network-LSA for the network node. That network-LSA lists links to all routers attached to the network, including the Designated Router itself 🫶. If you want the full tea on what the DR actually does, check out Section 7.3.
9.2. Events causing interface state changes 🦋
Interface states can change because of a bunch of different events. They show up as the labelled arcs in Figure 11, and the label definitions are below. If you want to see exactly how these events affect OSPF protocol operation, go read Section 9.3 🌸
InterfaceUp ⭐ Lower-level protocols have said the network interface is operational. That lets the interface leave the Down state. On virtual links, the operational indication actually comes out of the shortest path calculation (see Section 16.7) 🧚
WaitTimer ⏰ The Wait Timer has gone off, which means the waiting period before electing a (Backup) Designated Router is over 🍓
BackupSeen 👀 The router has noticed whether a Backup Designated Router exists for the network or not. This happens in one of two ways. First, a Hello Packet arrives from a neighbor claiming to be the Backup Designated Router itself. Second, a Hello Packet arrives from a neighbor claiming to be the Designated Router while saying there is no Backup Designated Router. Either way, there must be bidirectional communication with that neighbor, which means the router must also show up 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 trigger the NeighborChange event. For what the neighbor states mean, see Section 10.1 🌈
- Bidirectional communication has been established with a neighbor. Basically, the neighbor's state moved up to 2-Way or higher ✨
- Bidirectional communication with a neighbor is gone. The neighbor's state dropped to Init or lower 💀
- A bidirectional neighbor is newly declaring itself as either Designated Router or Backup Designated Router. You spot this by looking at that neighbor's Hello Packets 👑
- A bidirectional neighbor is no longer declaring itself as Designated Router, or no longer declaring itself as Backup Designated Router. This also gets caught by looking at that neighbor's Hello Packets 🙈
- The advertised Router Priority for a bidirectional neighbor has changed. Again, this is detected through that neighbor's Hello Packets 🎀
LoopInd 🔁 The interface has been told it's now looped back to itself. That info can come from network management or from the lower level protocols 🌸
UnloopInd 🌷 The interface has been told it's no longer looped back. Same deal as LoopInd: the news 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 state the interface is in right now, because the new state will be Down 💖
9.3. The Interface state machine 🎀
Here's the detailed rundown of the interface state changes. Every change is kicked off by an event (Section 9.2), and the same event can do different things depending on what state the interface is currently in. That's why the state machine below is organized by current interface state and then received event. Each entry tells you the new interface state and the set of extra actions that are required 💅
When an interface's state changes, it may be necessary to originate a new router-LSA. See Section 12.4 for the details 🧚
Some of the required actions also generate 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, which turns on periodic sending of Hello packets out the interface. If the attached network is a physical point-to-point network, Point-to-MultiPoint network or virtual link, the interface state moves to Point-to-Point. Otherwise, if the router isn't eligible to become Designated Router, the interface state moves to DR Other ✨
Otherwise, the attached network is a broadcast or NBMA network and the router is eligible to become Designated Router. In that case, the interface state is set to Waiting so the router can try to discover the attached network's Designated Router, and the single shot Wait Timer starts 🍓 If the network is NBMA, also look at 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. After this calculation, the interface's new state 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. After this calculation, the interface's new state 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. After this calculation, the interface's new state 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 are disabled. All neighbor connections tied to the interface are destroyed too, 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 isn't connected to the attached network anymore, all the actions for the InterfaceDown event above get run 🙈
State(s): Loopback Event: UnloopInd New state: Down Action: No actions are needed here. The interface variables were already reset when it entered the Loopback state. Just know that an InterfaceUp event is still needed before the interface is fully functional again 🫶
9.4. Electing the Designated Router 👑
This section explains the algorithm for working out a network's Designated Router and Backup Designated Router. The Interface state machine is the one that invokes it. The first time a router runs the election for a network, the network's Designated Router and Backup Designated Router both get set to 0.0.0.0. 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, look at 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 on the list ✨ Throw out every router that isn't eligible to become Designated Router. (Routers with a Router Priority of 0 are ineligible.) Then run the following steps, but only on the routers still left on the list 💖
- Note the current values of the network's Designated Router and Backup Designated Router. You'll compare against these later 🎀
- Calculate the new Backup Designated Router for the network. Only routers on the list that haven't declared themselves Designated Router are eligible to become Backup Designated Router 🦋 If one or more of them have declared themselves Backup Designated Router (meaning they list themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets), the one with the highest Router Priority is declared the Backup Designated Router. If there's a tie, the router with the highest Router ID wins 🌈 If no routers have declared themselves Backup Designated Router, choose the router with the highest Router Priority instead (again leaving out any routers that have declared themselves Designated Router), and use the Router ID to break ties 💅
9.4. Electing the Designated Router ✨ (cont'd)
(3) Okay so here's how the new Designated Router gets calculated 🎀. If one or more routers have declared themselves Designated Router (aka they're literally listing themselves as DR in their Hello Packets), the one with the highest Router Priority is declared to be Designated Router 👑. Tie? The one with the highest Router ID wins 💅. If no routers have declared themselves Designated Router, the Designated Router just becomes the same 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 the Designated Router or no longer the Backup Designated Router, repeat steps 2 and 3, and then proceed to step 5 🔁. For example, if Router X is now the Designated Router, then when step 2 is repeated X is no longer eligible for Backup Designated Router election 🙈. Among other things, this makes sure that no router declares itself both Backup Designated Router and Designated Router, which is giving main character energy for the whole election 👑.
(5) After all these calculations, the router itself may now be Designated Router or Backup Designated Router 🌸. See Sections 7.3 and 7.4 for the extra duties that come with it. The router's interface state SHOULD be set accordingly ✨. If the router itself is now Designated Router, the new interface state is DR. If the router itself is now Backup Designated Router, the new interface state is Backup. Otherwise, the new interface state is DR Other.
(6) If the attached network is an NBMA network, and the router itself has just become either Designated Router or Backup Designated Router, it MUST start sending Hello Packets to those neighbors that are not eligible to become Designated Router (see Section 9.5.1) 🧚. This happens by invoking the neighbor event Start for each neighbor with a Router Priority of 0.
(7) If the above calculations changed the identity of either the Designated Router or Backup Designated Router, the set of adjacencies on this interface needs to be modified 💖. Some adjacencies may need to be formed, and others may need to be broken. To do this, invoke the event AdjOK? on all neighbors whose state is at least 2-Way. That reexamines their eligibility for adjacency (see Sections 10.3 and 10.4) 🫶.
The reason the election algorithm is so complicated is that it wants an orderly handoff from Backup Designated Router to Designated Router when the current Designated Router fails 😭. That orderly handoff comes from hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities 🌈.
The above procedure may elect the same router to be both Designated Router and Backup Designated Router, though that router will never be the calculating router (Router X) itself 💀. The elected Designated Router might not be the router with the highest Router Priority, and the Backup Designated Router won't necessarily have the second highest Router Priority 🍓. 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 in the above procedure 🥺. Also, if Router X is the only attached router that's eligible to become Designated Router, it selects itself as Designated Router and there's no Backup Designated Router for the network ✨.
9.5. Sending Hello packets 🎀
Hello packets go out of each functioning router interface 💜. They're used to discover and maintain neighbor relationships [6]. On broadcast and NBMA networks, Hello Packets are also used to elect the Designated Router and Backup Designated Router 👑.
The format of a Hello packet is detailed in Section A.3.2 📋. The Hello Packet contains the router's Router Priority (used in choosing the Designated Router) and the interval between Hello Packets sent out the interface (HelloInterval) ⏱️. The Hello Packet also says how often a neighbor must be heard from to stay active (RouterDeadInterval) 💅. HelloInterval and RouterDeadInterval MUST be the same for all routers attached to a common network 🫶. The Hello packet also carries 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 🦋. One optional capability is defined in this specification (see Sections 4.5 and A.2). The E-bit of the Options field SHOULD be set if and only if the attached area is capable of processing AS-external-LSAs (i.e., it is 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) 🙅♀️. Unrecognized bits in 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 on the network that have had Hello Packets seen from them recently 🍓. The Hello packet also contains 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 are sent 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 Point-to-MultiPoint networks, separate Hello packets go to each attached neighbor every HelloInterval seconds 💖. Sending Hello packets on NBMA networks is covered in the next section 🫶.
9.5.1. Sending Hello packets on NBMA networks 🌸
Static configuration information may be needed for the Hello Protocol to work on non-broadcast networks (see Sections C.5 and C.6) 😭. On NBMA networks, every attached router that's eligible to become Designated Router becomes aware of all of its neighbors on the network (either through configuration or by some unspecified mechanism) 🧚. Each neighbor is labelled with that neighbor's Designated Router eligibility 💅.
The interface state MUST be at least Waiting before any Hello Packets go out the NBMA interface 🚦. 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 sends Hellos depends on whether the router itself is eligible to become Designated Router 👑.
If the router is eligible to become Designated Router, it MUST periodically send Hello Packets to all neighbors that are also eligible 🎀. On top of that, if the router is itself the Designated Router or Backup Designated Router, it MUST also send periodic Hello Packets to all other neighbors 💜. This means any two eligible routers are always swapping Hello Packets, which is necessary for the Designated Router election algorithm to work correctly 🔥. To keep the number of Hello Packets down, the number of eligible routers on an NBMA 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 Hello packets are sent periodically to any neighbor, the interval between them depends on the 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 tied to a particular OSPF router interface, and it's identified either by the neighboring router's OSPF Router ID or by its Neighbor IP address (see below) 🦋. So if the OSPF router and another router share multiple attached networks, multiple conversations happen, each one described by its own unique neighbor data structure 🌸. Each separate conversation is loosely called a separate "neighbor" in the text ✨.
The neighbor data structure holds all the info that matters for the forming or formed adjacency between the two neighbors 🫶. (But remember, not all neighbors become 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 that fires when no Hello Packet has been seen from this neighbor recently. The length of the timer is RouterDeadInterval seconds 😭.
Master/Slave 🔥 When the two neighbors are swapping databases, they form a master/slave relationship 💜. The master sends the first Database Description Packet and is the only one allowed to retransmit 🎀. The slave can only respond to the master's Database Description Packets 🙅♀️. The master/slave relationship is negotiated in state ExStart 🦋.
DD Sequence Number 🌈 The DD Sequence number of the Database Description packet that is currently being sent to the neighbor 🍓.
Last received Database Description packet 🌸 The initialize(I), more (M) and master(MS) bits, Options field, and DD sequence number contained in the last Database Description packet received from the neighbor. These are used to figure out whether the next Database Description packet received from the neighbor is a duplicate 💅.
Neighbor ID 💖 The OSPF Router ID of the neighboring router. The Neighbor ID is learned when Hello packets are received from the neighbor, or it's configured if this is a virtual adjacency (see Section C.4) ✨.
Okay so, the neighbor data structure is where it gets really good 🧚 Each field is basically the neighbor's profile card, and the router keeps it up to date so it always knows who it's talking to 💅
Neighbor Priority 🎀 The Router Priority of the neighboring router. It's carried in the neighbor's Hello packets, and it's used when picking the Designated Router for the attached network 👑
Neighbor IP address 🦋 The IP address of the neighboring router's interface to the attached network. It's used as the Destination IP address when protocol packets are sent as unicasts along this adjacency. It also shows up in router-LSAs as the Link ID for the attached network if the neighboring router gets picked as Designated Router (see Section 12.4.1). We learn it when Hello packets come in from the neighbor. For virtual links, it's learned during the routing table build process instead (see Section 15) ✨
Neighbor Options 🌸 The optional OSPF capabilities the neighbor supports. We learn these during the Database Exchange process (see Section 10.6), and the neighbor also lists them in its Hello packets. That's the sneaky-useful part: if there's a mismatch in certain crucial OSPF capabilities, the Hello packet gets rejected, so the neighbor relationship won't even start forming (see Section 10.5) 🙅♀️ The optional OSPF capabilities themselves are documented in Section 4.5 💜
Neighbor's Designated Router 🍓 The neighbor's idea of who the Designated Router is. If the neighbor thinks it is the DR, that matters for our local calculation of the Designated Router. This is only defined on broadcast and NBMA networks 🌈
Neighbor's Backup Designated Router 🧚 The neighbor's idea of who the Backup Designated Router is. If the neighbor thinks it is the BDR, that matters for our local calculation of the Backup Designated Router. Also only defined on broadcast and NBMA networks 💅
Next up are the lists of LSAs 📚 These describe subsets of the area link-state database. This memo defines five distinct types of LSAs, and all of them can be in an area link-state database: router-LSAs, network-LSAs, and Type 3 and 4 summary-LSAs (all stored in the area data structure), plus AS-external-LSAs (stored in the global data structure) 🔥
Link state retransmission list 🔁 The list of LSAs that have been flooded on this adjacency but haven't been acknowledged yet. They get retransmitted at intervals until they're acknowledged, or until the adjacency is destroyed 🫶
Database summary list 📋 The complete list of LSAs that make up the area link-state database at the moment the neighbor enters Database Exchange state. This list gets sent to the neighbor in Database Description packets ✨
Link state request list 🙏 The list of LSAs we still need to receive from this neighbor so that both neighbors' link-state databases are in sync. It's created as Database Description packets come in, and then it's sent to the neighbor in Link State Request packets. The list gets depleted as the appropriate Link State Update packets arrive 🍓
10.1. Neighbor states ✨
Okay, so the state of a neighbor (really, the state of a conversation with a neighboring router) is documented in the following sections 💖 The states are listed in order of progressing functionality. The inoperative state comes first, then a bunch of intermediate states, and then the final, fully functional state. The spec uses this ordering to say things like "those neighbors/adjacencies in state greater than X" 🧚 Figures 12 and 13 show the graph of neighbor state changes, with the arcs labelled by the event causing each change. The neighbor events are documented in Section 10.2 🦋
The graph in Figure 12 shows the state changes done by the Hello Protocol. The Hello Protocol handles neighbor acquisition and maintenance, and it makes sure two-way communication happens between neighbors 👑
The graph in Figure 13 shows how an adjacency forms. Not every two neighboring routers become adjacent (see Section 10.4) 🙈 The adjacency starts forming when the neighbor is in ExStart. Once the two routers figure out their master/slave status, the state moves to Exchange. At that point the neighbor starts being used in the flooding procedure, and the two routers start syncing their databases. When that sync is finished, the neighbor is in state Full, and we say the two routers are fully adjacent. Only then does the adjacency show up in LSAs 🌸
For a more detailed description of neighbor state changes, plus the extra actions involved in each change, see Section 10.3 💜
+----+
|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 always happen:
- Event
KillNbralways forces Down State - Event
InactivityTimeralways forces Down State - Event
LLDownalways forces Down State
+-------+
|ExStart|
+-------+
|
NegotiationDone|
+->+--------+
|Exchange|
+--+--------+
|
Exchange|
Done |
+----+ | +-------+
|Full|<---------+----->|Loading|
+----+<-+ +-------+
| LoadingDone |
+------------------+Figure 13: Neighbor state changes (Database Exchange)
In addition to the state transitions pictured, these also happen:
- Event
SeqNumberMismatchforces ExStart state - Event
BadLSReqforces ExStart state - Event
1-Wayforces Init state - Event
KillNbralways forces Down State - Event
InactivityTimeralways forces Down State - Event
LLDownalways forces Down State - Event
AdjOK?leads to adjacency forming/breaking
Down 🌑
This is the starting state of a neighbor conversation. It means we haven't gotten any recent info from the neighbor. On NBMA networks, Hello packets may still be sent to "Down" neighbors, just less often (see Section 9.5.1) 🫧
Attempt 🔎
This state only applies to neighbors attached to NBMA networks. It means no recent info has come in from the neighbor, but a more concerted effort should be made to reach them. That effort is Hello packets sent at intervals of HelloInterval (see Section 9.5.1) 💪
Init 👀
In this state, a Hello packet has recently been seen from the neighbor. However, bidirectional communication hasn't been set up yet, because our 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 out from the associated interface 📣
2-Way 🤝
In this state, the two routers can talk both ways. The Hello Protocol has made sure of that. This is the most advanced state short of starting adjacency establishment. The (Backup) Designated Router gets selected from the set of neighbors in state 2-Way or greater 👑
ExStart 🚀
This is the first step in creating an adjacency between the two neighboring routers. The goal here is to decide which router is the master, and to pick the initial 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. Link State Request packets may also be sent in this state, asking for the neighbor's more recent LSAs. All adjacencies in Exchange state or greater are used by the flooding procedure. These adjacencies can totally transmit and receive all types of OSPF routing protocol packets 🌈
Loading 📥
In this state, Link State Request packets get sent to the neighbor, asking for the more recent LSAs that were discovered (but not yet received) during the Exchange state 🧺
Full 🏆
In this state, the neighboring routers are fully adjacent. These adjacencies will now appear in router-LSAs and network-LSAs 🎉
10.2. Events causing neighbor state changes 💫
State changes can be triggered by a bunch of events. They show up in the labels on the arcs in Figures 12 and 13. Here's what each label means 🎀
HelloReceived 👋 A Hello packet has been received from the neighbor.
Start 🌱 This tells us Hello packets should now be sent to the neighbor at intervals of HelloInterval seconds. This event is only generated for neighbors associated with NBMA networks.
2-WayReceived 🤝 Bidirectional communication has been realized between the two neighboring routers. The router knows this because it sees itself in the neighbor's Hello packet.
NegotiationDone 🎯 The Master/Slave relationship has been negotiated, and DD sequence numbers have been exchanged. This signals the start of sending and receiving Database Description packets. For more on how this event gets generated, consult Section 10.8 ✨
ExchangeDone 🎉 Both routers have successfully sent a full run of Database Description packets, so each one now knows which parts of its link state database are out of date 🫶 For how this event gets generated, check out Section 10.8 💖
BadLSReq 🙈 A Link State Request came in for an LSA that isn't in the database. That's a sign something went wrong in the Database Exchange process 💀
Loading Done ✨ Link State Updates have arrived for every out-of-date part of the database. You can tell because the Link state request list is empty once the Database Exchange is finished 🌸
AdjOK? 🔥 Time to decide whether an adjacency should be established or kept with the neighbor. This event is the one that gets some adjacencies forming and takes others down 💅
The following events make well developed neighbors drop back to lesser states. Unlike the ones above, these can show up no matter which of several states the neighbor conversation is in 👑
SeqNumberMismatch 😭 A Database Description packet showed up that either a) has an unexpected DD sequence number, 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 those means something went wrong while the adjacency was getting set up 🙅♀️
1-Way 🦋 A Hello packet came in from the neighbor that doesn't mention the router. That means communication with the neighbor isn't two-way 🥺
KillNbr 💀 This tells us that all communication with the neighbor is now impossible, so the neighbor has to fall back to Down state 🖤
InactivityTimer ⏰ The inactivity Timer went off, which means no Hello packets have been seen from the neighbor for a while. The neighbor drops back to Down state 😴
LLDown 🌧️ This one comes from the lower level protocols and says the neighbor can't be reached anymore. For example, on an X.25 network it could show up as an X.25 clear indication with the right cause and diagnostic fields. It always forces the neighbor into Down state 🚫
10.3. The Neighbor state machine ✨
Okay so here's the detailed version of how the neighbor's state changes 🧚 Every change gets kicked off by an event (Section 10.2), but the same event can do different things depending on what state the neighbor is already in. That's why the state machine below is organized by current neighbor state and then received event 💜 Each entry tells you the new neighbor state it lands in and the extra actions it needs to do 🎀
When a neighbor's state changes, the Designated Router election algorithm might need to run again. Whether it does depends on if the interface NeighborChange event gets generated (see Section 9.2) 🔄 Also, if the Interface is in DR state (meaning the router is itself the Designated Router), a change in neighbor state might cause a new network-LSA to be originated (see Section 12.4) 🌈
When the neighbor state machine needs to call the interface state machine, that should happen as a scheduled task (see Section 4.4) ⭐ This keeps things simple, since it makes sure neither state machine runs inside the other one 🫧
Entry: Down, Start 🌸
State(s): Down
Event: Start
New state: AttemptAction: Send a Hello Packet to the neighbor (this neighbor is always associated with an NBMA network) and start the Inactivity Timer for the neighbor 🦋 If the timer goes off later, that means communication with the neighbor never got established 🥀
Entry: Attempt, HelloReceived 💖
State(s): Attempt
Event: HelloReceived
New state: InitAction: Restart the Inactivity Timer for the neighbor, since the neighbor has now been heard from ✨
Entry: Down, HelloReceived 🧁
State(s): Down
Event: HelloReceived
New state: InitAction: Start the Inactivity Timer for the neighbor 🕰️ If it goes off later, that would mean the neighbor is dead 💀
Entry: Init or greater, HelloReceived 🫶
State(s): Init or greater
Event: HelloReceived
New state: No state change.Action: Restart the Inactivity Timer for the neighbor, since the neighbor has been heard from again 🔁
Entry: Init, 2-WayReceived 👑
State(s): Init
Event: 2-WayReceived
New state: Depends upon action routine.Action: First, figure out whether an adjacency should be established with the neighbor (see Section 10.4) 🧐 If not, the new neighbor state is 2-Way 🍓
Otherwise, meaning an adjacency should be established, the neighbor state moves to ExStart 🚀 As soon as it gets there, the router increments the DD sequence number in the neighbor data structure 🔢 If this is the first time an adjacency has ever been attempted, the DD sequence number should be given some unique value, like the time of day clock ⏱️ Then it declares itself master by setting the master/slave bit to master 👑 and starts sending Database Description Packets with the initialize (I), more (M) and master (MS) bits set 🎀 That Database Description Packet should otherwise be empty 🫧 It should keep getting retransmitted at intervals of RxmtInterval until the next state is entered (see Section 10.8) 🔁
Entry: ExStart, NegotiationDone 🌷
State(s): ExStart
Event: NegotiationDone
New state: ExchangeAction: 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-LSAs, network-LSAs and summary-LSAs in the area structure, plus the AS-external-LSAs in the global structure 🗂️ AS-external-LSAs get left out of a virtual neighbor's Database summary list 🚫 They also get left out if the area has been configured as a stub (see Section 3.6) 🌿 LSAs whose age is equal to MaxAge get added to the neighbor's Link state retransmission list instead 📮 A summary of the Database summary list gets sent to the neighbor in Database Description packets 📨 Each one has a DD sequence number and gets explicitly acknowledged 💌 Only one Database Description Packet can be outstanding at a time ⏳ For more on sending and receiving these, check out Sections 10.8 and 10.6 🤓
Entry: Exchange, ExchangeDone 🍒
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 🎉 Nothing else needs doing, and this is the adjacency's final state 💯
Otherwise, the new neighbor state is Loading 📥 The router starts (or keeps) sending Link State Request packets to the neighbor (see Section 10.9) 🙏 These ask for the neighbor's more recent LSAs, which were discovered during the Exchange state but haven't been received yet 🔍 They're all listed in the Link state request list for that neighbor 📝
Entry: Loading, Loading Done 🏁
State(s): Loading
Event: Loading Done
New state: FullAction: No action required 🙌 This is the adjacency's final state 👑
Entry: 2-Way, AdjOK? 🦋
State(s): 2-Way
Event: AdjOK?
New state: Depends upon action routine.Action: Figure out whether an adjacency should be formed with the neighboring router (see Section 10.4) 🤔 If not, the neighbor state stays at 2-Way 🛋️ Otherwise, the neighbor state moves to ExStart, and the router does the actions from the Init and 2-WayReceived entry above 🚀
Entry: ExStart or greater, AdjOK? 💔
State(s): ExStart or greater
Event: AdjOK?
New state: Depends upon action routine.Action: Check whether the neighboring router should still be adjacent 🔎 If yes, there's no state change and nothing else is needed 👍
Otherwise, the (possibly partially formed) adjacency must be destroyed 🧨 The neighbor state moves to 2-Way 🔙 The Link state retransmission list, Database summary list and Link state request list all get cleared of LSAs 🧹
Entry: Exchange or greater, SeqNumberMismatch 😱
State(s): Exchange or greater
Event: SeqNumberMismatch
New state: ExStartAction: The (possibly partially formed) adjacency gets torn down, and then the router tries to reestablish it 🔄 The neighbor state first moves to ExStart 🚀 The Link state retransmission list, Database summary list and Link state request list all get cleared of LSAs 🧽 Then the router increments the DD sequence number in the neighbor data structure 🔢 declares itself master (setting the master/slave bit to master) 👑 and starts sending Database Description Packets with the initialize (I), more (M) and master (MS) bits set 🎀 That Database Description Packet should otherwise be empty (see Section 10.8) 🫧
Entry: Exchange or greater, BadLSReq 🙀
State(s): Exchange or greater
Event: BadLSReq
New state: ExStartAction: The BadLSReq action is exactly the same as the SeqNumberMismatch action 👯 The (possibly partially formed) adjacency is torn down, and then the router tries to reestablish it 🔁 For more info, check out the neighbor state machine entry that runs when SeqNumberMismatch is generated in state Exchange or greater 🔍
Entry: Any state, KillNbr 🖤
State(s): Any state
Event: KillNbr
New state: DownAction: The Link state retransmission list, Database summary list and Link state request list all get cleared of LSAs 🧹 The Inactivity Timer also gets disabled ⏹️
Entry: Any state, LLDown 🌧️
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
LSAs. 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
LSAs.
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
LSAs.
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 only get formed with some subset of the router's neighbors, not every single one 💅. Routers on point-to-point networks, Point-to-MultiPoint networks and virtual links always become adjacent 🦋. On broadcast and NBMA networks, every router becomes adjacent to both the Designated Router and the Backup Designated Router 👑.
The adjacency-forming decision happens in two spots inside the neighbor state machine 🧚. The first is when bidirectional communication is first set up with the neighbor, and the second is when the identity of the attached network's (Backup) Designated Router changes. If the router decides NOT to try for an adjacency, the neighbor communication just 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 Point-to-MultiPoint
- 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 walks through exactly how a received Hello Packet gets processed 🔥. (See Section A.3.2 for the format of Hello packets.) The generic input processing of OSPF packets has already checked the validity of the IP header and the OSPF packet header, so we're good there ✨. 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 stops processing and the packet gets dropped 💀. Basically, those fields are describing the attached network's configuration, so they have to match. There is ONE exception though: 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 in the Hello Packet's Options field MUST match this area's ExternalRoutingCapability. If AS-external-LSAs are not flooded into or throughout the area (in other words, the area is a "stub"), the E-bit MUST be clear in received Hello Packets. Otherwise, the E-bit MUST be set. A mismatch stops processing and the packet gets dropped 😭. The rest of the bits in the Hello Packet's Options field SHOULD be ignored 💅.
Now an attempt is made to match the source of the Hello Packet to one of the receiving interface's neighbors 🔍. If the receiving interface connects to a broadcast, Point-to-MultiPoint or NBMA network, the source is identified by the IP source address in the Hello's IP header. If the receiving interface connects to a point-to-point link or a virtual link, the source is identified by the Router ID in the Hello's OSPF packet header. The interface's current list of neighbors lives in the interface's data structure. If no matching neighbor structure can be found (aka this is the first time the neighbor has been detected), one gets created. A newly created neighbor starts out in state Down 🍓.
When receiving a Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, the neighbor structure's Neighbor ID is set equal to the Router ID in the packet's OSPF header 🌈. For these network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are ALSO set equal to the matching fields in the received Hello Packet. Changes in these fields SHOULD be noted for possible use in the steps below ⭐. When receiving a Hello on a point-to-point network (but NOT on a virtual link), the neighbor structure's Neighbor IP address is set to the packet's IP source address 🧚.
Now the rest of the Hello Packet gets examined, generating events for the neighbor and interface state machines 🫶. These state machines are specified to be either executed or scheduled (see Section 4.4). For example, by saying below that the neighbor state machine gets executed in line, a single received Hello can trigger several neighbor state transitions at once 🔥.
- 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, if a change in the neighbor's Router Priority field was noted, the receiving interface's state machine is scheduled with the event
NeighborChange👑. - If the neighbor is declaring itself to be Designated Router (Hello Packet's Designated Router field = Neighbor IP address) AND the Backup Designated Router field in the packet is equal to 0.0.0.0 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 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💖. - If the neighbor is declaring itself to be Backup Designated Router (Hello Packet's 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🌸.
On NBMA networks, receiving a Hello Packet MAY also cause a 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 🦋
Alright, this section breaks down how a received Database Description Packet gets handled 🧚. The incoming packet has already been matched to a neighbor and receiving interface by the generic input packet processing (Section 8.2). Whether the Database Description packet SHOULD be accepted, and if so, how it gets processed further, depends on the neighbor state 💅.
If a Database Description packet is accepted, the following packet fields SHOULD be saved in the matching neighbor data structure under "last received Database Description packet" 📝: the packet's initialize(I), more (M) and master(MS) bits, the Options field, and the DD sequence number. If these fields are set identically in two consecutive Database Description packets received from the neighbor, the second one counts as a "duplicate" in the processing described below 👯.
If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the packet is rejected 😬. Otherwise, the handling depends on the neighbor state:
Down The packet SHOULD be rejected.
Attempt The packet SHOULD be rejected.
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 then continues in this new state by falling through to the ExStart case below ✨.
2-Way The packet SHOULD be ignored. Database Description Packets are used ONLY for the purpose of bringing up adjacencies 🙈.[7]
ExStart If the received packet matches one of the following cases, the neighbor state machine SHOULD be executed with the event NegotiationDone (causing the state to transition to Exchange), the packet's Options field SHOULD be recorded in the neighbor structure's Neighbor Options field, and the packet SHOULD be accepted as next in sequence and processed further (see below). Otherwise, the packet SHOULD be ignored 🔥.
- The initialize(
I), more (M) and master(MS) bits are set, the contents of the packet are empty, and the neighbor's Router ID is larger than the router's own. In this case the router is now Slave. Set the master/slave bit to slave, and set the neighbor data structure's DD sequence number to that specified by the master 👑. - The initialize(
I) and master(MS) bits are off, the packet's DD sequence number equals the neighbor data structure's DD sequence number (indicating acknowledgment) and the neighbor's Router ID is smaller than the router's own. In this case the router is Master 🌈.
Exchange Duplicate Database Description packets are discarded by the master, and cause the slave to retransmit the last Database Description packet that it had sent. Otherwise (the packet is not a duplicate):
- okay so if the state of the
MS-bitdoesn't match the master/slave state of the connection, generate the neighbor eventSeqNumberMismatchand stop processing the packet. 🙅♀️ - if the
initialize(I)bit is set, generate the neighbor eventSeqNumberMismatchand stop processing the packet. 🚫 - if the packet's
Optionsfield shows a different set of optional OSPF capabilities than the ones we got from this neighbor before (recorded in theNeighbor Optionsfield of the neighbor structure), generate the neighbor eventSeqNumberMismatchand stop processing the packet. 🧐 - Database Description packets must be processed in sequence, as shown by their DD sequence numbers. If the router is master, the next packet received should have a DD sequence number equal to the DD sequence number in the neighbor data structure. If the router is slave, the next packet received should have a DD sequence number equal to one more than the DD sequence number stored in the neighbor data structure. Either way, if the packet is the next in sequence, it should be accepted and its contents processed as described below. 🔢✨
- Else, generate the neighbor event
SeqNumberMismatchand 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). Especially, the packet's Options field should match the set of optional OSPF capabilities previously indicated by the neighbor (stored in the neighbor structure's Neighbor Options field). Any other packets received, including a packet 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 it sent. 🔁
When the router accepts a received Database Description Packet as the next in sequence, the packet contents get processed like this. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS-external-LSA (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 up the LSA in its database to see whether it also has an instance of that LSA. If it doesn't, or if the database copy is less recent (see Section 13.1), the LSA 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 in the neighbor data structure. 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 in the neighbor data structure to the DD sequence number 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 how received Link State Request packets get processed in detail. Received Link State Request Packets list the LSAs 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 LSA named in the Link State Request packet should be found in the router's database and copied into Link State Update packets to send to the neighbor. These LSAs should NOT be placed on the Link state retransmission list for the neighbor. If an LSA can't be found in the database, something has gone wrong with the Database Exchange process, and the 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 Database Description packet's Interface MTU field is set to the size of the largest IP datagram that can be sent out the sending interface without fragmentation. Common MTUs in use across the Internet can be found in Table 7-1 of [Ref22]. Interface MTU should be set to 0 in Database Description packets sent over virtual links. 📏
The router's optional OSPF capabilities (see Section 4.5) get sent 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. Only one optional capability is defined in this specification (see Sections 4.5 and A.2). The E-bit should be set if and only if the attached network belongs to a non-stub area. Unrecognized bits in the Options field should be set to zero. 🧩
How Database Description packets get 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 LSA in the area's link-state database (at the moment the neighbor moves into Exchange state) is listed in the neighbor Database summary list. Each new Database Description Packet copies its DD sequence number from the neighbor data structure, then describes the current top of the Database summary list. Items are removed from the Database summary list when the previous packet is acknowledged. 📋✨
In state Exchange, 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 its DD sequence number, or b) RxmtInterval seconds pass 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 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 from the master. For this reason, the slave must wait RouterDeadInterval seconds before freeing the last Database Description packet. If a Database Description packet arrives from the master after this interval, it will generate a SeqNumberMismatch neighbor event. 🙅♀️
10.9. Sending Link State Request Packets 📮
In neighbor states Exchange or Loading, the Link state request list holds the LSAs that still need to be obtained from the neighbor. To request them, a router sends the neighbor the beginning of the Link state request list, packed into a Link State Request packet. 📦
When the neighbor answers 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. LSAs on the Link state request list that have been requested but not yet received get packed into Link State Request packets for retransmission 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 (meaning 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's assumed that RT2 is the Designated Router for the network, and that RT2 has a higher Router ID than Router RT1. 🌈
The neighbor state changes each router goes through are listed on the sides of the figure. 👀
At the beginning of Figure 14, Router RT1's interface to the network becomes operational. It starts sending Hello Packets, even though it doesn't know who the Designated Router is or who any other neighboring routers are. Router RT2 hears this hello (moving the neighbor to Init state), and in its next Hello Packet, it says that it is itself the Designated Router and that it has heard Hello Packets from RT1. This in turn causes RT1 to go to state ExStart, as it starts bringing up the adjacency. 🤝
RT1 begins by asserting itself as the master. When it sees that RT2 really is the master (because of RT2's higher Router ID), RT1 transitions to slave state and adopts its neighbor's DD sequence number. Database Description packets are then exchanged, with polls coming from the master (RT2) and responses from the slave (RT1). So picture this sequence of Database Description
+---+ +---+
|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
<------------------------------
FullFigure 14: An adjacency bring-up example
Okay bestie, the Database Description exchange is officially over once both the poll and its associated response have the M-bit switched off 🙈✨. That's the vibe check that says "we're done talking about our databases, no cap" 💅.
In this example we're assuming RT2 already has a completely up to date database, so RT2 goes straight into Full state 👑. RT1 has some catching up to do. It only hits Full after it updates the parts of its database it's missing 🧚. To do that it sends Link State Request Packets and gets Link State Update Packets back in return 📦. Also, RT1 waited until it had a complete 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've interleaved sending Link State Request Packets with receiving Database Description Packets, which is honestly giving multitasking queen energy 🔥.
11. The Routing Table Structure 🗺️
The routing table data structure holds all the info a router needs to forward an IP data packet toward its destination 💖. Each routing table entry describes the collection of best paths to one particular destination. When a router forwards an IP data packet, it finds the routing table entry that best matches the packet's IP destination. That matching entry then tells it the next hop toward the packet's destination 🦋. OSPF also supports a default route (Destination ID = DefaultDestination, Address Mask = 0x00000000). When the default route exists, it matches every IP destination, although any other matching entry is a better match 🌈. Finding the entry that best matches an IP destination is covered in Section 11.1 🔍.
There's a single routing table in each router 💅. Two sample routing tables are described in Sections 11.2 and 11.3 🎀. Building the routing table is discussed in Section 16 🧚.
The rest of this section defines the fields in a routing table entry. The first set of fields describes the entry's destination ✨.
Destination Type
Destination type is either "network" or "router". Only network entries are actually used when forwarding IP data traffic 🚚. Router routing table entries are only used as intermediate steps in the routing table build process 🛠️.
A network is a range of IP addresses that IP data traffic may be forwarded to. This includes IP networks (class A, B, or C), IP subnets, IP supernets, and single IP hosts 🌸. The default route falls into this category too 🙌.
Router entries are kept for area border routers and AS boundary routers 🏰. Routing table entries for area border routers are used when calculating the inter-area routes (see Section 16.2), and when maintaining configured virtual links (see Section 15) 🔗. Routing table entries for AS boundary routers are used when calculating the AS external routes (see Section 16.4) 🌍.
Destination ID
The destination's identifier or name. This depends on the Destination Type 🪪. For networks, the identifier is their associated IP address. For routers, the identifier is the OSPF Router ID.[9] 💜
Address Mask
Only defined for networks 🎯. The network's IP address together with its address mask defines a range of IP addresses. For IP subnets, the address mask is referred to as the subnet mask 🍓. For host routes, the mask is "all ones" (0xffffffff) 💀.
Optional Capabilities
When the destination is a router, this field indicates the optional OSPF capabilities that the destination router supports ✨. The only optional capability defined by this specification is the ability to process AS-external-LSAs 🫶. For a further discussion of OSPF's optional capabilities, see Section 4.5 📚.
The set of paths to use for a destination may vary based on the OSPF area the paths belong to 🦋. That means there can be multiple routing table entries for the same destination, depending on the values of the next field 🌈.
Area
This field indicates the area whose link state information led to the routing table entry's collection of paths 🗺️. This is called the entry's associated area. For sets of AS external paths, this field isn't defined 🙈. For destinations of type "router", there may be separate sets of paths (and therefore separate routing table entries) associated with each of several areas. For example, this happens when two area border routers share multiple areas in common 👯♀️. For destinations of type "network", only the set of paths associated with the best area (the one providing the preferred route) is kept 👑.
The rest of the routing table entry describes the set of paths to the destination 💅. The following fields pertain to the set of paths as a whole. In other words, each path in a routing table entry has the same path-type and cost (see below) 🎀.
Path-type
There are four possible types of paths used to route traffic to the destination, listed in decreasing order of preference: intra-area, inter-area, type 1 external, or type 2 external 🏆. Intra-area paths indicate destinations belonging to one of the router's attached areas 🏡. Inter-area paths are paths to destinations in other OSPF areas. These are discovered by examining received summary-LSAs 🔎. AS external paths are paths to destinations outside the AS. These are detected by examining received AS-external-LSAs 🌏.
Cost
The link state cost of the path to the destination. For all paths except type 2 external paths, this describes the entire path's cost 💰. For type 2 external paths, this field describes the cost of the portion of the path internal to the AS. This cost is calculated as the sum of the costs of the path's constituent links 🧮.
Type 2 cost
Only valid for type 2 external paths 🌟. For these paths, this field indicates the cost of the path's external portion. This cost has been advertised by an AS boundary router, and it's the most significant part of the total path cost 😤. For example, a type 2 external path with a type 2 cost of 5 is always preferred over a path with a 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 LSA (router-LSA or network-LSA) that directly references the destination. For example, if the destination is a transit network, this is the transit network's network-LSA 🚉. If the destination is a stub network, this is the router-LSA for the attached router 🧱. The LSA is discovered during the shortest-path tree calculation (see Section 16.1) 🌳. Multiple LSAs may reference the destination, but a tie-breaking scheme always reduces the choice to a single LSA 🙌. The Link State Origin field isn't used by the OSPF protocol, but the routing table calculation in OSPF's Multicast routing extensions (MOSPF) does use it 🎀.
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 broadcast, Point-to-MultiPoint, and NBMA networks, the next hop also includes the IP address of the next router (if any) in the path toward the destination 📍.
Advertising router
Valid only for inter-area and AS external paths 📣. This field indicates the Router ID of the router advertising the summary-LSA or AS-external-LSA that led to this path 💌.
11.1. Routing table lookup 🔍
When an IP data packet is received, an OSPF router finds the routing table entry that best matches the packet's destination 📬. That entry then provides the outgoing interface and next hop router to use when forwarding the packet 🚀. This section describes how that best matching entry gets found 💫.
Before the lookup begins, "discard" routing table entries should be inserted into the routing table for each of the router's active area address ranges (see Section 3.5) 🧹. (An area range is considered "active" if the range contains one or more networks reachable by intra-area paths.) The destination of a "discard" entry is the set of addresses described by its associated active area address range, and the path type of each "discard" entry is set to "inter-area".[10] 🗑️
Several routing table entries may match the destination address 🤔. In this case, the "best match" is the routing table entry that provides the most specific (longest) match. Another way of saying this is to choose the entry that specifies the narrowest range of IP addresses.[11] For example, the entry for the address/mask pair of (128.185.1.0, 0xffffff00) is more specific than an entry for the pair (128.185.0.0, 0xffff0000) 🎯. The default route is the least specific match, since it matches all destinations 🌙. (Note that for any single routing table entry, multiple paths may be possible. In these cases, the calculations in Sections 16.1, 16.2, and 16.4 always yield the paths having the most preferential path-type, as described in Section 11) 👑✨
If there is no matching routing table entry, or the best match routing table entry is one of the above "discard" routing table entries, then the packet's IP destination is considered unreachable. Instead of being forwarded, the packet SHOULD then be discarded and an ICMP destination unreachable message SHOULD be returned to the packet's source. 🚫📦
11.2. Sample routing table, without areas ✨
Okay so, picture the Autonomous System from Figure 2. No OSPF areas have been configured, and there's a single metric on each outbound interface. Router RT6's routing table gets calculated the way we covered in Section 2.2, and the result is Table 12. Destination types are abbreviated here: Network is "N" and Router is "R". 💅
There are no instances of multiple equal-cost shortest paths in this example. And since there are no areas, there are no inter-area paths either. Simple, clean, iconic. 🫶
Routers RT5 and RT7 are AS boundary routers. Intra-area routes to RT5 and RT7 have been calculated, which lets external routes get calculated to the destinations they advertise (Networks N12, N13, N14 and N15). It's assumed that all AS-external-LSAs originated by RT5 and RT7 are advertising type 1 external metrics, so type 1 external paths end up being calculated to destinations N12-N15. 🌸
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 *
R RT5 0 intra-area 6 RT5 *
R 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).11.3. Sample routing table, with areas 🧚
Consider the previous example, except this time it's split into OSPF areas. That area configuration is pictured in Figure 6. We're going to look at Router RT4's routing table for this setup. RT4 has a connection to Area 1 and a backbone connection, which means it views the AS as the concatenation of the two graphs shown in Figures 7 and 8. The result 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 entries for the area border router RT3, since it shares two areas with RT4 (Area 1 and the backbone). Two entries, one router, very main character. 👑
Backbone paths have been calculated to all area border routers, and 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 are all condensed into a single route when advertised into the backbone (by Router RT11). The cost of that route is the maximum of the set of costs to its individual components, which is a detail I absolutely love. 🦋
There is a virtual link configured between Routers RT10 and RT11. Without this virtual link, RT11 would be unable to advertise a route for networks N9-N11 and Host H1 into the backbone, and there would not be an entry for these networks in Router RT4's routing table. Virtual link = lifesaver. 🫶
In this example there are two equal-cost paths to Network N12. However, they both use the same next hop (Router RT5). 💖
Router RT4's routing table would improve (i.e., some of the paths in the routing table would become shorter) if an additional virtual link were configured between Router RT4 and Router RT3. The new virtual link would itself be associated with the first entry for area border router RT3 in Table 13 (an intra-area path through Area 1). That would yield a cost of 1 for the virtual link. The routing table entry changes caused by adding this virtual link are shown in Table 14. 🔥
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 *
R RT3 1 intra-area 1 * *
__________________________________________________________________
N Ib 0 intra-area 22 RT5 *
N Ia 0 intra-area 27 RT5 *
R RT3 0 intra-area 21 RT5 *
R RT5 0 intra-area 8 * *
R RT7 0 intra-area 14 RT5 *
R RT10 0 intra-area 22 RT5 *
R RT11 0 intra-area 25 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 36 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. 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 *
R RT3 0 intra-area 1 * *
R RT10 0 intra-area 16 RT3 *
R RT11 0 intra-area 19 RT3 *
________________________________________________________________
N N9-N11,H1 0 inter-area 30 RT3 RT11
Table 14: Changes resulting from an
additional virtual link.12. Link State Advertisements (LSAs) 🌈
Each router in the Autonomous System originates one or more link state advertisements (LSAs). This memo defines five distinct types of LSAs, which are described in Section 4.3. The collection of LSAs forms the link-state database. Each separate type of LSA has its own function. Router-LSAs and network-LSAs describe how an area's routers and networks are interconnected. Summary-LSAs provide a way of condensing an area's routing information. AS-external-LSAs provide a way of transparently advertising externally-derived routing information throughout the Autonomous System. ✨
Each LSA begins with a standard 20-byte header. This LSA header is discussed below. 💜
12.1. The LSA Header 🎀
The LSA header contains the LS type, Link State ID and Advertising Router fields. The combination of these three fields uniquely identifies the LSA. 🔑
There may be several instances of an LSA present in the Autonomous System, all at the same time. It MUST then be determined which instance is more recent. This determination is made by examining the LS sequence, LS checksum and LS age fields. These fields are also contained in the 20-byte LSA header. 🙈
Several of the OSPF packet types list LSAs. When the instance is not important, an LSA is referred to 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. 📚
A detailed explanation of the fields contained in the LSA header follows. 🦋
12.1.1. LS age ⏳
This field is the age of the LSA in seconds. It SHOULD be processed as an unsigned 16-bit integer. It is set to 0 when the LSA is originated. It MUST be incremented by InfTransDelay on every hop of the flooding procedure. LSAs are also aged as they are held in each router's database. ⏰
The age of an LSA is never incremented past MaxAge. LSAs having age MaxAge are not used in the routing table calculation. When an LSA's age first reaches MaxAge, it is reflooded. An LSA of age MaxAge is finally flushed from the database when it is no longer needed to ensure database synchronization. For more information on the aging of LSAs, consult Section 14. 💀
The LS age field is examined when a router receives two instances of an LSA, both having identical LS sequence numbers and LS checksums. An instance of age MaxAge is then always accepted as most recent; this allows old LSAs to be flushed quickly from the routing domain. Otherwise, if the ages differ by more than MaxAgeDiff, the instance having the smaller age is accepted as most recent.[12] See Section 13.1 for more details. 🧹
12.1.2. Options 🍭
The Options field in the LSA header indicates which optional capabilities are associated with the LSA. OSPF's optional capabilities are described in Section 4.5. One optional capability is defined by this specification, represented by the E-bit found in the Options field. The unrecognized bits in the Options field SHOULD be set to zero. 💅✨
12.1. ✨ The E-bit slay
okay bestie, the E-bit is OSPF's ExternalRoutingCapability 💖 It should be set in all LSAs associated with the backbone, and in all LSAs tied to non-stub areas (see Section 3.6) 🌸 It should also be set in all AS-external-LSAs ✨ But it should be reset in all router-LSAs, network-LSAs and summary-LSAs associated with a stub area 🙈 And here's the tea: for every LSA, the E-bit is for informational purposes only. It does not affect the routing table calculation 💅
12.1.3. LS type 🎀
okay so the LS type field is what decides the format and function of an LSA 🦋 That's why LSAs of different types have different names, like router-LSAs or network-LSAs. Every LSA type defined by this memo is flooded throughout a single area only, except the AS-external-LSAs (LS type = 5) 👑 Those get flooded throughout the entire Autonomous System, except for stub areas (see Section 3.6). Each separate LSA 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 LSA is describing 💜 The value of the Link State ID depends on the LSA's LS type, and it takes on the values listed in Table
LS Type LSA description
________________________________________________
1 These are the router-LSAs.
They describe the collected
states of the router's
interfaces. For more information,
consult Section 12.4.1.
________________________________________________
2 These are the network-LSAs.
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-LSAs.
They describe inter-area routes,
and enable the condensation of
routing information at area
borders. Originated by area border
routers, the Type 3 summary-LSAs
describe routes to networks while the
Type 4 summary-LSAs describe routes to
AS boundary routers.
________________________________________________
5 These are the AS-external-LSAs.
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-LSA.Table 15: OSPF link state advertisements (LSAs).
16.
Actually, for Type 3 summary-LSAs (LS type = 3) and AS-external-LSAs (LS type = 5), the Link State ID may
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 LSA's Link State ID.
additionally have one or more of the destination network's "host" bits set 🙈 For example, when originating an AS-external-LSA for the network 10.0.0.0 with mask of 255.0.0.0, the 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 LSAs for two networks that have the same address but different masks. See Appendix E for details 🦋
When the LSA 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 contained in the body of the LSA. When the LSA is 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-LSA (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 LSA's originator 🫶 For router-LSAs, this field is identical to the Link State ID field. Network-LSAs are originated by the network's Designated Router. Summary-LSAs are originated by area border routers. AS-external-LSAs are originated by AS boundary routers.
12.1.6. LS sequence number 🔥
the sequence number field is a signed 32-bit integer, and it's used to detect old and duplicate LSAs 💖 The space of sequence numbers is linearly ordered. The larger the sequence number (when compared as signed 32-bit integers), the more recent the LSA. To describe the sequence number space more precisely, let N refer, in the discussion below, to the constant 2**31 ✨
The sequence number -N (0x80000000) is reserved (and unused) 🙈 This leaves -N + 1 (0x80000001) as the smallest (and therefore oldest) sequence number. This sequence number is referred to as the constant InitialSequenceNumber. A router uses InitialSequenceNumber the first time it originates any LSA. Afterwards, the LSA's sequence number is incremented each time the router originates a new instance of the LSA. When an attempt is made to increment the sequence number past the maximum value of N - 1 (0x7fffffff; also referred to as MaxSequenceNumber), the current instance of the LSA must first be flushed from the routing domain 😭 This is done by prematurely aging the LSA (see Section 14.1) and reflooding it. As soon as this flood has been acknowledged by all adjacent neighbors, a new instance can be originated with sequence number of InitialSequenceNumber 🦋
The router may be forced to promote the sequence number of one of its LSAs when a more recent instance of the LSA is unexpectedly received during the flooding process. This should be a rare event 🌈 It may indicate that an out-of-date LSA, originated by the router itself before its last restart/reload, still exists in 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 LSA, excepting the LS age field. The LS age field is excepted so that an LSA's age can be incremented without updating the checksum 🍓 The checksum used is the same one used for ISO connectionless datagrams, and it's commonly referred to as the Fletcher checksum. It is documented in Annex B of [Ref6]. The LSA header also contains the length of the LSA in bytes. Subtracting the size of the LS age field (two bytes) yields the amount of data to checksum 🎀
The checksum is used to detect data corruption of an LSA. This corruption can occur while an LSA is being flooded, or while it is being held in a router's memory. The LS checksum field cannot take on the value of zero, and the occurrence of such a value should be considered a checksum failure. In other words, calculation of the checksum is not optional 😭
The checksum of an LSA is verified in two cases: a) when it is received in a Link State Update Packet, and b) at times during the aging of the link state database. The detection of a checksum failure leads to separate actions in each case. See Sections 13 and 14 for more details 💅
Whenever the LS sequence number field indicates that two instances of an LSA are the same, the LS checksum field is examined. If there is a difference, the instance with the larger LS checksum is considered to be most recent.[13] 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 💖 All routers belonging to the same area have identical link state databases for that area.
the databases for each individual area are always dealt with separately 🌸 The shortest path calculation is performed separately for each area (see Section 16). Components of the area link-state database are flooded throughout the area only. And when an adjacency (belonging to Area A) is being brought up, only the database for Area A is synchronized between the two routers 🫶
The area database is composed of router-LSAs, network-LSAs and summary-LSAs (all listed in the area data structure). External routes (AS-external-LSAs) are also 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 function is based on an LSA's LS type, Link State ID and Advertising Router.[14] There will be a single instance (the most up-to-date) of each LSA in the database. The database lookup function is invoked during the LSA flooding procedure (Section 13) and the routing table calculation (Section 16). Using this lookup function, the router can also determine whether it has itself ever originated a particular LSA, and if so, with what LS sequence number 🧚
An LSA is added to a router's database when either a) it is received during the flooding process (Section 13), or b) it is originated by the router itself (Section 12.4). An LSA is deleted from a router's database when either a) it has been overwritten by a newer instance during the flooding process (Section 13), or b) the router originates a newer instance of one of its self-originated LSAs (Section 12.4), or c) the LSA ages out and is flushed from the routing domain (Section 14). Whenever an LSA 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
for backward compatibility with previous versions of the OSPF specification ([Ref9]), TOS-specific information can be included in router-LSAs, summary-LSAs and AS-external-LSAs 💜 The encoding of TOS in OSPF LSAs is specified in Table 17. That table relates the OSPF encoding to the IP packet header's TOS field (defined in [Ref12]). The OSPF encoding is expressed as a decimal integer, and the IP packet header's TOS field is expressed in the binary TOS values used in [Ref12] 🎀
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.12.4. Originating LSAs ✨
okay so bestie, every router in an OSPF area is busy originating LSAs 💅🌸 Each router makes a router-LSA, and if it's the Designated Router for any of the area's networks, it also makes network-LSAs for those networks 🫶
Area border routers make one summary-LSA for each known inter-area destination, and AS boundary routers make one AS-external-LSA for each known AS external destination 🦋 Destinations get advertised one at a time, so when one route changes, only that one gets reflooded and not the whole pile of routes 🙈 During flooding, lots of LSAs can ride along in a single Link State Update packet 🚀
Let's look at Router RT4 in Figure 6, because it's giving main character 👑 It's an area border router connected to Area 1 and the backbone. RT4 originates 5 distinct LSAs into the backbone (one router-LSA, plus one summary-LSA for each of the networks N1-N4) 💖 It also originates 8 distinct LSAs into Area 1 (one router-LSA and seven summary-LSAs, as pictured in Figure 7) ✨ And if RT4 gets picked as Designated Router for Network N3, it also originates a network-LSA for N3 into Area 1 🧚
Now in that same figure, Router RT5 is originating 3 distinct AS-external-LSAs (one for each of N12-N14) 🌈 These get flooded through the entire AS, as long as none of the areas are configured as stubs 💀 BUT if area 3 is a stub area, the AS-external-LSAs for N12-N14 do NOT get flooded into area 3 (see Section 3.6) 😭 Instead, Router RT11 originates a default summary-LSA 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 an LSA gets originated, its LS sequence number goes up, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces 🔥 For the details on installing the LSA into the database, see Section 13.2 💅 For flooding newly originated LSAs, see Section 13.3 💖
The ten events that can cause a new instance of an LSA to be originated are:
(1) The LS age field of one of the router's self-originated LSAs reaches the value LSRefreshTime. In this case, a new instance of the LSA gets originated, even though the contents of the LSA (apart from the LSA header) stay the same 🔄 This guarantees periodic originations of all LSAs, and that periodic updating adds robustness to the link state algorithm 🛡️ LSAs that solely describe unreachable destinations should not be refreshed, and should instead be flushed from the routing domain (see Section 14.1) 🗑️
When whatever an LSA describes changes, a new LSA gets originated 🌟 BUT two instances of the same LSA may not be originated within the time period MinLSInterval 🙅 This may mean the next instance gets delayed by up to MinLSInterval ⏳ The following events may change the contents of an LSA. These events should cause new originations if and only if the contents of the new LSA would be different ✨
(2) An interface's state changes (see Section 9.1). This may mean a new instance of the router-LSA is needed 🦋
(3) An attached network's Designated Router changes. A new router-LSA should be originated 💫 Also, if the router itself is now the Designated Router, a new network-LSA should be produced 🌸 If the router itself is no longer the Designated Router, any network-LSA 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 or from the FULL state. This may mean a new instance of the router-LSA is needed 💜 Also, if the router is itself the Designated Router for the attached network, a new network-LSA should be produced 🫶
The next four events concern area border routers ONLY 🚨
(5) An intra-area route has been added, deleted, or modified in the routing table. This may cause a new instance of a summary-LSA (for this route) to be originated in each attached area, possibly including the backbone 🌈
(6) An inter-area route has been added, deleted, or modified in the routing table. This may cause a new instance of a summary-LSA (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-LSAs 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-LSA into the virtual link's Transit area (see the discussion of the router-LSA's bit V in Section 12.4.1), as well as originating a new router-LSA 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 BGP) changes. This will cause an AS boundary router to originate a new instance of an AS-external-LSA 🌐
(10) A router ceases to be an AS boundary router, perhaps after restarting. In this situation the router MUST flush all AS-external-LSAs that it had previously originated. These LSAs can be flushed via the premature aging procedure specified in Section 14.1 🧹✨
The construction of each type of LSA is explained in detail below 📖 In general, these sections describe the contents of the LSA body (the part coming after the 20-byte LSA header). For info on building the LSA header, see Section 12.1 💕
12.4.1. Router-LSAs 🏠
A router originates a router-LSA for each area that it belongs to 🌷 Such an LSA describes the collected states of the router's links to the area. The LSA is 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 shownThe format of a router-LSA is shown in Appendix A (Section A.4.2) 📐 The first 20 bytes of the LSA are the generic LSA header that was discussed in Section 12.1 🧩 router-LSAs have LS type = 1 🔢
A router also says whether it's an area border router or an AS boundary router, by setting the appropriate bits (bit B and bit E, respectively) in its router-LSAs 🚩 This lets paths to those types of routers get saved in the routing table, for later processing of summary-LSAs and AS-external-LSAs 🗺️ Bit B should be set whenever the router is actively attached to two or more areas, even if the router isn't currently attached to the OSPF backbone area 🌍 Bit E should NEVER be set in a router-LSA for a stub area, because stub areas can't contain AS boundary routers 🙅
Also, the router sets bit V in its router-LSA for Area A if and only if the router is the endpoint of one or more fully adjacent virtual links having Area A as their Transit area 🚇 Setting bit V lets other routers in Area A figure out whether the area supports transit traffic (see TransitCapability in Section 6) 🔍
The router-LSA then describes the router's working connections (interfaces or links) to the area 🔌 Each link is typed according to the kind of attached network 🏷️ Each link also gets labelled with its Link ID 🪪 This 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-LSA.In addition, the Link Data field is specified for each link, and it gives 32 bits of extra info for that link 🎀 For links to transit networks, numbered point-to-point links, and virtual links, it holds the IP interface address of the associated router interface. The routing table calculation needs this one, so check out Section 16.1.1 🧠 For links to stub networks, it holds the stub network's IP address mask. For unnumbered point-to-point links, the Link Data field should be set to the unnumbered interface's MIB-II [Ref8] ifIndex value 🦋
Last but not least, the cost of using the link for output is specified. The output cost is configurable ⚙️ Except for links to stub networks, the output cost must always be non-zero 🔥
So how does a router actually build the list of link descriptions? Say a router wants to build a router-LSA for Area A. It checks out its collection of interface data structures, and for each interface it does this:
- If the attached network does not belong to Area A, no links are added to the LSA, and the next interface should be examined. 🙅♀️
- If the state of the interface is Down, no links are added.
- 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 point-to-point network. 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. 🪞
- Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for virtual links in Section 12.4.1.2, for broadcast and NBMA interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4. 🗺️
After the router has looked at all its interfaces, it adds host links to the router-LSA by checking the list of attached hosts that belong to Area A. A host route shows up as a Type 3 link (stub network). Its Link ID is the host's IP address, its Link Data is the all-ones mask (0xffffffff), and its cost is the host's configured cost (see Section C.7) 💅
12.4.1.1. Describing point-to-point interfaces
For point-to-point interfaces, one or more link descriptions get added to the router-LSA like this:
- If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For 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 [Ref8] ifIndex value. The cost should be set to the output cost of the point-to-point interface. 💌
- In addition, as long as the state of the interface is "Point-to-Point" (and regardless of the neighboring router state), a Type 3 link (stub network) should be added. This stub link can take one of two forms:
- Option 1: Assuming that the neighboring router's IP address is known, set the Link ID of the Type 3 link to the neighbor's IP address, the Link Data to the mask 0xffffffff (indicating a host route), and the cost to the interface's configured output cost.[15] 🎯
- Option 2: If a subnet has been assigned to the point-to-point link, set the Link ID of the Type 3 link to the subnet's IP address, the Link Data to the subnet's mask, and the cost to the interface's configured output cost.[16] 🧁
12.4.1.2. Describing broadcast and NBMA interfaces
For operational broadcast and NBMA interfaces, you add a single link description to the router-LSA like this:
- If the state of the interface is Waiting, add a Type 3 link (stub network) with Link ID set to the IP network number of the attached network, Link Data set to the attached network's address mask, and cost equal to the interface's configured output cost. ⏳
- Else, a Designated Router has been elected 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) with Link ID set to the IP interface address of the attached network's Designated Router (which may be the router itself), Link Data set to the router's own IP interface address, and cost equal to the interface's configured output cost. Otherwise, add a link as if the interface state were Waiting (see above). 🤝
12.4.1.3. Describing virtual links
For virtual links, a link description gets added to the router-LSA only when the virtual neighbor is fully adjacent. In that case, add a Type 4 link (virtual link) with Link ID set to the Router ID of the virtual neighbor, Link Data set to the IP interface address associated with the virtual link, and cost set to the cost calculated for the virtual link during the routing table calculation (see Section 15). 🌈
12.4.1.4. Describing Point-to-MultiPoint interfaces
For operational Point-to-MultiPoint interfaces, one or more link descriptions get added to the router-LSA like this:
- A single Type 3 link (stub network) is added with Link ID set to the router's own IP interface address, Link Data set to the mask 0xffffffff (indicating a host route), and cost set to 0. 🌸
- For each fully adjacent neighbor associated with the interface, add an additional Type 1 link (point-to-point) with Link ID set to the Router ID of the neighboring router, Link Data set to the IP interface address, and cost equal to the interface's configured output cost. 🫶
12.4.1.5. Examples of router-LSAs
Let's look at the router-LSAs generated by Router RT3, as pictured in Figure 6. The area that contains Router RT3 (Area 1) has been redrawn with actual network addresses in Figure 15. Assume the last byte of all of RT3's interface addresses is 3, giving it the interface addresses 192.1.1.3 and 192.1.4.3, and that the other routers have similar addressing schemes. Also assume that all links are functional, and that Router IDs are assigned as the smallest IP interface address 💜
RT3 originates two router-LSAs, 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-LSA for Area 1 is shown below. It says RT3 has two connections to Area 1: a link to the transit network 192.1.1.0 and a link to the stub network 192.1.4.0. Note that the transit network is identified by the IP interface of its Designated Router (so the Link ID = 192.1.1.4, which is Designated Router RT4's IP interface to 192.1.1.0). Also note that RT3 has indicated that it is an area border router 👑
; RT3's router-LSA for Area 1
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
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
# TOS metrics = 0
metric = 1
Link ID = 192.1.4.0 ;IP Network number
Link Data = 0xffffff00 ;Network mask
Type = 3 ;connects to stub network
# TOS metrics = 0
metric = 2Next up is RT3's router-LSA for the backbone. It shows RT3 has a single attachment to the backbone. That attachment is an unnumbered point-to-point link to Router RT6. RT3 has again indicated that it is an area border router 🧚
; RT3's router-LSA for the backbone
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 1 ;indicates router-LSA
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
# TOS metrics = 0
metric = 812.4.2. Network-LSAs
A network-LSA is generated for every transit broadcast or NBMA network. (A transit network is a network having two or more attached routers.) The network-LSA describes all the routers attached to the network 🌐
The Designated Router for the network originates the LSA. The Designated Router originates the LSA only if it is fully adjacent to at least one other router on the network. The network-LSA is flooded throughout the area that contains the transit network, and no further. The network-LSA lists the routers that are fully adjacent to the Designated Router, and each fully adjacent router is identified by its OSPF Router ID. The Designated Router includes itself in this list 🦋
Okay so, the Link State ID for a network-LSA is literally the IP interface address of the Designated Router 💅 Mask it with the network's address mask (which is also sitting inside the network-LSA) and boom, you get the network's IP address ✨
Now, a router that used to be the DR for a network but isn't anymore has to clean up after itself 🧹 That old network-LSA is no longer used in the routing table calculation, so it gets flushed by bumping the LSA's age up to MaxAge and reflooding it (see Section 14.1). 🫠 And in those rare cases where a router's Router ID changes, any network-LSAs that were originated under the old Router ID must be flushed too. The router might not even remember its old Router ID 💀, so those LSAs are spotted by having their Link State ID match one of the router's IP interface addresses while their Advertising Router is some value other than the router's current Router ID (see Section 13.4 for more details).
12.4.2.1. Examples of network-LSAs
Okay, picture the area configuration in Figure 6 again 🗺️ Network-LSAs get originated for Network N3 in Area 1, Networks N6 and N8 in Area 2, and Network N9 in Area 3. Say Router RT4 got picked as the Designated Router for Network N3. Then RT4 generates this network-LSA on behalf of Network N3 (see Figure 15 for the address assignments) 🎀
; Network-LSA for Network N3
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 2 ;indicates network-LSA
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-LSAs
Summary-LSAs are giving "I'm outside your area but still in the AS" energy 🦋 The destination described by one is either an IP network, an AS boundary router, or a range of IP addresses. They're flooded throughout a single area only 🌸
Area border routers are the ones who originate summary-LSAs 👑 The exact summary routes to advertise into an area come from looking at the routing table structure (see Section 11) and following the algorithm below. Note that only intra-area routes get advertised into the backbone, while both intra-area and inter-area routes get advertised into the other areas 💜
So, to figure out which routes to advertise into an attached Area A, each routing table entry gets processed like this. Remember that each routing table entry describes a set of equal-cost best paths to a particular destination 🧠
- Only Destination Types of network and AS boundary router are advertised in summary-LSAs. If the routing table entry's Destination Type is area border router, examine the next routing table entry.
- AS external routes are never advertised in summary-LSAs. If the routing table entry has Path-type of type 1 external or type 2 external, examine the next routing table entry.
- Else, if the area associated with this set of paths is the Area A itself, do not generate a summary-LSA for the route.[17]
- Else, if the next hops associated with this set of paths belong to Area A itself, do not generate a summary-LSA for the route.[18] This is the logical equivalent of a Distance Vector protocol's split horizon logic. 🪞
- Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route.
- Else, if the destination of this route is an AS boundary router, a summary-LSA should be originated if and only if the routing table entry describes the preferred path to the AS boundary router (see Step 3 of Section 16.4). If so, a Type 4 summary-LSA is originated 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. Note: these LSAs 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 summary-LSA 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 E for details) and metric equal to the routing table cost. 📬
- The one remaining case is an intra-area route to a network. This means that the network is contained in one of the router's directly attached areas. In general, this information must be condensed before appearing in summary-LSAs. Remember that an area has a configured list of address ranges, each range consisting of an [address,mask] pair and a status indication of either
AdvertiseorDoNotAdvertise. At most a single Type 3 summary-LSA is originated for each range. When the range's status indicatesAdvertise, a Type 3 summary-LSA 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 E for details) and cost equal to the largest cost of any of the component networks. When the range's status indicatesDoNotAdvertise, the Type 3 summary-LSA is suppressed and the component networks remain hidden from other areas. 🫣
By default, if a network is not contained in any explicitly configured address range, a Type 3 summary-LSA 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 E for details) and metric equal to the network's routing table cost 🌈
If an area is capable of carrying transit traffic (i.e., its TransitCapability is set to TRUE), routing information concerning backbone networks should not be condensed before being summarized into the area. Nor should the advertisement of backbone networks into transit areas be suppressed. In other words, the backbone's configured ranges should be ignored when originating summary-LSAs into transit areas. 🚌
If a router advertises a summary-LSA for a destination which then becomes unreachable, the router must then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Also, if the destination is still reachable, yet can no longer be advertised according to the above procedure (e.g., it is now an inter-area route, when it used to be an intra-area route associated with some non-backbone area; it would thus no longer be advertisable to the backbone), the LSA should also be flushed from the routing domain. 🗑️
12.4.3.1. Originating summary-LSAs 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-LSAs into the area according to the Section 12.4.3's algorithm, or they can choose to originate only a subset of the summary-LSAs, possibly under configuration control. The fewer LSAs originated, the smaller the stub area's link state database, which further reduces the demands on its routers' resources. However, omitting LSAs may also lead to sub-optimal inter-area routing, although routing will continue to function 🤷♀️
As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary-LSAs) are never originated into stub areas 🚫
In a stub area, instead of importing external routes, each area border router originates a "default summary-LSA" into the area 🎯 The Link State ID for the default summary-LSA is set to DefaultDestination, and the metric is set to the (per-area) configurable parameter StubDefaultCost. Note that StubDefaultCost need not be configured identically in all of the stub area's area border routers 🫶
12.4.3.2. Examples of summary-LSAs
Okay, let's revisit the area configuration in Figure 6 🗺️ Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, so they're the ones originating summary-LSAs. Let's zoom in on Router RT4 🔍 Its routing table was calculated as in the example in Section 11.3. RT4 originates summary-LSAs into both the backbone and Area 1. Into the backbone, RT4 originates separate LSAs for each of the networks N1-N4. Into Area 1, RT4 originates separate LSAs for networks N6-N8 and the AS boundary routers RT5, RT7. It also condenses host routes Ia and Ib into a single summary-LSA. Finally, the routes to networks N9, N10, N11 and Host H1 are advertised by a single summary-LSA. This condensation was originally performed by the router RT11 ✨
These LSAs are illustrated graphically in Figures 7 and 8. Two of the summary-LSAs originated by Router RT4 follow. The actual IP addresses for the networks and routers in question have been assigned in Figure 15 💖
; Summary-LSA for Network N1,
; originated by Router RT4 into the backbone
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 3 ;Type 3 summary-LSA
Link State ID = 192.1.2.0 ;N1's IP network number
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 4; Summary-LSA for AS boundary router RT7
; originated by Router RT4 into Area 1 LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 4 ;Type 4 summary-LSA
Link State ID = Router RT7's ID
Advertising Router = 192.1.1.4 ;RT4's ID
metric = 1412.4.4. AS-external-LSAs ✨
Okay bestie, AS-external-LSAs describe routes to destinations outside the Autonomous System 🌍 Most of them point at specific external destinations, and for those the Link State ID is set to the destination network's IP address. If needed, the Link State ID can also have one or more of the network's "host" bits set, so peek at Appendix E for the details 🧚 But here's the cute part: a default route for the whole AS can be described too, just by setting the Link State ID to DefaultDestination (0.0.0.0) 🎀 AS-external-LSAs are originated by AS boundary routers, and each AS boundary router makes one AS-external-LSA for every external route it has learned, whether that's through another routing protocol (like BGP) or through configuration information 💅
Main character energy alert 🚨 AS-external-LSAs are the only LSAs that get flooded throughout the entire Autonomous System. Every other type of LSA stays in its own area 🏠 But AS-external-LSAs are not flooded into or throughout stub areas (see Section 3.6). Bye bye, extra clutter! This makes the link state database smaller for routers sitting inside stub areas 🙈
The metric advertised for an external route can be one of two types. Type 1 metrics are comparable to the link state metric. Type 2 metrics are assumed to be larger than the cost of any intra-AS path. Type 1 is the friend who's basically on the same level as everyone else, and Type 2 is the one who's always assumed to be bigger 👑
If a router advertises an AS-external-LSA for a destination that then becomes unreachable, the router MUST then flush the LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Sorry LSA, it's time to go 😭
12.4.4.1. Examples of AS-external-LSAs 🎀
Consider once again the AS pictured in Figure 6 🗺️ There are two AS boundary routers: RT5 and RT7. Router RT5 originates three AS-external-LSAs, for networks N12-N14. Router RT7 originates two AS-external-LSAs, for networks N12 and N15. Let's say RT7 has learned its route to N12 via BGP, and it wants to advertise a Type 2 metric to the AS. RT7 would then originate the following LSA for N12:
; AS-external-LSA for Network N12,
; originated by Router RT7
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = N12's IP network number
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
metric = 2
Forwarding address = 0.0.0.0In the above example, the forwarding address field has been set to 0.0.0.0, which tells everyone that packets for the external destination should be forwarded to the advertising OSPF router (RT7). Cute, but this isn't always desirable 🙃 Consider the example pictured in Figure 16 🖼️ There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of these routers, RTA, is exchanging BGP information with the non-OSPF router RTX. So RTA has to originate AS-external-LSAs for those destinations it learned from RTX. By using the AS-external-LSA's forwarding address field, RTA can specify that packets for these destinations be forwarded directly to RTX. Without this feature, Routers RTB and RTC would take an extra hop to reach these destinations. Extra hops? Nah 🙅♀️
Note that when the forwarding address field is non-zero, it SHOULD point to a router belonging to another Autonomous System. Good manners, babe 💖
A forwarding address can also be specified for the default route. For example, in Figure 16, RTA may want to specify that all externally-destined packets should by default be forwarded to its BGP peer RTX. The resulting AS-external-LSA is pictured below. Notice the Link State ID is set to DefaultDestination 💜
; Default route, originated by Router RTA
; Packets forwarded through RTX
LS age = 0 ;always true on origination
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = DefaultDestination ; default route
Advertising Router = Router RTA's ID
bit E = 1 ;Type 2 metric
metric = 1
Forwarding address = RTX's IP addressOkay, now let's say that in Figure 16, both RTA and RTB exchange BGP information with RTX. In this case, RTA and RTB would originate the same set of AS-external-LSAs 😬 If those LSAs specify the same metric, they'd be functionally equivalent, since they'd specify the same destination and forwarding address (RTX). That's a clear duplication of effort 🙄 If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would stay the same and the link state database would shrink. The catch is that it has to be unambiguously defined which router originates the LSAs, otherwise neither might, or the identity of the originator might oscillate 🌀 So the following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used. The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1. Highest Router ID wins, iykyk 👑
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+Figure 16: Forwarding address example 🦋
13. The Flooding Procedure 🌊
Okay so LSAs spread around the network through Link State Update packets 💌 A single Link State Update packet can contain several distinct LSAs, and it floods each LSA one hop further from where it started. To make flooding reliable, every LSA has to be acknowledged separately 🤝 Those acknowledgments travel in Link State Acknowledgment packets, and many separate acknowledgments can also be grouped together into one packet ✨
The flooding procedure starts when a Link State Update packet has been received. A bunch of consistency checks happen on the packet before it gets handed over to the flooding procedure (see Section 8.2). Specifically, the Link State Update packet has been associated with a particular neighbor and a particular area. If the neighbor is in a lesser state than Exchange, the packet SHOULD be dropped without further processing 🙅♀️
All types of LSAs, other than AS-external-LSAs, are associated with a specific area. Plot twist: LSAs don't have an area field 🙈 So an LSA's area MUST be deduced from the Link State Update packet header.
For each LSA contained in a Link State Update packet, the following steps are taken:
- Validate the LSA's LS checksum. If the checksum turns out to be invalid, discard the LSA and get the next one from the Link State Update packet.
- Examine the LSA's LS type. If the LS type is unknown, discard the LSA and get the next one from the Link State Update Packet. This specification defines LS types 1-5 (see Section 4.3).
- Else if this is an AS-external-LSA (LS type = 5), and the area has been configured as a stub area, discard the LSA and get the next one from the Link State Update Packet. AS-external-LSAs are not flooded into or throughout stub areas (see Section 3.6).
- Else if the LSA's LS age is equal to MaxAge, and there is currently no instance of the LSA in the router's link state database, and none of router's neighbors are in states Exchange or Loading, then take the following actions:
- a) Acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back to the sending neighbor (see Section 13.5), and
- b) Discard the LSA and examine the next LSA (if any) listed in the Link State Update packet.
- Otherwise, find the instance of this LSA that is currently contained in the router's link state database. If there is no database copy, or the received LSA is more recent than the database copy (see Section 13.1 below for the determination of which LSA is more recent) the following steps MUST be performed:
- (a) If there is already a database copy, and if the database copy was received via flooding and installed less than
MinLSArrivalseconds ago, discard the new LSA (without acknowledging it) and examine the next LSA (if any) listed in the Link State Update packet. - (b) Otherwise immediately flood the new LSA out some subset of the router's interfaces (see Section 13.3). In some cases (e.g., the state of the receiving interface is DR and the LSA was received from a router other than the Backup DR) the LSA will be flooded back out the receiving interface. This occurrence SHOULD be noted for later use by the acknowledgment process (Section 13.5).
- (c) Remove the current database copy from all neighbors' Link state retransmission lists.
- (d) Install the new LSA in the link state database (replacing the current database copy). This may cause the routing table calculation to be scheduled. In addition, timestamp the new LSA with the current time (i.e., the time it was received). The flooding procedure cannot overwrite the newly installed LSA until
MinLSArrivalseconds have elapsed. The LSA installation process is discussed further in Section 13.2. - (e) Possibly acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5.
- (a) If there is already a database copy, and if the database copy was received via flooding and installed less than
(f) okay so if this new LSA says it was originated by the receiving router itself (aka it's a self-originated LSA), the router MUST take special action. That means either updating the LSA or, in some cases, flushing it from the routing domain. 💅 For how self-originated LSAs get detected and handled, see Section 13.4. 🪞
(6) Else, if there's an instance of the LSA on the sending neighbor's Link state request list, something went wrong in the Database Exchange process 😭. In that case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor, and stop processing the Link State Update packet. 🚫
(7) Else, if the received LSA is the same instance as the database copy (neither one is more recent), the following two steps SHOULD be performed:
(a) If the LSA is on the Link state retransmission list for the receiving adjacency, the router itself is waiting for an acknowledgment for this LSA. The router SHOULD treat the received LSA as an acknowledgment by removing the LSA 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 LSA by sending a Link State Acknowledgment packet back out the receiving interface. This is explained below in Section 13.5. 💌
(8) Else, the database copy is more recent. If the database copy has LS age equal to MaxAge and LS sequence number equal to MaxSequenceNumber, just discard the received LSA without acknowledging it. (In this case the LSA's LS sequence number is wrapping, and the MaxSequenceNumber LSA MUST be completely flushed before any new LSA instance can be introduced 🌀.) Otherwise, as long as the database copy hasn't been sent in a Link State Update within the last MinLSArrival seconds, send the database copy back to the sending neighbor, encapsulated within a Link State Update packet. The Link State Update packet SHOULD be sent directly to the neighbor. While doing this, do not put the database copy of the LSA on the neighbor's link state retransmission list, and do not acknowledge the received (less recent) LSA instance. 🫶
13.1. Determining which LSA is newer ✨
When a router runs into two instances of an LSA, it MUST determine which one is more recent. 👀 This already came up above when comparing a received LSA to its database copy. The same comparison MUST also be done during the Database Exchange procedure that happens during adjacency bring-up.
An LSA is identified by its LS type, Link State ID and Advertising Router. For two instances of the same LSA, the LS sequence number, LS age and LS checksum fields decide which one is more recent:
- The LSA with the newer LS sequence number is more recent. See Section 12.1.6 for an explanation of the LS sequence number space. If both instances have the same LS sequence number, then:
- If the two instances have different LS checksums, the instance with the larger LS checksum (when read as a 16-bit unsigned integer) is considered more recent.
- Else, if only one of the instances has its LS age field set to MaxAge, the instance of age MaxAge 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 LSAs in the database 🗂️
Installing a new LSA in the database, whether it came from flooding or was newly self-originated, may cause the OSPF routing table structure to be recalculated. 🔄 The contents of the new LSA SHOULD be compared to the old instance, if one is present. If there's no difference, there's no need to recalculate the routing table. When comparing an LSA to its previous instance, the following all count as differences in contents:
- The LSA's Options field has changed.
- One of the LSA instances has LS age set to MaxAge, and the other doesn't.
- The length field in the LSA header has changed.
- The body of the LSA (i.e., anything outside the 20-byte LSA header) has changed. Note that this excludes changes in LS Sequence Number and LS Checksum.
If the contents are different, the following pieces of the routing table MUST be recalculated, depending on the new LSA's LS type field:
Router-LSAs and network-LSAs The entire routing table MUST be recalculated, starting with the shortest path calculations for each area (not just the area whose link-state database has changed). 🌳 The reason the shortest path calculation can't be restricted to the single changed area has to do with the fact that AS boundary routers may belong to multiple areas. A change in the area currently providing the best route may force the router to use an intra-area route provided by a different area.[19]
Summary-LSAs The best route to the destination described by the summary-LSA MUST be recalculated (see Section 16.5). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs. 🔍
AS-external-LSAs The best route to the destination described by the AS-external-LSA MUST be recalculated (see Section 16.6). 🛣️
Also, any old instance of the LSA MUST be removed from the database when the new LSA is installed. 🧹 This 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) LSA has been received, it MUST be flooded out some set of the router's interfaces. 🚀 This section covers the second part of the flooding procedure (the first part was the processing in Section 13). That part is about selecting the outgoing interfaces and adding the LSA to the appropriate neighbors' Link state retransmission lists. The maintenance of the neighbors' Link state request lists is also part of this step.
This section applies just as much to flooding an LSA that the router has itself just originated (see Section 12.4). For those LSAs, this section gives the entire flooding procedure (the processing in Section 13 isn't performed, since, for example, the LSA wasn't received from a neighbor and so doesn't need to be acknowledged). 🙅♀️
Depending on the LSA's LS type, the LSA can be flooded out only certain interfaces. These interfaces, called the eligible interfaces, are defined as follows:
AS-external-LSAs (LS Type = 5) AS-external-LSAs are 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 those 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 those interfaces attaching to Area A. If Area A is the backbone, this includes all the virtual links. 🌸
Link state databases MUST remain synchronized over all adjacencies associated with the eligible interfaces above. 🔗 This is done by running the following steps on each eligible interface. It should be noted that this procedure MAY decide not to flood an LSA out a particular interface if there's a high probability that the attached neighbors have already received the LSA. However, in those cases the flooding procedure MUST be absolutely sure that the neighbors eventually do receive the LSA, so the LSA is still added to each adjacency's Link state retransmission list. For each eligible interface:
(1) Each of the neighbors attached to this interface is examined to determine whether it MUST receive the new LSA. The following steps are run for each neighbor:
(a) If the neighbor is in a lesser state than Exchange, it doesn't take part in flooding, and the next neighbor SHOULD be examined. 🙈
(b) Else, if the adjacency isn't yet full (neighbor state is Exchange or Loading), examine the Link state request list associated with this adjacency. If there's an instance of the new LSA on the list, it means the neighboring router already has an instance of the LSA. Compare the new LSA to the neighbor's copy:
- If the new LSA is less recent, examine the next neighbor.
- If the two copies are the same instance, delete the LSA from the Link state request list, and examine the next neighbor. [20]
- Else, the new LSA is more recent. Delete the LSA from the Link state request list.
(c) If the new LSA was received from this neighbor, examine the next neighbor. 🔁
(d) At this point we aren't positive the neighbor has an up-to-date instance of this new LSA. Add the new LSA to the Link state retransmission list for the adjacency. This makes the flooding procedure reliable: the LSA will be retransmitted at intervals until an acknowledgment is seen from the neighbor. 🔁✨
(2) The router now has to decide whether to flood the new LSA out this interface. If in the previous step the LSA was NOT added to any of the Link state retransmission lists, there's no need to flood the LSA out the interface, and the next interface SHOULD be examined. 🙅
(3) If the new LSA was received on this interface, and it was received from either the Designated Router or the Backup Designated Router, chances are all the neighbors have already received the LSA. So examine the next interface. 🤝
(4) If the new LSA was received on this interface, and the interface state is Backup (i.e., the router itself is the Backup Designated Router), examine the next interface. The Designated Router will do the flooding on this interface. However, if the Designated Router fails, the router (i.e., the Backup Designated Router) will end up retransmitting the updates. 🛟
(5) okay so if we've made it to this step, the LSA has to get flooded out the interface 📮✨. Send a Link State Update packet (with the new LSA as its contents) out the interface. The LSA's LS age MUST be incremented by InfTransDelay (which MUST be > 0) when it gets copied into the outgoing Link State Update packet 💅. This keeps going until the LS age field hits the max value of MaxAge 🫶.
On broadcast networks, the Link State Update packets get multicast 🦋. The destination IP address depends on the interface state. If the interface state is DR or Backup, the address AllSPFRouters SHOULD be used. Otherwise, the address AllDRouters SHOULD be used 🌸.
On non-broadcast networks, separate Link State Update packets MUST be sent as unicasts to each adjacent neighbor (aka anyone in state Exchange or higher) 💌. The destination IP addresses for these packets are the neighbors' IP addresses 🎀.
13.4. Receiving self-originated LSAs ✨
It's literally a common occurrence for a router to get its own self-originated LSAs back through the flooding procedure 🙈. An LSA 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-LSA and its Link State ID is equal to one of the router's own IP interface addresses 🧚.
BUT, if the received self-originated LSA is newer than the last instance the router actually originated, the router MUST take special action 🚨. Getting one of these means there are LSAs floating around the routing domain that the router originated before its last restart 💀. In most cases, the router MUST then advance the LSA's LS sequence number one past the received LS sequence number, and originate a new instance of the LSA 🔥.
Now, sometimes the router just doesn't want to originate the received LSA anymore 🙅♀️. Possible examples include: 1) the LSA is a summary-LSA or AS-external-LSA and the router no longer has an (advertisable) route to the destination, 2) the LSA is a network-LSA but the router is no longer Designated Router for the network, or 3) the LSA is a network-LSA whose Link State ID is one of the router's own IP interface addresses but whose Advertising Router is not equal to the router's own Router ID. That last one SHOULD be rare, and it means the router's Router ID changed since it originated the LSA 👀. In all these cases, instead of updating the LSA, the LSA SHOULD be flushed from the routing domain by incrementing the received LSA's LS age to MaxAge and reflooding (see Section 14.1) 🗑️✨.
13.5. Sending Link State Acknowledgment packets 💌
Each newly received LSA MUST be acknowledged 🫶. This is usually done with Link State Acknowledgment packets. But acknowledgments can also happen implicitly by sending Link State Update packets (see step 7a of Section 13) 🪄.
Lots of acknowledgments can get grouped into a single Link State Acknowledgment packet 📦. That packet gets sent back out the interface that received the LSAs. It can go out in one of two ways: delayed and sent on an interval timer, or sent directly to a particular neighbor 🍓. Which strategy is used depends on what's going on when the LSA arrives 👑.
Delayed acks are giving multiple vibes 💜: 1) they make it easy to package a bunch of acknowledgments together in one packet, 2) one Link State Acknowledgment packet can cover acknowledgments for several neighbors at once (through multicasting), and 3) they randomize the Link State Acknowledgment packets sent by the various routers attached to a common network 🎲. The fixed interval between a router's delayed transmissions MUST be short (less than RxmtInterval), or needless retransmissions will ensue 😭.
Direct acks go straight to a particular neighbor in response to getting a duplicate LSA 🎯. They're sent immediately when the duplicate shows up. On multi-access networks, these acks go directly to the neighbor's IP address 📬.
The exact procedure for sending Link State Acknowledgment packets is in Table 19 🗂️. The circumstances around getting the LSA are in the left column, and the ack action is in one of the two right columns. That action depends on the state of the interface, and interfaces in state Backup act differently from everyone else 🫠. 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 the interface state is DR or Backup, the destination AllSPFRouters is used. In all other states, the destination AllDRouters is used. On non-broadcast networks, delayed Link State Acknowledgment packets MUST be unicast separately over each adjacency (i.e., each neighbor whose state is >= Exchange) 💅.
Action taken in state
Circumstances Backup All other states
_________________________________________________________________
LSA has No acknowledgment No acknowledgment
been flooded back sent. sent.
out receiving in-
terface (see Sec-
tion 13, step 5b).
_________________________________________________________________
LSA 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
_________________________________________________________________
LSA 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
_________________________________________________________________
LSA is a Direct acknowledg- Direct acknowledg-
duplicate, and was ment sent. ment sent.
not treated as an
implied ack-
nowledgment.
_________________________________________________________________
LSA's LS Direct acknowledg- Direct acknowledg-
age is equal to ment sent. ment sent.
MaxAge, and there is
no current instance
of the LSA
in the link state
database, and none
of router's neighbors
are in states Exchange
or Loading (see
Section 13, step 4).
Table 19: Sending link state acknowledgements.The reasoning for sending those packets as multicasts is easiest to see with an example 🧠. Check out 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 LSA to Network N3, RT1, RT2, and RT3 all receive it 📨. These routers won't flood the LSA back onto net N3, but they still MUST ensure their link-state databases stay synchronized with their adjacent neighbors 🥹. So RT1, RT2, and RT4 are waiting to see an acknowledgment from RT3 👀. And RT4 and RT3 are both waiting to see acknowledgments from RT1 and RT2 💖. The best way to pull that off is multicasting the acks 🦋.
The logic for Backup DRs is a little different because they behave differently during LSA flooding (see Section 13.3, step 4) ✨.
13.6. Retransmitting LSAs 🔁
LSAs flooded out an adjacency get placed on that adjacency's Link state retransmission list 📋. To keep flooding reliable, these LSAs keep getting 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 flooding in the face of lost packets may be affected 🐢.
Several retransmitted LSAs MAY fit into a single Link State Update packet 🧩. When LSAs are being retransmitted, only the number that fits in a single Link State Update packet SHOULD be sent 📏. Another packet of retransmissions can go out whenever some of the LSAs get acknowledged, or on the next firing of the retransmission timer ⏭️.
Link State Update packets carrying retransmissions are always sent directly to the neighbor 🎯. On multi-access networks, that means retransmissions go straight to the neighbor's IP address 📬. Each LSA'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 the maximum value of MaxAge) ⏳.
If an adjacent router goes down, retransmissions MAY occur until OSPF's Hello Protocol destroys the adjacency 🕰️. When the adjacency is destroyed, the Link state retransmission list gets cleared 🧹✨.
13.7. Receiving link state acknowledgments 🫶
A bunch of consistency checks happen on a received Link State Acknowledgment packet before it gets handed to the flooding procedure 🔍. Most importantly, it's been associated with a particular neighbor. If that neighbor is in a state lower than Exchange, the Link State Acknowledgment packet gets discarded 🗑️.
Otherwise, for each acknowledgment in the Link State Acknowledgment packet, these steps happen 🧚:
- Does the LSA being acknowledged have an instance on the Link state retransmission list for the neighbor? If not, check the next acknowledgment. Otherwise:
- If the acknowledgment is for the same instance that's on the list, remove the item from the list and check the next acknowledgment. Otherwise:
- Log the questionable acknowledgment, and check the next one.
That's the whole flooding ack story, bestie 💜✨ More of this document is coming, so stay tuned 🧚
14. Aging The Link State Database ✨
okay so every LSA has an LS age field 🎀 and it's measured in seconds. the LS age ticks up while the LSA is sitting in a router's database. and when the LSA gets copied into a Link State Update Packet to flood out a particular interface, its LS age also goes up by InfTransDelay 💅
an LSA's LS age never goes past MaxAge. LSAs with age MaxAge are not used in the routing table calculation 🙈 as a router ages its link state database, an LSA's LS age can hit MaxAge.[21] when that happens, the router MUST attempt to flush the LSA from the routing domain. the way it does this is by reflooding the MaxAge LSA like it's a brand new LSA (see Section 13.3) 🦋
when a router is making a Database summary list for a newly forming adjacency, any MaxAge LSAs in the link state database get added to the neighbor's Link state retransmission list instead of the neighbor's Database summary list. see Section 10.3 for the deets 🫶
a MaxAge LSA MUST be removed from the router's link state database immediately once both 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. no lingering zombies 💀
and when aging the database, whenever an LSA's LS age hits a multiple of CheckAge, its LS checksum SHOULD be verified. if the checksum is wrong, a program or memory error has been detected, and at the very least the router itself SHOULD be restarted 😭
14.1. Premature aging of LSAs
so an LSA can be flushed from the routing domain by setting its LS age to MaxAge, leaving its LS sequence number alone, and then reflooding it 🌸 this follows the same course as flushing an LSA whose LS age naturally reached MaxAge (see Section 14). the MaxAge LSA 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 LSA's LS age to MaxAge "premature aging" 💜
premature aging is used when it's time for a self-originated LSA's sequence number field to wrap. at that point the current LSA instance (with LS sequence number MaxSequenceNumber) MUST be prematurely aged and flushed from the routing domain before a new instance with sequence number equal to InitialSequenceNumber can be originated. see Section 12.1.6 for more 🍓
premature aging can also be used when, say, one of the router's previously advertised external routes is no longer reachable. in that case the router can flush its AS-external-LSA from the routing domain via premature aging. this is preferable to the alternative, which is originating a new LSA for the destination with a metric of LSInfinity. premature aging is also used when the router unexpectedly receives self-originated LSAs during the flooding procedure (see Section 13.4) ⭐
a router MAY only prematurely age its own self-originated LSAs. the router may not prematurely age LSAs originated by other routers. an LSA 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-LSA 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) can't be disconnected, or some areas of the Autonomous System become unreachable 😱 so 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. the virtual link MUST 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 have in common, called the Transit area. virtual links can't be configured through stub areas (see Section 3.6) 🙅♀️
the virtual link is treated as if it were an unnumbered point-to-point network that belongs to the backbone and joins the two area border routers. an attempt is made to establish an adjacency over it. once that adjacency is up, the virtual link is included in backbone router-LSAs, and OSPF packets for the backbone area flow over the adjacency. this document calls that adjacency a "virtual adjacency" 💖
in each endpoint router, the cost and viability of the virtual link are discovered by looking at the routing table entry for the other endpoint router (that entry's associated area MUST be the configured Transit area). this is called the virtual link's corresponding routing table entry. the InterfaceUp event occurs for a virtual link when its corresponding routing table entry becomes reachable, and InterfaceDown occurs when it becomes unreachable. basically the virtual link's viability depends on whether 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-LSA) SHOULD be considered inoperational, which means it gets treated the same as if the path didn't exist 🫠
here are the other virtual link details, bestie 👑
- AS-external-LSAs are NEVER flooded over virtual adjacencies. that would just be duplicated effort, since the same AS-external-LSAs are already flooded throughout the virtual link's Transit area. for the same reason, AS-external-LSAs are not summarized over virtual adjacencies during the Database Exchange process 💅
- the cost of a virtual link is NOT configured. it's defined to be 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-LSA SHOULD be originated for the backbone area 🎀
- the routing table build process determines the virtual link's cost and viability (through building the routing table entry for the other endpoint), and it also determines the IP interface address for the virtual interface and the virtual neighbor's IP address. those are used when sending OSPF protocol packets over the virtual link. heads up though: when one (or both) of the virtual link endpoints connects to the Transit area via 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, and that can make the virtual link fail 🙈
- in each endpoint's backbone router-LSA, the virtual link is represented 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 🦋
- a non-backbone area can carry transit data traffic (so it's considered a "transit area") if and only if it serves as the Transit area for one or more fully adjacent virtual links (see TransitCapability in Sections 6 and 16.1) ✨ a transit area needs special treatment when backbone networks get summarized into it (see Section 12.4.3), and during the routing calculation (see Section 16.3) 🧚
- 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 breaks down the OSPF routing table calculation 💅 using its attached areas' link state databases as input, a router runs the algorithm below and builds its routing table step by step. at each step the router MUST access individual pieces of the link state databases (like a router-LSA originated by a certain router). that access happens through the lookup function discussed in Section 12.2. the lookup can return an LSA whose LS age is equal to MaxAge. an LSA like that SHOULD NOT be used in the routing table calculation, and it's treated just as if the lookup had failed 😭
the OSPF routing table's organization is explained in Section 11, and two examples of the build process are in Sections 11.2 and 11.3. the whole thing breaks into these steps:
(1) first, the present routing table gets invalidated, and the table is built again from scratch. the old routing table is saved so that changes to routing table entries can be identified 🫶
(2) next, intra-area routes get calculated by building the shortest-path tree for each attached area. in particular, every routing table entry whose Destination Type is "area border router" gets calculated in this step. this step has two parts. first the tree is built by only considering links between routers and transit networks. then the stub networks get added to the tree. during the area's shortest-path tree calculation, the area's TransitCapability is also calculated for use later in Step 4 🍓
(3) then the inter-area routes are calculated by examining summary-LSAs. if the router is attached to multiple areas (so it's an area border router), only backbone summary-LSAs are examined ⭐
(4) in area border routers connected to one or more transit areas (non-backbone areas whose TransitCapability is TRUE), the transit areas' summary-LSAs get examined to see whether better paths exist through the transit areas than were found in Steps 2-3 above 🌈
(5) last, routes to external destinations are calculated by examining AS-external-LSAs. the locations of the AS boundary routers (which originate the AS-external-LSAs) were determined in Steps 2-4 💖
Steps 2-5 get explained in more detail below. any changes to routing table entries from these calculations can make OSPF take further actions. for example, a change to an intra-area route makes an area border router originate new summary-LSAs (see Section 12.4). see Section 16.7 for the full list of OSPF protocol actions that result from routing table changes 👑
16.1. Calculating the shortest-path tree for an area
okay bestie so this is where the router finally does its big shortest-path glow-up 💅✨ it works out the set of intra-area routes for an area (we're calling it Area A 🦋). the router is the root of its own tree 🌳, and the whole thing happens in two stages. stage one only looks at routers and transit networks, and runs Dijkstra to build a tree out of that subset of the link state database 🧠. stage two is the cute part, where stub networks get tacked on as leaves 🍃
so the database is a directed graph (we're using the terms from Section 2, obviously 🙈). the vertices are routers, transit networks, and stub networks. stage one only cares about the transit vertices (routers + transit networks) and the links connecting them 🔗. each transit vertex carries a few things with it the whole time:
Vertex (node) ID a 32-bit number that, together with the vertex type (router or network), uniquely identifies the vertex 🪪 for router vertices it's the router's OSPF Router ID. for network vertices it's the IP address of the network's Designated Router. 💖
An LSA every transit vertex has an LSA attached. for routers that's a router-LSA. for transit networks it's a network-LSA, which is actually originated by that network's Designated Router. either way the LSA's Link State ID is always the same as the Vertex ID above 🫶
List of next hops the next hops for the current set of shortest paths from the root to this vertex. there can be more than one because of equal-cost multipath 🌈 each next hop tells you which outgoing router interface to use when forwarding to the destination. on broadcast, Point-to-MultiPoint and NBMA 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. a path's cost is the sum of the costs of its links (as advertised in router-LSAs and network-LSAs) 💸 one path is "shorter" than another if it has a smaller link state cost. no cap, that's the whole game 👑
okay so the stage one Dijkstra thing basically goes like this 🏃♀️💨. at every iteration there's a list of candidate vertices. paths to them have been found, but they might not be the shortest yet. BUT the candidate closest to the root is guaranteed to have a shortest path, so that one gets moved into the tree, removed from the candidate list, and its neighbors get checked to be added to or updated on the list. then it loops again. it stops when the candidate list is empty. ✨
here are the steps in detail. remember we're computing the tree for Area A, and every link state database lookup below is against Area A's database 🦋
(1) set up the algorithm's data. clear the candidate list 🧹. start the shortest-path tree with only the root (the router doing the calculation). set Area A's TransitCapability to FALSE 🙅♀️
(2) the vertex that was just added to the tree is now called vertex V. look at its LSA, which means looking it up in Area A's link state database by Vertex ID 🔍. if it's a router-LSA and bit V of that router-LSA (see Section A.4.2) is set, set Area A's TransitCapability to TRUE ✅. either way, each link in the LSA gives the cost to an adjacent vertex. for each link (say it joins vertex V to vertex W):
(a) if it's a link to a stub network, skip to the next link in V's LSA. stub links get handled in stage two 🍓
(b) otherwise W is a transit vertex (router or transit network). look up W's LSA (router-LSA or network-LSA) in Area A's database. if that LSA doesn't exist, or its LS age is equal to MaxAge, or it doesn't have a link back to vertex V, move on to the next link in V's LSA.[23] 🚫
(c) if vertex W is already on the shortest-path tree, move on to the next link in the LSA. it's already been handled, bestie 🙈
(d) work out the link state cost D of the path from the root to vertex W. D is the cost of the already-calculated shortest path to V plus the advertised cost of the link between V and W 🧮 then:
- if D is greater than the value already listed for W on the candidate list, examine the next link. no thanks 🙅♀️
- if D is equal to the value listed for W on the candidate list, calculate the set of next hops you get from using this link. the inputs are the destination (W) and its parent (V), and that calculation is in Section 16.1.1. those hops should be added to the next hop values already listed for W on the candidate list 🤝
- if D is less than the value listed for W on the candidate list, or W isn't on the candidate list yet, set W's entry on the candidate list to a distance of D from the root. also calculate the next hops from using this link and set W's next hop values to match. the calculation is described in Section 16.1.1, using the destination (W) and its parent (V) as inputs. this is the glow-up moment 💅⭐
(3) if the candidate list is empty at this step, the shortest-path tree of transit vertices is fully built and stage one is done 🎉. otherwise, pick the candidate closest to the root, add it to the tree, and remove it from the candidate list. when two vertices are equally close to the root, network vertices have to be picked before router vertices so you definitely find all the equal-cost paths 🧩. this matches the tie-breakers from the modified Dijkstra used by OSPF's Multicast routing extensions (MOSPF) 🌸
(4) possibly update the routing table 📝. for any routing table entries that get changed, the associated area is set to Area A, the path type is intra-area, and the cost is set to the new shortest path's distance.
if the newly added vertex is an area border router or AS boundary router, add a routing table entry with destination type "router". copy the Options field from its router-LSA into the entry's Optional capabilities field 💁♀️ call that new vertex Router X. if Router X is the endpoint of one of the calculating router's virtual links, and that virtual link uses Area A as its Transit area, then the virtual link is declared up 🆙. the IP address of the virtual interface gets set to the IP address of the outgoing interface calculated above for Router X 🎯. and the virtual neighbor's IP address gets set to Router X's interface address (from Router X's router-LSA) that points back toward the root of the shortest-path tree. equivalently, that's the interface pointing back to Router X's parent vertex on the tree, similar to the calculation in Section 16.1.1 🔁
if the newly added vertex is a transit network, find its routing table entry. the Destination ID is the IP network number, which you get by masking the Vertex ID (Link State ID) with the subnet mask from the body of the network-LSA 🎀. if an entry already exists (so there's already an intra-area route to that destination in the table), then multiple vertices have mapped to the same IP network. this can happen when a new Designated Router is being set up, for example 👀 in that case the current entry should only be overwritten if the newly found path is just as short AND the current entry's Link State Origin has a smaller Link State ID than the newly added vertex's LSA. 😤 both have to be true, no exceptions
if there's no entry for the network (the usual case 🥰), add a routing table entry for the IP network. its Link State Origin should be set to the newly added vertex's LSA 🌷
(5) loop back to Step 2 and keep going ✨🔄
the stub networks get added to the tree in stage two 🌲. here all the router vertices get checked again. any that were found to be unreachable in stage one get thrown out 🗑️. for each reachable router vertex (call it V), find its router-LSA in the link state database. then check each stub network link in that LSA, and run these steps:
(1) work out the distance D from the root to the stub network. D is the distance from the root to router vertex V (from stage one) 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 the calculated D is larger, just move on to the next stub network link in the LSA 🙅♀️
(2) Okay, so if we've reached this step, the stub network's routing table entry has to get updated, no skipping! 💅 Calculate the set of next hops you'd get by using the stub network link. The how-to is in Section 16.1.1, and the inputs are the destination (the stub network) and the parent vertex (the router vertex). If the distance 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. The routing table already has a Link State Origin in this case. If that Link State Origin is a router-LSA whose Link State ID is smaller than V's Router ID, reset the Link State Origin to V's router-LSA. 🦋
Otherwise D is smaller than the routing table cost, so it's a glow-up! ✨ Overwrite the current entry by setting its cost to D and its list of next hops to the newly calculated set. Set the entry's Link State Origin to V's router-LSA. Then go on to examine the next stub network link. 🌸
For all routing table entries added or modified in the second stage, the associated area is set to Area A and the path type is set to intra-area. 🍓 When the list of reachable router-LSAs runs out, the second stage is complete, and at that point every intra-area route associated with Area A has been determined. Iconic. 👑
The spec doesn't require the two-stage method to calculate the shortest path tree. Still, if you use a different algorithm, you have to end up with an identical tree 🙈 So links between transit vertices must be bidirectional to be included in the tree. Also, more efficient algorithms exist for calculating the tree, like the incremental SPF algorithm described in [Ref1]. Lowkey a brain-hurty topic, but so worth it. 🧚
16.1.1. The next hop calculation
This section explains how to work out the current set of next hops to use for a destination. Each next hop is made of the outgoing interface to use when forwarding packets to the destination, plus the IP address of the next hop router (if there is one). The next hop calculation runs every time a shorter path to the destination is found. That can happen in either stage of the shortest-path tree calculation (see Section 16.1). In stage 1, a shorter path shows 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 is 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, since shorter and shorter paths keep turning up. In the end, the destination's routing table entry always reflects the next hops from the absolute shortest path(s). Main character energy 👑
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 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 just inherits the set of next hops from the parent. Otherwise there are two cases. 🎀
In the first case, the parent vertex is the root (the calculating router itself). That means the destination is either a directly connected network or a directly connected router. The outgoing interface is simply the OSPF interface connecting to the destination network or router. If the destination is a router that connects to the calculating router via a Point-to-MultiPoint network, the destination's next hop IP address(es) can be found by examining the destination's router-LSA. Each link pointing back to the calculating router, with a Link Data field belonging to the Point-to-MultiPoint network, gives an IP address of the next hop router. If the destination is a directly connected network, or a router that connects to the calculating router via a point-to-point interface, no next hop IP address is needed. If the destination is a router connected to the calculating router via 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-LSA. For each link in the router-LSA 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 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 get calculated by examining summary-LSAs. If the router has active attachments to multiple areas, only backbone summary-LSAs are examined. Routers attached to a single area examine that area's summary-LSAs. Either way, the summary-LSAs examined below are all part of a single area's link state database (call it Area A). 🌈
Summary-LSAs are originated by the area border routers. Each summary-LSA in Area A gets considered in turn. Remember that the destination described by a summary-LSA is either a network (Type 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). For each summary-LSA:
(1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the next LSA. 💀
(2) If the LSA was originated by the calculating router itself, examine the next LSA. 🙈
(3) If it's a Type 3 summary-LSA, and the collection of destinations described by the summary-LSA equals one of the router's configured area address ranges (see Section 3.5), and that area address range is active, then the summary-LSA should be ignored. "Active" means there are one or more reachable (by intra-area paths) networks contained in the area range. Not the main thing to overthink, but it matters. 🧚
(4) Otherwise, call the destination described by the LSA N (for Type 3 summary-LSAs, N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA), and call the area border router originating the LSA BR. Look up the routing table entry for BR that has Area A as its associated area. If no such entry exists (meaning BR is unreachable in Area A), do nothing with this LSA and consider the next one in the list. Otherwise, this LSA describes an inter-area path to destination N, whose cost is the distance to BR plus the cost specified in the LSA. Call the cost of this inter-area path IAC. 🍓
(5) Next, look up the routing table entry for the destination N. (If N is an AS boundary router, look up the "router" routing table entry associated with Area A.) If no entry exists for N, or if the entry's path type is "type 1 external" or "type 2 external", then install the inter-area path to N, with 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) Otherwise, if the paths present in the table are intra-area paths, do nothing with the LSA. Intra-area paths are always preferred, periodt. 👑
(7) Otherwise, the paths present in the routing table are also inter-area paths. Install the new path through BR if it's cheaper, overriding the paths in the routing table. Otherwise, if the new path is the same cost, add it to the list of paths that appear in the routing table entry. 💅
16.3. Examining transit areas' summary-LSAs
This step is only performed by area border routers attached to one or more non-backbone areas that are capable of carrying transit traffic (that is, "transit areas", or those areas whose TransitCapability parameter has been set to TRUE in Step 2 of the Dijkstra algorithm (see Section 16.1)). 🦋
The point of the calculation below is to check the transit areas and see whether they offer any better (shorter) paths than the ones calculated in Sections 16.1 and 16.2. Any paths found that are better than or equal to previously discovered paths get installed in the routing table. ✨
The calculation also works out the actual next hop(s) for those destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. After the calculation below is done, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded. 🌸
The calculation goes like this. All the transit areas' summary-LSAs get examined in turn. Each one describes a route through a transit area Area A to a network N (N's address is obtained by masking the LSA's Link State ID with the network/subnet mask contained in the body of the LSA), or, in the case of a Type 4 summary-LSA, to an AS boundary router N. Suppose also that the summary-LSA was originated by an area border router BR. 🍓
(1) If the cost advertised by the summary-LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the next LSA. 💀
(2) If the summary-LSA was originated by the calculating router itself, examine the next LSA. 🙈
(3) Look up the routing table entry for N. (If N is an AS boundary router, look up the "router" routing table entry associated with the backbone area.) If it does not 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 LSA. 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 is unreachable, examine the next LSA. 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 LSA. Call this cost IAC. 💖
(5) Okay so this is the big one 👀 If this cost is less than the cost already sitting in N's routing table entry, you 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, you just add BR's next hops to N's list. In any case, the area on N's routing table entry must remain the backbone area, and the path type (intra-area or inter-area) must also stay the same 💅
Here's the tea 🫖 The calculation above never makes unreachable destinations reachable. It only finds better paths to places that are already reachable ✨ Any better cost it finds gets installed into the routing table entry, and from there it can get readvertised in summary-LSAs to other areas. Iconic, honestly 🦋
Let's do an example, bestie 🎀 Picture the Autonomous System in Figure 17. There's one 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 RT1 and RT4. On the right side of the figure, Network N1 belongs to the backbone. The dotted lines show there's a way shorter intra-area backbone path between RT5 and Network N1 (cost 20) than between RT4 and Network N1 (cost 100). Both RT4 and RT5 inject summary-LSAs 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 areasAfter the backbone SPT is calculated in Section 16.1, RT1 (the left end of the virtual link) has a path through RT4 for all data traffic headed to Network N1 🙃 But RT5 is way closer to N1, so every router inside Area 1 (like RT2 and RT3) sends its N1 traffic toward RT5 instead of RT4. And yep, after running Area 1's summary-LSAs through the calculation above, RT1 also forwards N1 traffic toward RT5 💖 Real talk: in this example the virtual link lets transit traffic travel through Area 1, but the actual path the traffic takes doesn't have to follow the virtual link. Virtual links allow transit traffic to be forwarded through an area, but they don't dictate the exact path it takes 🧚
16.4. Calculating AS external routes ✨
AS external routes get calculated by examining AS-external-LSAs, one at a time 🌸 Most AS-external-LSAs describe routes to specific IP destinations. An AS-external-LSA can also describe a default route for the Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000). For each AS-external-LSA:
(1) If the cost in the LSA is LSInfinity, or the LSA's LS age is equal to MaxAge, skip it and look at the next LSA 🙈
(2) If the LSA was originated by the calculating router itself, skip it and examine the next LSA.
(3) Call the destination described by the LSA N. N's address comes from masking the LSA's Link State ID with the network/subnet mask in the body of the LSA. Then look up the routing table entries (potentially one per attached area) for the AS boundary router (ASBR) that originated the LSA. If there are no entries for ASBR (aka ASBR is unreachable), do nothing with this LSA and move on to the next one in the list 💀
Otherwise, this LSA describes an AS external path to destination N. Check the forwarding address in the AS-external-LSA. This is the IP address packets for the destination should be forwarded to 🦋
If the forwarding address is 0.0.0.0, packets should be sent to the ASBR itself. Among the multiple routing table entries for the ASBR, pick the preferred one like this. If RFC1583Compatibility is set to "disabled", prune the set of routing table entries for the ASBR as described in Section 16.4.1. In any case, among what's left, pick the entry with the least cost. If there's a tie on least cost, the entry whose associated area has the largest OSPF Area ID (read as an unsigned 32-bit integer) wins 🏆
If the forwarding address is non-zero, look it up in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path. If no such path exists, do nothing with the LSA and consider the next one in the list 🫶
(4) Let X be the cost given by the preferred routing table entry for the ASBR/forwarding address, and Y the cost in the LSA. X is in terms of the link state metric, and Y is a type 1 or 2 external metric 🔥
(5) Look up the routing table entry for destination N. If there's no entry, 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 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 ✨
(6) Compare the AS external path described by the LSA with the existing paths in N's routing table entry, like this. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal preference, it gets added to N's list of paths 💜
(a) Intra-area and inter-area paths are always preferred over AS external paths 👑
(b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred 💅
(c) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, and RFC1583Compatibility is set to "disabled", pick the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1 🌈
(d) If the new AS external path is still indistinguishable from the current paths in N's routing table entry, pick the preferred path with a least cost comparison. Type 1 external paths get 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 advertising equal type 2 metrics get compared by looking at the distance to the forwarding addresses 🍓
16.4.1. External path preferences 🧁
When there are multiple intra-AS paths to ASBRs/forwarding addresses, the rules below say which paths are preferred. These rules apply when the same ASBR is reachable through multiple areas, or when you're trying to decide which of several AS-external-LSAs should win. In the first case the paths all end at the same ASBR, while in the second they end at separate ASBRs/forwarding addresses. Either way, each path is represented by its own routing table entry, as defined in Section 11 🦋
This section only applies when RFC1583Compatibility is set to "disabled" 🙃
The path preference rules, from highest to lowest preference, go like this. Heads up: because of these rules there can still be multiple paths at the highest preference. If that happens, the path to use gets decided by cost, as described in Section 16.4 💖
- Intra-area paths using non-backbone areas are always the most preferred.
- The other paths, intra-area backbone paths and inter-area paths, are of equal preference.
16.5. Incremental updates -- summary-LSAs ✨
When a new summary-LSA shows up, you don't have to recalculate the entire routing table 🙌 Call the destination described by the summary-LSA N (N's address comes from masking the LSA's Link State ID with the network/subnet mask in the body of the LSA), and let Area A be the area the LSA belongs to. There are then two separate cases 👀
Okay so Case 1 is when Area A is the backbone and/or the router is not an area border router 🦋 Bestie, this one is a whole thing. In this case, the following calculations must be performed. First, if there's already an inter-area route to destination N, N's routing table entry gets invalidated, but we save its values so we can compare later 👀 Then the calculation in Section 16.2 runs again for just that one destination N. During this step, we look at all of Area A's summary-LSAs that describe a route to N. 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 too 💅
If those results changed the cost or path to an AS boundary router (like with a Type 4 summary-LSA) or to any forwarding addresses, then all AS-external-LSAs will 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, just in case an alternate external route to N exists 🫶
Case 2: Area A is a transit area and the router is an area border router. 🌈 In this case, the following calculations must be performed. First, if N's routing table entry currently 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 routing table entry, the entry should be invalidated. The entry's old values should be saved for later comparisons ✨ 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 from Section 16.1. Like, the whole thing, periodt 💀
Otherwise, if the cost or path to an AS boundary router (like a Type 4 summary-LSA) or to any forwarding addresses has changed, all AS-external-LSAs will 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-LSAs 🎀
When a new AS-external-LSA shows up, we don't have to recalculate the entire routing table, which is such a relief 😭 Call the destination described by that AS-external-LSA N. N's address comes from masking the LSA's Link State ID with the network/subnet mask in the body of the LSA. If there's already an intra-area or inter-area route to the destination, no recalculation is necessary, because internal routes take precedence 💖
Otherwise, the procedure in Section 16.4 will have to be performed, but only for those AS-external-LSAs whose destination is N. Before this procedure runs, the present routing table entry for N should be invalidated 🌸
16.7. Events generated as a result of routing table changes 🦋
Changes to routing table entries sometimes make the 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 isn't just a change to AS external routes, new summary-LSAs 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 LSA must be flushed from the routing domain by setting its
LS agetoMaxAgeand reflooding (see Section 14.1) 🫠 - A routing table entry associated with a configured virtual link has changed. The destination of such a routing table 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, the corresponding virtual link is now operational. An InterfaceUp event should be generated for the virtual link, which causes a virtual adjacency to begin to form (see Section 10.3). At this point, 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, the virtual link and its associated adjacency should be destroyed. This means an InterfaceDown event 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-LSA for the backbone must be originated. This in turn may cause further routing table changes. It's giving domino effect 🍓
16.8. Equal-cost multipath 💜
The OSPF protocol keeps track of multiple equal-cost routes to all destinations. You can see this in the steps we used above to calculate the routing table, and in the definition of the routing table structure 👑
Each one of the multiple routes will be of the same type (intra-area, inter-area, type 1 external or type 2 external) and cost, and will have the same associated area. However, each route may specify a separate next hop and Advertising router 🫶
There is 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 ✨
Footnotes ✨
[1] okay so the graph's vertices can represent routers, transit networks, or stub networks 🌸 and since routers can belong to multiple areas, it's literally not possible to color the graph's vertices 🎨
[2] it's possible for ALL of a router's interfaces to be unnumbered point-to-point links 🙈 in that case an IP address must be assigned to the router. That address then gets advertised in the router's router-LSA as a host route 🧚
[3] note that in these cases both interfaces, the non-virtual and the virtual, would have the same IP address 👀
[4] no host route is generated for interfaces to unnumbered point-to-point networks, and no IP packets can be addressed to them 🚫 this is true regardless of that interface's state 💀
[5] this one's such a good example 🔍 it's instructive to see what happens when the Designated Router for the network crashes. Call the Designated Router RT1 and the Backup Designated Router RT2. If RT1 crashes (or maybe its interface to the network dies), the other routers on the network will detect RT1's absence within RouterDeadInterval seconds. Not everyone notices at precisely the same time 😅 so the routers that detect RT1's absence before RT2 does will, for a time, select RT2 to be both Designated Router and Backup Designated Router. When RT2 detects that RT1 is gone, it moves itself to Designated Router. At this point, the remaining router with the highest Router Priority gets selected as Backup Designated Router 👑
[6] on point-to-point networks, the lower level protocols indicate whether the neighbor is up and running 🙌 existence of the neighbor on virtual links is indicated by the routing table calculation. But in both cases the Hello Protocol still gets used 💜 it makes sure communication between the neighbors is bidirectional, and that each neighbor has a functioning routing protocol layer 🫶
[7] when the identity of the Designated Router is changing, it may be pretty common for a neighbor in this state to send the router a Database Description packet 📦 that means there's some momentary disagreement about who the Designated Router is 🤷♀️
[8] it's possible for a router to resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart 🔄 this causes the other end of the adjacency to process a SeqNumberMismatch event, and therefore to also go back to ExStart state 👯
[9] the address space of IP networks and the address space of OSPF Router IDs may overlap 🌈 so a network may have an IP address that's identical (when considered as a 32-bit number) to some router's Router ID 😳
[10] "Discard" entries are necessary to make sure route summarization at area boundaries won't cause packet looping 🔁
[11] it's assumed that, for two different address ranges matching the destination, one range is more specific than the other. Non-contiguous subnet masks can be configured to violate this assumption 🙅 and such subnet mask configurations can't be handled by the OSPF protocol 💔
[12] MaxAgeDiff is an architectural constant 🏛️ it indicates the maximum dispersion of ages, in seconds, that can occur for a single LSA instance as it gets flooded throughout the routing domain. If two LSAs differ by more than this, they're assumed to be different instances of the same LSA. This can happen when a router restarts and loses track of the LSA's previous LS sequence number. See Section 13.4 for more details.
[13] when two LSAs have different LS checksums, they're assumed to be separate instances 🧩 this can happen when a router restarts and loses track of the LSA's previous LS sequence number. In the case where the two LSAs have the same LS sequence number, it's not possible to determine which LSA is actually newer 🤔 however, if the wrong LSA is accepted as newer, the originating router will simply originate another instance 🫠 See Section 13.4 for further details.
[14] there is one instance where a lookup must be done based on partial information 🔎 this happens during the routing table calculation, when a network-LSA must be found based solely on its Link State ID. The lookup is still well defined, though, since no two network-LSAs can have the same Link State ID 💅
[15] this is the way RFC 1583 specified point-to-point representation 📜 it has three advantages: a) it does not require allocating a subnet to the point-to-point link, b) it tends to bias the routing so that packets destined for the point-to-point interface will actually be received over the interface (which is useful for diagnostic purposes), and c) it allows network bootstrapping of a neighbor, without requiring that the bootstrap program contain an OSPF implementation 🥾
[16] this is the more traditional point-to-point representation, used by protocols such as RIP 👴
[17] this clause covers the case: inter-area routes are not summarized to the backbone. This is because inter-area routes are always associated with the backbone area 🦋
[18] this clause is only invoked when a non-backbone Area A supports transit data traffic (i.e., has TransitCapability set to TRUE). For example, in the area configuration of Figure 6, Area 2 can support transit traffic due to the configured virtual link between Routers RT10 and RT11. As a result, Router RT11 need only originate a single summary-LSA into Area 2 (having the collapsed destination N9-N11,H1), since all of Router RT11's other eligible routes have next hops belonging to Area 2 itself (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7). 🧠
[19] by keeping more information in the routing table, it's possible for an implementation to recalculate the shortest path tree for only 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 [Ref1]. However, these algorithms are beyond the scope of this specification.
[20] this is how the Link state request list gets emptied, which eventually causes the neighbor state to transition to Full. See Section 10.9 for more details. 🏁
[21] it should be a relatively rare occurrence for an LSA's LS age to reach MaxAge in this fashion. Usually, the LSA will be replaced by a more recent instance before it ages out ⏳
[22] strictly speaking, because of equal-cost multipath, the algorithm does not create a tree 🌲 we keep using the "tree" terminology because that's what shows up most in the existing literature 📚
[23] note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W. This is enough to ensure that, before data traffic flows between a pair of neighboring routers, their link state databases will be synchronized 🔗
[24] when the forwarding address is non-zero, it should point to a router belonging to another Autonomous System. See Section 12.4.4 for more details. 🌍
References 📚
Here's every reference, exactly as written, so nothing gets lost 🎀
[Ref1] McQuillan, J., I. Richer and E. Rosen, "ARPANET Routing
Algorithm Improvements", BBN Technical Report 3803, April
1978.
[Ref2] Digital Equipment Corporation, "Information processing
systems -- Data communications -- Intermediate System to
Intermediate System Intra-Domain Routing Protocol", October
1987.
[Ref3] McQuillan, J., et.al., "The New Routing Algorithm for the
ARPANET", IEEE Transactions on Communications, May 1980.
[Ref4] Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", Computer Networks, December 1983.
[Ref5] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP
8073", RFC 905, April 1984.
[Ref7] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, May 1988.
[Ref8] McCloghrie, K., and M. Rose, "Management Information Base
for network management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[Ref9] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC1519, September 1993.
[Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[Ref12] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[Ref13] Leiner, B., et.al., "The DARPA Internet Protocol Suite", DDN
Protocol Handbook, April 1985.
[Ref14] Bradley, T., and C. Brown, "Inverse Address Resolution
Protocol", RFC 1293, January 1992.
[Ref15] deSouza, O., and M. Rodrigues, "Guidelines for Running OSPF
Over Frame Relay Networks", RFC 1586, March 1994.
[Ref16] Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp. 32-38, April 1989.
[Ref17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[Ref18] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[Ref19] Coltun, R., and V. Fuller, "The OSPF NSSA Option", RFC 1587,
March 1994.
[Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in
progress.
[Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[Ref22] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[Ref23] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[Ref24] Hinden, R., "Internet Routing Protocol Standardization
Criteria", BBN, October 1991.
[Ref25] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
[Ref26] Rosen, E., "Vulnerabilities of Network Control Protocols: An
Example", Computer Communication Review, July 1981.A. OSPF data formats 🎀
This appendix describes the format of OSPF protocol packets and OSPF LSAs 📦 the OSPF protocol runs directly over the IP network layer 🌐 before any data formats are described, the details of the OSPF encapsulation get explained first, so we're all on the same page 💖
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 is contained in OSPF Hello packets, Database Description packets, and in OSPF LSAs 🫶
OSPF packet formats are detailed in Section A.3 🧚 and a description of OSPF LSAs appears in Section A.4 🌸
A.1. Encapsulation of OSPF packets 🌸
okay so OSPF runs directly on top of IP, the network layer 💅 which means its packets only get wrapped in IP and local data-link headers. no extra layers in between, bestie.
OSPF doesn't have its own way to fragment packets, so when a packet is bigger than the network MTU it depends on IP fragmentation 😭 If needed, an OSPF packet can be up to 65,535 bytes long (IP header included). The big ones (Database Description, Link State Request, Link State Update and Link State Acknowledgment packets) can usually be split into several separate protocol packets without losing any functionality, and that's recommended!! IP fragmentation should be avoided whenever possible 🙈 So the move is to try keeping OSPF packets sent over virtual links to 576 bytes, unless Path MTU Discovery is being performed (see [Ref22]) 🦋
The other main features of OSPF's IP encapsulation are:
- Use of IP multicast 🎀 Some OSPF messages get multicast when they're sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these addresses should never be forwarded, since they're only meant to travel a single hop. To make sure they don't travel multiple hops, their IP TTL must be set to
1✨- AllSPFRouters: this multicast address has been assigned the value
224.0.0.5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent here, and certain OSPF protocol packets go here during the flooding procedure. - AllDRouters: this multicast address has been assigned the value
224.0.0.6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent here during the flooding procedure.
- AllSPFRouters: this multicast address has been assigned the value
- Protocol number 🔢 OSPF is IP protocol number
89. This number has been registered with the Network Information Center. IP protocol number assignments are documented in [Ref11]. - TOS value 🍓 All OSPF routing protocol packets are sent using the normal service TOS value of binary
0000defined in [Ref12]. - IP precedence 👑 Routing protocol packets are sent with IP precedence set to Internetwork Control. OSPF protocol packets should be given precedence over regular IP data traffic, in both sending and receiving. Setting the IP precedence field in the IP header to Internetwork Control [Ref5] may help implement this objective.
A.2. The Options field 🧚
okay the OSPF Options field shows up in OSPF Hello packets, Database Description packets and all LSAs. 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. Thanks to this, routers with different capabilities can be mixed together inside one OSPF routing domain, which is so iconic 🌈
When it's used 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 LSAs to a neighbor because that neighbor has reduced functionality. And lastly, listing capabilities in LSAs lets routers route traffic around reduced functionality routers by leaving them out of parts of the routing table calculation 💜
Five bits of the OSPF Options field have been assigned, but only one (the E-bit) is described completely by this memo. Each bit is described briefly below. Routers should reset (i.e. clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating LSAs. On the flip side, routers that encounter unrecognized Option bits in received Hello packets, Database Description packets or LSAs should ignore the capability and process the packet/LSA normally 🫶
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options fieldE-bit: this bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of this memo.MC-bit: this bit describes whether IP multicast datagrams are forwarded according to the specifications in [Ref18].N/P-bit: this bit describes the handling of Type-7 LSAs, as specified in [Ref19].EA-bit: this bit describes the router's willingness to receive and forward External-Attributes-LSAs, as specified in [Ref20].DC-bit: this bit describes the router's handling of demand circuits, as specified in [Ref21].
A.3. OSPF Packet Formats 📦
there are five distinct OSPF packet types 🔥 All of them begin with a standard 24 byte header, which gets described first. Each packet type is then described in its own section after that, where you can see how the packet is split into fields and then go through the field definitions one by one.
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets are how LSAs get flooded throughout the OSPF routing domain. Because of this, OSPF protocol packets can't be parsed unless the format of LSAs is understood too. The format of LSAs is described in Section A.4.
The receive processing of OSPF packets is detailed in Section 8.2. The sending of OSPF packets is explained in Section 8.1 ✨
A.3.1. The OSPF packet header 🎀
every OSPF packet starts with a standard 24 byte header 💖 This header holds all the info needed to figure out whether the packet should be accepted for further processing. That determination is described in Section 8.2 of the specification.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version #: the OSPF version number. This specification documents version 2 of the protocol 🧚Type: the OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details.
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State AcknowledgmentPacket length: the length of the OSPF protocol packet in bytes. This length includes the standard OSPF header 📏Router ID: the Router ID of the packet's source 🦋Area ID: a 32 bit number identifying the area that this packet belongs to. All OSPF packets are associated with a single area. Most travel a single hop only. Packets travelling over a virtual link are labelled with the backbone Area ID of0.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. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. The checksum is considered to be part of the packet authentication procedure, and for some authentication types the checksum calculation is omitted 🙈AuType: identifies the authentication procedure to be used for the packet. Authentication is discussed in Appendix D of the specification. Consult Appendix D for a list of the currently defined authentication types 🔐Authentication: a 64-bit field for use by the authentication scheme. See Appendix D for details 💜
A.3.2 The Hello packet 💌
Hello packets are OSPF packet type 1 🎀 They get sent out regularly on every interface (virtual links included) to set up and keep neighbor relationships alive 🫶 On physical networks that can do multicast or broadcast, Hello packets also get multicast so routers can find their neighbors automatically ✨ it's giving "hey, anyone out there?" energy 📡
Every router on a shared network has to agree on certain parameters (Network mask, HelloInterval and RouterDeadInterval) 🙈 Those values ride along in the Hello packets, so if they don't match, neighbor relationships can't form. Okay bestie, the full receive side for Hello packets is in Section 10.5 💅 and the sending side is 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Here's the field rundown 📝
- Network mask 🎭: the network mask tied to this interface. For example, if the interface is on a class B network whose third byte gets used for subnetting, the network mask is
0xffffff00. - Options 🧩: the optional capabilities this router supports, documented in Section A.2.
- HelloInterval ⏰: the number of 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 ineligible to become (Backup) Designated Router. Not for everyone, and that's okay 🫶
- RouterDeadInterval 💀: the number of seconds before a silent router gets declared down.
- Designated Router 🦋: the identity of the Designated Router for this network, from the sending router's point of view. It's identified by its IP interface address on the network. If there's no Designated Router, it's set to
0.0.0.0. - Backup Designated Router 🌸: the identity of the Backup Designated Router for this network, from the sending router's point of view. It's identified by its IP interface address on the network. If there's no Backup Designated Router, it's set to
0.0.0.0. - Neighbor 💜: the Router IDs of each 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 starting up, and they describe the contents of the link-state database. It can take more than one packet to describe the whole database, so a poll-response procedure handles it 🎀 One router gets named the master and the other the slave. The master sends Database Description packets (the polls), and the slave answers with Database Description packets of its own (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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |The Database Description packet looks a lot like 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 link-state database. Sending these is covered in Section 10.8, and receiving them is covered in Section 10.6 🧚
Field breakdown 🌈
- Interface MTU 📏: the size in bytes of the largest IP datagram that can go out the associated interface without fragmentation. You can find the MTUs of common Internet link types in Table 7-1 of [Ref22].
Interface MTUshould be set to0in Database Description packets sent over virtual links. - Options 🧩: the optional capabilities this router supports, documented in Section A.2.
- I-bit 🌟: the Init bit. When it's set to 1, this packet is the first in the sequence of Database Description packets.
- M-bit ➕: the More bit. When it's set to 1, more Database Description packets are coming after this one.
- 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 keeps incrementing until the complete database description has been sent.
The rest of the packet is a (possibly partial) list of pieces of the link-state database 🧩 Each LSA in the database is described by its LSA header, which is documented in Section A.4.1. That header holds all the info needed to uniquely identify both the LSA and its current instance. 🆔✨
A.3.4 The Link State Request packet 🙋♀️
Link State Request packets are OSPF packet type 3 🎀 After swapping Database Description packets with a neighbor, a router might notice that parts of its link-state database are out-of-date. That's when it sends a Link State Request packet to ask for the newer pieces of the neighbor's database 📬 It may take several Link State Request packets to get everything.
A router sending a Link State Request packet knows exactly which instance of the database pieces it wants. Each instance is defined by its LS sequence number, LS checksum, and LS age, but those fields don't appear in the Link State Request packet itself 🤷♀️ The router might even get back instances that are newer than what it asked for, and honestly that's a glow-up 🌈
Sending these is documented in Section 10.9, and receiving them is documented in Section 10.7 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Each requested LSA gets identified by its LS type, Link State ID, and Advertising Router 🏷️ That trio uniquely pins down the LSA, but not its instance. Link State Request packets are understood to be asking for the most recent instance, whatever that happens to be ✨
Let's keep going, bestie 💖
A.3.5 The Link State Update packet 🦋
Okay so Link State Update packets are OSPF packet type 4, and they're the ones that actually do the flooding of LSAs 🌊 Each one carries a bundle of LSAs that have moved one hop further away from where they started. You can squish several LSAs into one packet, which is so efficient, honestly iconic 💅
Link State Update packets get multicast on physical networks that support multicast/broadcast ✨ To keep flooding reliable, the flooded LSAs get acknowledged in Link State Acknowledgment packets 🫶 If a certain LSA has to be sent again, the retransmitted copy always goes straight to the neighbor, not to a group. For the full reliable-flooding story, go check Section 13, bestie 📖
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |# LSAs 🔢 This is just the number of LSAs included in this update.
The body of the Link State Update packet is a list of LSAs 📦 Every LSA starts with a common 20 byte header, which you'll find in Section A.4.1. The detailed formats for each type of LSA live in Section A.4.
A.3.6 The Link State Acknowledgment packet 💖
Link State Acknowledgment packets are OSPF packet type 5 🎀 Flooded LSAs get explicitly acknowledged so the flooding is reliable, and that acknowledgment happens by sending and receiving these packets. One Link State Acknowledgment packet can acknowledge multiple LSAs at once, which is giving efficiency ✨
Where the acknowledgment goes depends on two things: the state of the sending interface, and who sent the Link State Update being acknowledged. It gets sent to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. The sending side is documented in Section 13.5, and the receiving side in Section 13.7 🧚
The format is pretty similar to the Data Description packet. Both packets basically just carry a list of LSA 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Each acknowledged LSA is described by its LSA header 🪪 The LSA header is covered in Section A.4.1, and it has everything needed to uniquely identify both the LSA and that LSA's current instance. Main character header energy 👑
A.4 LSA formats 🌈
This memo defines five distinct types of LSAs 💜 Every LSA begins with a standard 20 byte LSA header, explained in Section A.4.1, and the sections after that diagram each separate LSA type.
Each LSA describes a piece of the OSPF routing domain 🗺️ Every router originates a router-LSA. On top of that, whenever a router gets elected Designated Router, it also originates a network-LSA. Other types of LSAs may be originated too (see Section 12.4). All LSAs then get flooded throughout the OSPF routing domain. The flooding algorithm is reliable, which means all routers end up with the same collection of LSAs (See Section 13 for more on flooding). This collection is called the link-state 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 LSA header 🎀
Every LSA starts with a common 20 byte header, and this header has enough info to uniquely identify the LSA: the LS type, Link State ID, and Advertising Router 🔍 Multiple instances of the same LSA 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 the 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 LSA 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 LSA. Each LSA type has its own advertisement format. The LSA types defined in this memo are as follows (see Section 12.1.3 for further explanation):
LS Type Description
___________________________________
1 Router-LSAs
2 Network-LSAs
3 Summary-LSAs (IP network)
4 Summary-LSAs (ASBR)
5 AS-external-LSAsLink State ID 🪪 This field identifies the portion of the internet environment that is being described by the LSA. Its contents depend on the LSA's LS type. For example, in network-LSAs the Link State ID is set to the IP interface address of the network's Designated Router (from which the network's IP address can be derived). The Link State ID is further discussed in Section 12.1.4.
Advertising Router 📣 The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router.
LS sequence number 🔢 Detects old or duplicate LSAs. Successive instances of an LSA are given successive LS sequence numbers. See Section 12.1.6 for more details.
LS checksum ✅ The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 for more details.
length 📏 The length in bytes of the LSA. This includes the 20 byte LSA header.
A.4.2 Router-LSAs ✨
Okay bestie, router-LSAs are the Type 1 LSAs 💅 Each router in an area originates a router-LSA, and it describes the state and cost of the router's links (aka interfaces) to that area. Every one of the router's links to the area must be described in a single router-LSA, so no splitting them up! For 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 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |In router-LSAs, the Link State ID field is set to the router's OSPF Router ID. Router-LSAs are flooded throughout a single area only 🌸
bit V: When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as Transit area (V is for virtual link endpoint). 🦋bit E: When set, the router is an AS boundary router (E is for external). ✨bit B: When set, the router is an area border router (B is for border). 👑# links: The number of router links described in this LSA. This must be the total collection of router links (i.e., interfaces) to the area. 💖
The following fields describe each router link (aka interface). Every router link is typed (see the Type field below), and the Type field tells you what kind of link you're looking at 🧚 It can be a link to a transit network, to another router, or to a stub network. The values of all the other fields depend on the link's Type. For example, each link has a 32-bit Link Data field. For links to stub networks, this field specifies the network's IP address mask. For other link types, Link Data specifies the router interface's IP address.
Type: A quick description of the router link. One of the following. Host routes are classified as links to stub networks with network mask of 0xffffffff, so that's how you spot them 🙈
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual linkLink ID: Identifies the object that this router link connects to. The value depends on the link's Type. When connecting to an object that also originates an LSA (i.e., another router or a transit network), the Link ID is equal to the neighboring LSA's Link State ID. This is the key for looking up the neighboring LSA in the link state database during the routing table calculation. See 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 value again depends on the link's Type field. For connections to stub networks,Link Dataspecifies the network's IP address mask. For unnumbered point-to-point connections, it specifies the interface's MIB-II [Ref8] ifIndex value. For the other link types, it specifies the router interface's IP address. This last bit is needed during the routing table build process, when calculating the IP address of the next hop. See Section 16.1.1 for more details. 🍓# TOS: The number of different TOS metrics given for this link, not counting the required link metric (referred to as the TOS 0 metric in [Ref9]). For example, if no additional TOS metrics are given, this field is set to 0. 💅metric: The cost of using this router link. 🌈
Additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). Within each link, and for each desired TOS, TOS-specific link information may be encoded as follows:
TOS: The IP Type of Service that this metric refers to. The encoding of TOS in OSPF LSAs is described in Section 12.3. 🫶TOS metric: TOS-specific metric information. ⭐
A.4.3 Network-LSAs ✨
Network-LSAs are the Type 2 LSAs, and they're the cute little network-level ones 🎀 A network-LSA is originated for each broadcast and NBMA network in the area that supports two or more routers. It's originated by the network's Designated Router, and it describes all routers attached to the network, including the Designated Router itself. The LSA'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, which is why metric fields don't need to be specified in the network-LSA 💖 For details on building network-LSAs, 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 those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field. 👑
A.4.4 Summary-LSAs 💖
Okay bestie, summary-LSAs are the Type 3 and 4 LSAs 🦋 They're originated by area border routers, and they describe inter-area destinations. If you want the nitty-gritty on how to build them, check out Section 12.4.3 ✨
Type 3 summary-LSAs are for when the destination is an IP network. The Link State ID is an IP network number here. If needed, it can also have one or more of the network's "host" bits set (see Appendix E for the deets). When the destination is an AS boundary router, we use a Type 4 summary-LSA instead, and the Link State ID is that ASBR's OSPF Router ID 🫶 Wondering why we need to advertise where each ASBR is? Section 16.4 has the tea 🍵 The only difference between Type 3 and 4 summary-LSAs is the Link State ID field. Otherwise they're the exact same format 💅
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Stub areas can use Type 3 summary-LSAs to describe a (per-area) default route 🌸 That's the move because default summary routes are used in stub areas instead of flooding a full set of external routes. When you're describing a default summary route, the Link State ID is always DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0 🧚
Network Mask
- For Type 3 summary-LSAs, this is the destination network's IP address mask. For example, a class A network gets the value 0xff000000. For Type 4 summary-LSAs this field isn't meaningful and must be zero 🙈
metric
- The cost of this route, in the same units as the interface costs in the router-LSAs 💜
Extra TOS-specific info can also be included, for backward compatibility with older OSPF specs ([Ref9]). For each TOS you want, the TOS-specific info is encoded like this:
TOS
- The IP Type of Service this metric refers to. Check Section 12.3 for how TOS gets encoded in OSPF LSAs 🎀
TOS metric
- The TOS-specific metric info 🍓
A.4.5 AS-external-LSAs 🌈
Type 5 LSAs are the AS-external-LSAs 👑 They're originated by AS boundary routers and describe destinations outside the AS. For how to construct them, see Section 12.4.3 ✨
Usually, an AS-external-LSA describes one specific external destination. For these, the Link State ID is an IP network number. If needed, it can also have one or more of the network's "host" bits set (Appendix E has the details) 🦋 AS-external-LSAs can also describe a default route, which gets used 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 set to 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| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| TOS | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network Mask
- The IP address mask for the advertised destination. For example, for a class A network you'd use the mask 0xff000000 🌷
bit E
- The type of external metric. If bit E is set, the metric is a Type 2 external metric, which means it's treated as larger than any link state path 🔥 If bit E is zero, the metric is a Type 1 external metric, which means it's in the same units as the link state metric (the same units as interface cost) 🍀
metric
- The cost of this route. How it's interpreted depends on the external type (bit E above) 💫
Forwarding address
- Data traffic for the advertised destination goes to this address. If the Forwarding address is 0.0.0.0, the traffic goes to the LSA's originator instead (the responsible AS boundary router) 🧭
External Route Tag
- A 32-bit field on every external route. OSPF itself doesn't use it. It can be used to pass info between AS boundary routers, but what that info is falls outside this spec 🎁
Extra TOS-specific info can also be included, for backward compatibility with older OSPF specs ([Ref9]). For each TOS you want, it's encoded like this:
TOS
- The Type of Service the following fields are about. Section 12.3 explains how TOS gets encoded in OSPF LSAs 🎀
bit E
- Kept for backward compatibility with [Ref9] 🕰️
TOS metric
- The TOS-specific metric info 🍒
Forwarding address
- Kept for backward compatibility with [Ref9] 🫧
External Route Tag
- Kept for backward compatibility with [Ref9] 🧁
B. Architectural Constants ✨
Okay so OSPF has a bunch of protocol parameters with fixed architectural values 🔮 The text refers to them by names like LSRefreshTime. The configurable parameters use the same naming style, and those live in Appendix C 💖
Here's each architectural constant, with its value and a quick rundown of what it does 🌟
LSRefreshTime
- The max time between distinct originations of any particular LSA. When the LS age field of one of the router's self-originated LSAs hits LSRefreshTime, a new instance gets originated, even though the contents (apart from the LSA header) stay the same 🔄 LSRefreshTime is set to 30 minutes ⏰
MinLSInterval
- The min time between distinct originations of any particular LSA. MinLSInterval is set to 5 seconds 🏃♀️
MinLSArrival
- For any particular LSA, the min time that has to pass between receiving new LSA instances during flooding. Instances arriving more often than that get thrown out 🗑️ MinLSArrival is set to 1 second ⚡
MaxAge
- The max age an LSA can reach. When an LSA's LS age field hits MaxAge, it gets reflooded to try to flush it from the routing domain (see Section 14). LSAs at MaxAge aren't used in the routing table calculation 🧹 MaxAge is set to 1 hour 🕐
CheckAge
- When an LSA's age in the link state database hits a multiple of CheckAge, its checksum gets verified. A wrong checksum at that point means something's seriously broken 🚨 CheckAge is set to 5 minutes ✨
MaxAgeDiff
- The max time dispersion that can happen while an LSA floods through the AS. Most of that time is spent with the LSA sitting on router output queues (so it isn't aging) during flooding 🌊 MaxAgeDiff is set to 15 minutes 💜
LSInfinity
- The metric value meaning the destination described by an LSA is unreachable. It's used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). It's defined as the 24-bit binary value of all ones: 0xffffff 🙅♀️
DefaultDestination
- The Destination ID for the default route. This route is used when no other matching routing table entry can be found 🛟 The default destination can only be advertised in AS-external-LSAs and in the type 3 summary-LSAs of stub areas. Its value is the IP address 0.0.0.0, and its Network Mask is always 0.0.0.0 too 🍼
InitialSequenceNumber
- The value used for the LS Sequence Number when originating the first instance of any LSA. It's the signed 32-bit integer 0x80000001 🌱
MaxSequenceNumber
- The max value the LS Sequence Number can reach. It's the signed 32-bit integer 0x7fffffff 🏔️
C. Configurable Constants 🎀
OSPF has quite a few configurable parameters, and we're about to list them 🥹 They're grouped into general functional categories (area parameters, interface parameters, and so on), and some of them come with sample values 💅
Okay bestie, some settings HAVE to match across groups of routers 💅 All routers in an area MUST agree on that area's parameters, and all routers hooked up to the same network MUST agree on that network's IP network number and mask. 🫶 Not optional, iykyk. Some parameters MAY be figured out by router algorithms outside this spec (like the address of a host on the other end of a SLIP line 🧚). From OSPF's point of view, those are still configurable ✨
C.1 Global parameters 🌸
Okay so normally, OSPF runs a separate copy for each area, which means most config is per-area 💖 Only a few global parameters are left, and here they are.
Router ID
This is a 32-bit number that uniquely identifies the router in the Autonomous System 🦋 One way to pick it is to use 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 LSAs from the routing domain (see Section 14.1), or they will hang around for up to MaxAge minutes 🙈
RFC1583Compatibility
This one controls the preference rules from Section 16.4 when you're choosing between several AS-external-LSAs that advertise the same destination 👑 If it's "enabled", the rules stay the ones from RFC 1583 ([Ref9]). If it's "disabled", the rules are the ones in Section 16.4.1, which stop routing loops when AS-external-LSAs for the same destination came from different areas 🔥 It's "enabled" by default.
Here's the tea: to keep routing loops to a minimum, every OSPF router in a routing domain SHOULD have RFC1583Compatibility set the exact same way 💅 If there are routers around that haven't been updated with the Section 16.4.1 functionality, then all routers SHOULD have RFC1583Compatibility set to "enabled". Otherwise, all routers SHOULD have it set to "disabled", which blocks all routing loops ✨
C.2 Area parameters 🎀
All routers belonging to an area MUST agree on that area's configuration 😭 If two routers disagree, adjacencies can't form between them, and that messes up the flow of routing protocol and data traffic. These items MUST be configured for an area:
Area ID
This is a 32-bit number that identifies the area 🌈 The Area ID 0.0.0.0 is reserved for the backbone. If the area is 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 has the following items:
[IP address, mask]: This describes the collection of IP addresses in the address range. Networks and hosts get assigned to an area depending on whether their addresses fall into one of the area's defining address ranges. Routers count as belonging to multiple areas, depending on which areas their attached networks are in.Status: Set to eitherAdvertiseorDoNotAdvertise. Routing information gets condensed at area boundaries. Outside the area, at most a single route is advertised (via a summary-LSA) for each address range, and that route is advertised if and only if the address range's Status is set toAdvertise🦋 Unadvertised ranges let you intentionally hide the existence of certain networks from other areas 🙈 Status is set toAdvertiseby default.
As an example, say an IP subnetted network is going to be its own OSPF area 💖 That area would be configured as a single address range. The IP address is the address of the subnetted network, and the mask is the natural class A, B, or C address mask. Outside the area, a single route gets advertised that describes the entire subnetted network ✨
ExternalRoutingCapability
This is about whether AS-external-LSAs get flooded into and throughout the area 💅 If they're excluded from the area, the area is called a "stub". Inside stub areas, routing to external destinations is based solely on a default summary route. The backbone cannot be configured as a stub area, and virtual links cannot be configured through stub areas either. For more info, check 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 is the cost of the default summary-LSA that the router SHOULD advertise into the area 👑
C.3 Router interface parameters 🦋
Some of the configurable router interface parameters, like the IP interface address and subnet mask, actually describe properties of the attached networks 🫶 So they MUST be consistent across all the routers attached to that network. These are the parameters that MUST be configured for a router interface:
IP interface address
This is the IP protocol address for this interface, and it uniquely identifies the router over the entire internet 💖 An IP address is not REQUIRED on point-to-point networks. A point-to-point network like that is called "unnumbered" 🧚
IP interface mask
Also called the subnet/network mask, this tells you which part 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 the attached network. On point-to-point networks and virtual links, the IP interface mask is not defined. On those links, the link itself doesn't get an IP network number, so each side's addresses are assigned independently, if they get assigned at all 🙈
Area ID
This is the OSPF area that the attached network belongs to 🌈
Interface output cost
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-LSA. The interface output cost MUST always be greater than 0 ✨
RxmtInterval
This is the number of seconds between LSA 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. The setting SHOULD be conservative, or you'll get needless retransmissions. 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 🦋 LSAs inside the update packet MUST have their age incremented by this amount before transmission. This value SHOULD take the transmission and propagation delays of the interface into account. 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 it's still a tie, the router with the highest Router ID wins 🔥 A router whose Router Priority is set to 0 is ineligible to become Designated Router on the attached network. Router Priority only gets configured for interfaces to broadcast and NBMA networks 🌸
HelloInterval
This is the length of time, in seconds, between the Hello Packets the router sends on the interface 🧚 The value is advertised in the router's Hello Packets. It MUST be the same for all routers attached to a common network. The smaller the HelloInterval, the faster topology changes get detected, but more OSPF routing protocol traffic follows ⭐ Sample value for an X.25 PDN network: 30 seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval
After a router stops hearing its neighbor's Hello Packets, this is the number of seconds before the neighbors declare it down 💀 It's also advertised in the router's Hello Packets, in their RouterDeadInterval field. It SHOULD be some multiple of the HelloInterval (say 4). This value again MUST be the same for all routers attached to a common network 🫶
AuType
This identifies the authentication procedure used on the attached network 🔐 This value MUST be the same for all routers attached to the network. Check Appendix D for a discussion of the defined authentication types ✨
Authentication key
This is configured data that lets the authentication procedure verify OSPF protocol packets received over the interface 🎀 For example, if the AuType says simple password, the Authentication key is a clear 64-bit password. Authentication keys for the other OSPF authentication types are covered in Appendix D 💅
C.4 Virtual link parameters 🌈
Virtual links are used to restore or increase connectivity of the backbone 🦋 They MAY be configured between any pair of area border routers that have interfaces to a common (non-backbone) area. In the backbone's graph, the virtual link shows up as an unnumbered point-to-point link. The virtual link MUST be configured in both of the area border routers 👑
A virtual link shows up in router-LSAs (for the backbone) as if it were a separate router interface to the backbone 🦋 So it has all of the parameters a router interface has (see Section C.3). Ngl, it's a little sneaky. Even though a virtual link acts like an unnumbered point-to-point link, it does have an associated IP interface address ✨ That address is the IP source in OSPF protocol packets sent along the virtual link, and it gets set dynamically during the routing table build process. The 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 it should be well over the expected round-trip delay between the two routers. This can be hard to estimate for a virtual link, so it's better to err on the side of making it too large 🫶 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, which is called the virtual link's Transit area 🌸 Virtual links cannot be configured through stub areas 💀
C.5 NBMA network parameters 🌈
OSPF treats an NBMA network pretty much like a broadcast network. Since there may be lots of routers attached, a Designated Router gets selected for the network. That Designated Router then originates a network-LSA, which lists all routers attached to the NBMA network 👑
Because NBMA networks don't have broadcast capabilities, you might need configuration parameters for the Designated Router selection. These only need to be configured on routers that are themselves eligible to become Designated Router (so, routers whose Router Priority for the network is non-zero), and only if no automatic procedure for discovering neighbors exists:
- List of all other attached routers: The list of all other routers attached to the NBMA network. Each router is listed by its IP interface address on the network. For each router listed, its eligibility to become Designated Router must also be defined. When an interface to an NBMA network comes up, the router sends Hello Packets only to those neighbors eligible to become Designated Router, until it discovers the identity of the Designated Router 🔍
- PollInterval: If a neighboring router has become inactive (Hello Packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello Packets to the dead neighbor. These Hello Packets are sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes ⏰
C.6 Point-to-MultiPoint network parameters 🦋
On Point-to-MultiPoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the network. Each neighbor is identified by its IP address on the Point-to-MultiPoint network. Designated Routers are not elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined 🤷♀️
Alternatively, neighbors on Point-to-MultiPoint networks may be dynamically discovered by lower-level protocols such as Inverse ARP ([Ref14]) ✨
C.7 Host route parameters 🧚
Host routes are advertised in router-LSAs as stub networks with mask 0xffffffff. They indicate router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are 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: The IP address of the host.
- Cost of link to host: The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the internet, the actual configured cost is often unimportant (i.e., it will have no effect on routing) 😌
- Area ID: The OSPF area to which the host belongs.
D. Authentication 💜
All OSPF protocol exchanges are authenticated 🔐 The OSPF packet header (see Section A.3.1) includes an authentication type field, plus 64 bits of data for use by the appropriate authentication scheme (determined by the type field).
The authentication type is configurable on a per-interface basis (or equivalently, per-network/subnet). Additional authentication data is also configurable on a per-interface basis.
Authentication types 0, 1 and 2 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20 📋
AuType Description
___________________________________________
0 Null authentication
1 Simple password
2 Cryptographic authentication
All others Reserved for assignment by the
IANA (iana@ISI.EDU)
Table 20: OSPF authentication types.D.1 Null authentication 🫥
Use of this authentication type means that routing exchanges over the network/subnet are not authenticated. The 64-bit authentication field in the OSPF header can contain anything, because it is not examined on packet reception. When using Null authentication, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed to detect data corruption 🧐
D.2 Simple password authentication 🔑
With this authentication 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. This basically acts as a "clear" 64-bit password. In addition, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed to detect data corruption 🧾
Simple password authentication guards against routers inadvertently joining the routing domain, because each router must first be configured with its attached networks' passwords before it can take part in routing 🚧 However, simple password authentication is vulnerable to passive attacks that are currently widespread on the Internet (see [Ref16]). Anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain. 😱 Be careful with this one, bestie 🚨
Security note: Simple password authentication does not protect against anyone with physical access to the network, who can learn the password and compromise the OSPF routing domain.
D.3 Cryptographic authentication 🔐
With this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate or verify a "message digest" that gets appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks 🛡️
The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification completely defines the use of OSPF Cryptographic authentication when the MD5 algorithm is used 🧮
In addition, a non-decreasing sequence number is included in each OSPF protocol packet to protect against replay attacks. This gives long term protection, but it is still possible to replay an OSPF packet until the sequence number changes ⏳ To make this work, each neighbor data structure contains a new field called the "cryptographic sequence number". This field is initialized to zero, and is also set to zero
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Key ID | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Usage of the Authentication field
in the OSPF packet header when Cryptographic
Authentication is employedwhenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number 📈
This specification does not provide a rollover procedure for the cryptographic sequence number. When the cryptographic sequence number that the router is sending hits the maximum value, the router should reset the cryptographic sequence number it is sending back to 0. After this is done, the router's neighbors will reject the router's OSPF packets for a period of RouterDeadInterval, and then the router will be forced to reestablish all adjacencies over the interface 😬 However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. That choice essentially prevents rollover, since the cryptographic sequence number field is 32 bits in length 🙌
The OSPF Cryptographic authentication option does not provide confidentiality 🙈
When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined as shown in Figure 18. The new field definitions are as follows:
- Key ID: This field identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key Identifiers are unique per-interface (or equivalently, per-subnet) 🗝️
- Auth Data Len: The length in bytes of the message digest appended to the OSPF packet 📏
- Cryptographic sequence number: An unsigned 32-bit non-decreasing sequence number. Used to guard against replay attacks 🛡️
The message digest appended to the OSPF packet is not actually considered part of the OSPF protocol packet. It is not included in the OSPF header's packet length, although it is included in the packet's IP header length field 📦
Okay so each key is identified by the combo of interface and Key ID 🔑✨. An interface can have multiple keys active at once, which is what makes swapping from one key to the next so smooth 🦋. Every key also has four time constants attached to it 🕰️. Those can be written as a time-of-day clock, or as the router's local clock (like how many seconds since the last reboot):
KeyStartAccept: the time the router starts accepting packets that were created with the given key.KeyStartGenerate: the time the router starts using the key for packet generation.KeyStopGenerate: the time the router stops using the key for packet generation.KeyStopAccept: the time the router stops accepting packets that were created with the given key.
For a smooth key transition 💅, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite ♾️. When a new key replaces an old one, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key.
Key storage SHOULD persist across a system restart, warm or cold, so you don't run into operational issues 🙈. If the last key tied to an interface expires, it is unacceptable to fall back to an unauthenticated condition, and it's not advisable to disrupt routing either 😭. So the router SHOULD send a "last authentication key expiration" notification to the network manager, and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured 🫶.
D.4 Message generation ✨
After building the contents of an OSPF packet, the authentication procedure indicated by the sending interface's Autype value gets called before the packet is sent 📦. The authentication procedure then modifies the OSPF packet as follows.
D.4.1 Generating Null authentication 🌸
When using Null authentication, the packet gets modified like this:
- The
Autypefield in the standard OSPF header is set to0. - The checksum field in the standard OSPF header is set to the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.
D.4.2 Generating Simple password authentication 🎀
When using Simple password authentication, the packet gets modified like this:
- The
Autypefield in the standard OSPF header is set to1. - The checksum field in the standard OSPF header is set to the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.
- The 64-bit authentication field in the OSPF packet header is set to the 64-bit password (i.e., authentication key) that has been configured for the interface.
D.4.3 Generating Cryptographic authentication 🔐
When using Cryptographic authentication, there MAY be multiple keys configured for the interface 🗝️. In that case, among the keys that are valid for message generation (i.e., that have KeyStartGenerate <= current time < KeyStopGenerate), choose the one with the most recent KeyStartGenerate time. Using this key, modify the packet as follows:
- The
Autypefield in the standard OSPF header is set to2. - The checksum field in the standard OSPF header is not calculated, but is instead set to
0. - The Key ID (see Figure 18) is set to the chosen key's Key ID.
- The
Auth Data Lenfield is set to the length in bytes of the message digest that will be appended to the OSPF packet. When using MD5 as the authentication algorithm,Auth Data Lenwill be16. - The 32-bit Cryptographic sequence number (see Figure 18) is set to a non-decreasing value (i.e., a value at least as large as the last value sent out the interface). The precise values to use in the cryptographic sequence number field are implementation-specific. For example, it MAY be based on a simple counter, or be based on the system's clock ⏰.
- The message digest is then calculated and appended to the OSPF packet. The authentication algorithm to be used in calculating the digest is indicated by the key itself. Input to the authentication algorithm consists of the OSPF packet and the secret key. When using MD5 as the authentication algorithm, the message digest calculation proceeds as follows:
- (a) The 16 byte MD5 key is appended to the OSPF packet.
- (b) Trailing pad and length fields are added, as specified in [Ref17].
- (c) The MD5 authentication algorithm is run over the concatenation of the OSPF packet, secret key, pad and length fields, producing a 16 byte message digest (see [Ref17]).
- (d) The MD5 digest is written over the OSPF key (i.e., appended to the original OSPF packet). The digest is not counted in the OSPF packet's length field, but is included in the packet's IP length field. Any trailing pad or length fields beyond the digest are not counted or transmitted.
D.5 Message verification 🕵️♀️
When an OSPF packet has been received on an interface, it MUST be authenticated 🚨. The authentication procedure is indicated by the setting of Autype in the standard OSPF packet header, which matches the setting of Autype for the receiving OSPF interface.
If an OSPF protocol packet is accepted as authentic, processing of the packet continues as specified in Section 8.2. Packets which fail authentication are discarded 🗑️.
D.5.1 Verifying Null authentication 🧼
When using Null authentication, the checksum field in the OSPF header MUST be verified. It MUST be set to the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. (If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.)
D.5.2 Verifying Simple password authentication 🪪
When using Simple password authentication, the received OSPF packet is authenticated as follows:
- The checksum field in the OSPF header MUST be verified. It MUST be set to the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excepting the authentication field. (If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming.)
- The 64-bit authentication field in the OSPF packet header MUST be equal to the 64-bit password (i.e., authentication key) that has been configured for the interface.
D.5.3 Verifying Cryptographic authentication 🛡️
When using Cryptographic authentication, the received OSPF packet is authenticated as follows:
- Locate the receiving interface's configured key having Key ID equal to that specified in the received OSPF packet (see Figure 18). If the key is not found, or if the key is not valid for reception (i.e.,
current time < KeyStartAcceptorcurrent time >= KeyStopAccept), the OSPF packet is discarded. - If the cryptographic sequence number found in the OSPF header (see Figure 18) is less than the cryptographic sequence number recorded in the sending neighbor's data structure, the OSPF packet is discarded.
- Verify the appended message digest in the following steps:
- (a) The received digest is set aside.
- (b) A new digest is calculated, as specified in Step 6 of Section D.4.3.
- (c) The calculated and received digests are compared. If they do not match, the OSPF packet is discarded. If they do match, the OSPF protocol packet is accepted as authentic, and the "cryptographic sequence number" in the neighbor's data structure is set to the sequence number found in the packet's OSPF header 🎉.
E. An algorithm for assigning Link State IDs 🎀
okay so the Link State ID in AS-external-LSAs and summary-LSAs is usually just the described network's IP address 💖 but if it's necessary, one or more of the network's host bits may be set in the Link State ID. this lets the router originate separate LSAs for networks that share an address but have different masks 🦋 that can happen with supernetting and subnet 0s (see [Ref10]) ✨
this appendix gives one possible algorithm for setting the host bits in Link State IDs. picking an algorithm is a local decision 💅 separate routers are free to use different algorithms, since the only LSAs affected are the ones that the router itself originates. the only requirement on the algorithms is that the network's IP address should be used as the Link State ID whenever possible, because that maximizes interoperability with OSPF implementations predating RFC 1583 🫶
the algorithm below is written for AS-external-LSAs, just for clarity. the exact same algorithm can be used for summary-LSAs 🌸 say the router wants to originate an AS-external-LSA for a network with address NA and mask NM1. the steps to figure out the LSA's Link State ID go like this:
- figure out whether the router is already originating an AS-external-LSA with Link State ID equal to
NA(in that LSA, the router itself will be listed as the Advertising Router). if not, the Link State ID is set equal toNAand the algorithm is done. otherwise, - grab the network mask from the body of the already existing AS-external-LSA and call it
NM2. then there are two cases 👑NM1is longer (more specific) thanNM2. in this case, set the Link State ID in the new LSA to the network[NA,NM1]with all the host bits set. that meansNAOR'ed together with all the bits that aren't set inNM1, which is the broadcast address of network[NA,NM1].NM2is longer thanNM1. in this case, change the existing LSA (the one with Link State IDNA) so it references the new network[NA,NM1]. do that by incrementing the sequence number, changing the mask in the body toNM1, and inserting the cost of the new network. then originate a new LSA for the old network[NA,NM2], with Link State ID equal toNAOR'ed together with the bits that aren't set inNM2(the broadcast address of network[NA,NM2]).
the algorithm assumes all masks are contiguous 🧚 this makes sure that when two networks share an address, one mask is more specific than the other. it also assumes that no network has an address equal to another network's broadcast address. with those two assumptions, the algorithm always produces unique Link State IDs ✨ you can also say it another way: when originating an AS-external-LSA, try the network number as the Link State ID first. 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 network uses its broadcast address instead (basically, flip all the "host" bits to 1). if the most specific network was originated first, you'll end up originating two LSAs at once 🙈
here's an example, where a single router (Router A) goes through this sequence of events 💜
- Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:- (a) a Link State ID of
10.0.0.0is used.
- (a) a Link State ID of
- Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:- (a) the LSA for
[10.0.0,0,255.255.255.0]is reoriginated using a new Link State ID of10.0.0.255. - (b) a Link State ID of
10.0.0.0is used for[10.0.0.0,255.255.0.0].
- (a) the LSA for
- Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:- (a) the LSA for
[10.0.0.0,255.255.0.0]is reoriginated using a new Link State ID of10.0.255.255. - (b) a Link State ID of
10.0.0.0is 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 of10.0.0.255.
- (a) the LSA for
F. Multiple interfaces to the same network/subnet 🌈
there are at least two ways to support multiple physical interfaces to the same IP subnet 🍓 both methods will interoperate with implementations of RFC 1583 (and of course this memo). both are sketched briefly below. the assumption here is that each interface has been given its own separate IP address. (otherwise, supporting multiple interfaces is more of a link-level or ARP issue than an OSPF issue, and that's a whole other vibe 💀)
Method 1:
run the entire OSPF functionality over both interfaces. that means sending and receiving hellos, flooding, and supporting separate interface and neighbor FSMs for each interface, etc. when you do this, all the other routers on the subnet will treat the two interfaces as separate neighbors, since neighbors are identified (on broadcast and NBMA networks) by their IP address 🦋
Method 1 has these disadvantages:
- you increase the total number of neighbors and adjacencies 😭
- you lose the bidirectionality test on both interfaces, since bidirectionality is based on Router ID 💔
- you have to consider both interfaces together during the Designated Router election. if you declare both to be DR at the same time, you can confuse the tie-breaker, which is Router ID 🙃
Method 2:
run OSPF over only one interface (call it the primary interface), but include both the primary and secondary interfaces in your Router-LSA 🧁
Method 2 has these disadvantages:
- you lose the bidirectionality test on the secondary interface 🫠
- when the primary interface fails, you need to promote the secondary interface to primary status 🚨
G. Differences from RFC 2178 💅
this section documents the differences between this memo and RFC 2178. all the differences are backward-compatible. implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate 🫶
G.1 Flooding modifications
three changes have been made to the flooding procedure in Section 13 🌸
the first change is to step 4 in Section 13. MaxAge LSAs now get acknowledged and then discarded only when both a) there is no database copy of the LSA and b) none of the router's neighbors are in states Exchange or Loading. in all other cases, the MaxAge LSA is processed like any other LSA. it gets installed in the database and flooded out the appropriate interfaces when it's more recent than the database copy (Step 5 of Section 13). this change also affects the contents of Table 19 ✨
the second change is to step 5a in Section 13. the MinLSArrival check is meant only for LSAs received during flooding. it should not be performed on those LSAs that the router itself originates 🙌
the third change is to step 8 in Section 13. confusion between routers about which LSA instance is more recent can cause a disastrous amount of flooding in a link-state protocol (see [Ref26]) 😱 OSPF guards against this in two ways: a) the LS age field is used like a TTL field in flooding, to eventually remove looping LSAs from the network (see Section 13.3), and b) routers refuse to accept LSA updates more often than once every MinLSArrival seconds (see Section 13). however, there is still one case in RFC 2178 where disagreements about which LSA is more recent can cause a lot of flooding traffic. that's when routers respond to old LSAs by reflooding the database copy. so Step 8 of Section 13 has been amended to only respond with the database copy when that copy has not been sent in any Link State Update within the last MinLSArrival seconds 🔥
G.2 Changes to external path preferences
there's still a possibility of a routing loop in RFC 2178 when both a) virtual links are in use and b) the same external route is being imported by multiple ASBRs, each of which is in a separate area. to fix this, Section 16.4.1 has been revised 🎀 to choose the correct ASBR/forwarding address, intra-area paths through non-backbone areas are always preferred. however, intra-area paths through the backbone area (Area 0) and inter-area paths now have equal preference, and they must be compared based solely on cost. (see, we're not using "must" in caps here, it's just a sentence 😂)
the reasoning behind this change goes like this. when virtual links are in use, an intra-area backbone path for one router can turn into an inter-area path in a router several hops closer to the destination. so intra-area backbone paths and inter-area paths have to be of equal preference. we can safely compare their costs, preferring the path with the smallest cost, because of the calculations in Section 16.3 🧠
thanks to Michael Briggs and Jeremy McCooey of the UNH InterOperability Lab for pointing out this problem 🫶
G.3 Incomplete resolution of virtual next hops
one of the jobs of the calculation in Section 16.3 is to figure out the actual next hop(s) for destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. after the calculation in Section 16.3 is complete, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded 🗑️
G.4 Routing table lookup
the routing table lookup algorithm in Section 11.1 has been modified to match current practice 💖 the "best match" routing table entry is now always the one providing the most specific (longest) match. say a router is forwarding packets to the destination 192.9.1.1. a routing table entry for 192.9.1/24 will always be a better match than the routing table entry for 192.9/16, no matter what the path-types of those entries are 🦋 note however that when multiple paths are available for a given routing table entry, the calculations in Sections 16.1, 16.2, and 16.4 always yield the paths with the most preferential path-type. (intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths; see Section 11) 👑
Security Considerations 🔐✨
okay bestie, this part is serious, so let's go 🫶
All OSPF protocol exchanges are authenticated. OSPF supports several types of authentication, and you can configure which one is in use on a per network segment basis 🔥. One of those types, the Cryptographic authentication option, is believed to be secure against passive attacks and gives significant protection against active attacks 🛡️. With it, each router tacks a "message digest" onto every OSPF packet it sends. Receivers then use the shared secret key and the digest they received to check that each packet is authentic 💅.
Ngl, how strong that protection is depends completely on three things 👀: the strength of the message digest algorithm (MD5 is currently the only one specified), the strength of the key in use, and whether every communicating OSPF implementation applies the security mechanism correctly. Everyone also has to keep the shared secret key secret 🤫. no cap, if that key leaks, the whole thing is cooked 💀.
None of the OSPF authentication types give you confidentiality, and they don't protect against traffic analysis either 🙈. Key management isn't covered by this memo at all, so that's a whole other puzzle to solve 🧚.
For more info, check out Sections 8.1, 8.2, and Appendix D 📖💖.
Author's Address 🖋️
John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: 978-952-1367
Fax: 978-392-2075
EMail: jmoy@casc.comFull Copyright Statement ⚖️
Legal bits need to stay exact, so here's the notice word for word 🎀
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.📦 where this page comes from
- ietf: rfc2328 1998-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms