RFC 2178
OSPF Version 2
OSPF Version 2 🦋
Okay bestie, let's start with the ID card 🪪 This is RFC 2178, titled OSPF Version 2. It was written by J. Moy of Cascade Communications Corp. and dated July 1997. It came out of the Network Working Group and is on the Standards Track 🚀 It obsoletes RFC 1583, so 1583 is officially out and this one is in 💅
Status of this Memo
Okay so this one is an Internet standards track protocol for the whole Internet community 🌐 It's also asking everyone to chat about it and send suggestions for improvements 💬 If you want the official 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, so share it with everyone 🌸
Abstract
Okay, the main character here is OSPF version 2 👑 OSPF is a link-state routing protocol 🧚 It's designed to run internal to a single Autonomous System, so it's a within-the-network kind of routing, not a between-networks one 🏠 Every OSPF router keeps an identical database that describes the Autonomous System's topology, and the routing table gets calculated from that database by building a shortest-path tree 🌳 It's giving consistency, bestie 💖
OSPF recalculates routes really fast when the topology changes, and it uses a minimum of routing protocol traffic while doing it ⚡ It also supports equal-cost multipath 🛤️ There's an area routing capability too, which gives an additional level of routing protection and cuts down on routing protocol traffic 🫶 And the big one: all OSPF routing protocol exchanges are authenticated 🔐 Iconic, no notes 😭
Now the tea ☕ The differences between this memo and RFC 1583 are explained in Appendix G. All of those differences are backward-compatible in nature 🎀 Implementations of this memo and of RFC 1583 will interoperate, so old and new can totally hang out together 🥹
For comments, the address is ospf@gated.cornell.edu 💌
Part 1 of 47 is done! 🌈 More parts coming, so stay tuned, bestie 💜
Table of Contents 🎀
okay bestie, this is the whole roadmap for the doc ✨ every section, subsection and appendix, with the page where it starts so you can jump straight to the good stuff 💅
1 Introduction ........................................... 5
1.1 Protocol Overview ...................................... 5
1.2 Definitions of commonly used terms ..................... 6
1.3 Brief history of link-state routing technology ........ 9
1.4 Organization of this document ......................... 10
1.5 Acknowledgments ....................................... 11
2 The link-state database: organization and calculations 11
2.1 Representation of routers and networks ................ 11
2.1.1 Representation of non-broadcast networks .............. 13
2.1.2 An example link-state database ........................ 14
2.2 The shortest-path tree ................................ 18
2.3 Use of external routing information ................... 20
2.4 Equal-cost multipath .................................. 22
3 Splitting the AS into Areas ........................... 22
3.1 The backbone of the Autonomous System ................. 23
3.2 Inter-area routing .................................... 23
3.3 Classification of routers ............................. 24
3.4 A sample area configuration ........................... 25
3.5 IP subnetting support ................................. 31
3.6 Supporting stub areas ................................. 32
3.7 Partitions of areas ................................... 33
4 Functional Summary .................................... 34
4.1 Inter-area routing .................................... 35
4.2 AS external routes .................................... 35
4.3 Routing protocol packets .............................. 35
4.4 Basic implementation requirements ..................... 38
4.5 Optional OSPF capabilities ............................ 39
5 Protocol data structures .............................. 40
6 The Area Data Structure ............................... 42
7 Bringing Up Adjacencies ............................... 44
7.1 The Hello Protocol .................................... 44
7.2 The Synchronization of Databases ...................... 45
7.3 The Designated Router ................................. 46
7.4 The Backup Designated Router .......................... 47
7.5 The graph of adjacencies .............................. 48
8 Protocol Packet Processing ............................ 49
8.1 Sending protocol packets .............................. 49
8.2 Receiving protocol packets ............................ 51
9 The Interface Data Structure .......................... 54
9.1 Interface states ...................................... 57
9.2 Events causing interface state changes ................ 59
9.3 The Interface state machine ........................... 61
9.4 Electing the Designated Router ........................ 64
9.5 Sending Hello packets ................................. 66
9.5.1 Sending Hello packets on NBMA networks ................ 67
10 The Neighbor Data Structure ........................... 68
10.1 Neighbor states ....................................... 70
10.2 Events causing neighbor state changes ................. 75
10.3 The Neighbor state machine ............................ 76
10.4 Whether tocome adjacent ............................ 82
10.5 Receiving Hello Packets ............................... 83
10.6 Receiving Database Description Packets ................ 85
10.7 Receiving Link State Request Packets .................. 88
10.8 Sending Database Description Packets .................. 89
10.9 Sending Link State Request Packets .................... 90
10.10 An Example ............................................ 91
11 The Routing Table Structure ........................... 93
11.1 Routing table lookup .................................. 96
11.2 Sample routing table, without areas ................... 97
11.3 Sample routing table, with areas ...................... 97
12 Link State Advertisements (LSAs) ......................100
12.1 The LSA Header ........................................100
12.1.1 LS age ............................................... 101
12.1.2 Options .............................................. 101
12.1.3 LS type .............................................. 102
12.1.4 Link State ID ........................................ 102
12.1.5 Advertising Router ................................... 104
12.1.6 LS sequence number ................................... 104
12.1.7 LS checksum .......................................... 105
12.2 The link state database .............................. 105
12.3 Representation of TOS ................................ 106
12.4 Originating LSAs ..................................... 107
12.4.1 Router-LSAs .......................................... 110
12.4.1.1 Describing point-to-point interfaces ................. 112
12.4.1.2 Describing broadcast and NBMA interfaces ............. 113
12.4.1.3 Describing virtual links ............................. 113
12.4.1.4 Describing Point-to-MultiPoint interfaces ............ 114
12.4.1.5 Examples of router-LSAs .............................. 114
12.4.2 Network-LSAs ......................................... 116
12.4.2.1 Examples of network-LSAs ............................. 116
12.4.3 Summary-LSAs ......................................... 117
12.4.3.1 Originating summary-LSAs into stub areas ............. 119
12.4.3.2 Examples of summary-LSAs ............................. 119
12.4.4 AS-external-LSAs ..................................... 120
12.4.4.1 Examples of AS-external-LSAs ......................... 121
13 The Flooding Procedure ............................... 122
13.1 Determining which LSA is newer ....................... 126
13.2 Installing LSAs in the database ...................... 127
13.3 Next step in the flooding procedure .................. 128
13.4 Receiving self-originated LSAs ....................... 130
13.5 Sending Link State Acknowledgment packets ............ 131
13.6 Retransmitting LSAs .................................. 133
13.7 Receiving link state acknowledgments ................. 134
14 Aging The Link State Database ........................ 134
14.1 Premature aging of LSAs .............................. 135
15 Virtual Links ........................................ 135
16 Calculation of the routing table ..................... 137
16.1 Calculating the shortest-path tree for an area ....... 138
16.1.1 The next hop calculation ............................. 144
16.2 Calculating the inter-area routes .................... 145
16.3 Examining transit areas' summary-LSAs ................ 146
16.4 Calculating AS external routes ....................... 149
16.4.1 External path preferences ............................ 151
16.5 Incremental updates -- summary-LSAs .................. 151
16.6 Incremental updates -- AS-external-LSAs .............. 152
16.7 Events generated as a result of routing table changes 153
16.8 Equal-cost multipath ................................. 154
Footnotes ............................................ 155
References ........................................... 158
A OSPF data formats .................................... 160
A.1 Encapsulation of OSPF packets ........................ 160
A.2 The Options field .................................... 162
A.3 OSPF Packet Formats .................................. 163
A.3.1 The OSPF packet header ............................... 164
A.3.2 The Hello packet ..................................... 166
A.3.3 The Database Description packet ...................... 168
A.3.4 The Link State Request packet ........................ 170
A.3.5 The Link State Update packet ......................... 171
A.3.6 The Link State Acknowledgment packet ................. 172
A.4 LSA formats .......................................... 173
A.4.1 The LSA header ....................................... 174
A.4.2 Router-LSAs .......................................... 176
A.4.3 Network-LSAs ......................................... 179
A.4.4 Summary-LSAs ......................................... 180
A.4.5 AS-external-LSAs ..................................... 182
B Architectural Constants .............................. 184
C Configurable Constants ............................... 186
C.1 Global parameters .................................... 186
C.2 Area parameters ...................................... 187
C.3 Router interface parameters .......................... 188
C.4 Virtual link parameters .............................. 190
C.5 NBMA network parameters .............................. 191
C.6 Point-to-MultiPoint network parameters ............... 191
C.7 Host route parameters ................................ 192
D Authentication ....................................... 193
D.1 Null authentication .................................. 193
D.2 Simple password authentication ....................... 193
D.3 Cryptographic authentication ......................... 194
D.4 Message generation ................................... 196
D.4.1 Generating Null authentication ....................... 196
D.4.2 Generating Simple password authentication ............ 197
D.4.3 Generating Cryptographic authentication .............. 197
D.5 Message verification ................................. 198
D.5.1 Verifying Null authentication ........................ 199
D.5.2 Verifying Simple password authentication ............. 199
D.5.3 Verifying Cryptographic authentication ............... 199
E An algorithm for assigning Link State IDs ............ 201
F Multiple interfaces to the same network/subnet ....... 203
G Differences from RFC 1583 ............................ 204
G.1 Enhancements to OSPF authentication .................. 204
G.2 Addition of Point-to-MultiPoint interface ............ 204
G.3 Support for overlapping area ranges .................. 205
G.4 A modification to the flooding algorithm ............. 206
G.5 Introduction of the MinLSArrival constant ............ 206
G.6 Optionally advertising point-to-point links as subnets 207
G.7 Advertising same external route from multiple areas .. 207
G.8 Retransmission of initial Database Description packets 209
G.9 Detecting interface MTU mismatches ................... 209
G.10 Deleting the TOS routing option ...................... 209
Security Considerations .............................. 210
Author's Address ..................................... 2111. Introduction 🎀
okay bestie, this doc is the spec for OSPF (Open Shortest Path First), a TCP/IP internet routing protocol 💖. OSPF is an Interior Gateway Protocol (IGP), which means it shares routing info between routers that all belong to one single Autonomous System (AS) 🌸. It's link-state (SPF) based, and that's a total glow-up from the Bellman-Ford stuff that traditional TCP/IP routing protocols run on 🧚.
The OSPF protocol was developed by the OSPF working group of the Internet Engineering Task Force. It was designed expressly for the TCP/IP internet environment, so it's got explicit support for CIDR and for tagging externally-derived routing info 🏷️. It also authenticates routing updates, and it uses IP multicast when sending and receiving updates 📡. On top of all that, a lot of work went into making it respond fast to topology changes while only sending small amounts of routing protocol traffic. iconic, honestly ✨.
1.1. Protocol overview
OSPF routes IP packets based solely on the destination IP address in the IP packet header 🎯. The packets get routed "as is" -- they aren't encapsulated in any extra protocol headers as they transit the Autonomous System, so no extra wrapping 🎁. OSPF is a dynamic routing protocol, which means it quickly detects topology changes in the AS (like a router interface failing) and then calculates new loop-free routes after a period of convergence 🔄. That convergence period is short and only involves a minimum of routing traffic. the way that's so efficient 😭.
In a link-state routing protocol, every router keeps a database describing the Autonomous System's topology. This is called the link-state database 🗂️. Every participating router has an identical database, and each individual piece of it is a particular router's local state (for example, the router's usable interfaces and reachable neighbors). Routers spread their local state through the whole AS by flooding 🌊.
All routers run the exact same algorithm, in parallel 👯. From the link-state database, each router builds a tree of shortest paths with itself as the root. That shortest-path tree gives the route to every destination in the AS, and externally derived routing info shows up on the tree as leaves 🌳.
When several equal-cost routes to a destination exist, traffic gets split equally among them ⚖️. The cost of a route is described by a single dimensionless metric 💅.
OSPF lets sets of networks get grouped together, and each grouping is called an area 🧩. The topology of an area is hidden from the rest of the AS, and this information hiding gives a big drop in routing traffic 📉. Routing inside the area is determined only by that area's own topology, so the area is protected from bad routing data 🛡️. An area is basically a generalization of an IP subnetted network.
OSPF also lets you configure IP subnets in a flexible way 🎀. Each route distributed by OSPF has a destination and a mask. Two different subnets of the same IP network number can have different sizes (different masks), and that's known as 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" (0xffffffff) 💜.
Every OSPF protocol exchange is authenticated, so only trusted routers can take part in the AS's routing 🔐. You can use a variety of authentication schemes, and in fact you can configure separate schemes for each IP subnet 🙈.
Externally derived routing data (for example, routes learned from an Exterior Gateway Protocol such as BGP; see [Ref23]) gets advertised throughout the AS 🌍. That external 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 AS boundary pass extra info between each other 🏷️✨.
1.2. Definitions of commonly used terms
This section gives definitions for terms that have a specific meaning to OSPF and get used all through 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. It used to be called a gateway in a lot 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, but separate Autonomous Systems may be running different IGPs 🔁.
- Router ID: A 32-bit number assigned to each router running OSPF. This number uniquely identifies the router within an Autonomous System 🪪.
- Network: In this memo, an IP network/subnet/supernet. It's possible for one physical network to be assigned multiple IP network/subnet numbers, and we consider those to be separate networks. Point-to-point physical networks are the exception: they count as a single network no matter how many (if any at all) IP network/subnet numbers get assigned to them 🕸️.
- Network mask: A 32-bit number showing the range of IP addresses on a single IP network/subnet/supernet. This spec displays network masks as hexadecimal numbers, so the mask for a class C IP network shows up as
0xffffff00. Elsewhere in the literature you'll often see that same mask written as255.255.255.0🎭. - Point-to-point networks: A network that joins a single pair of routers. A 56Kb serial line is an example 🔗.
- Broadcast networks: Networks that support many (more than two) attached routers, and that can address a single physical message to all of the attached routers (broadcast). Neighboring routers get discovered dynamically on these nets using OSPF's Hello Protocol, which itself takes advantage of the broadcast capability. OSPF also 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 📢.
- Non-broadcast networks: Networks that support many (more than two) routers but have no broadcast capability. Neighboring routers are maintained on these nets using OSPF's Hello Protocol. Because there's no broadcast capability, some configuration info may be needed to help discover neighbors. On non-broadcast networks, OSPF protocol packets that are normally multicast need to be sent to each neighboring router, one at a time. An X.25 Public Data Network (PDN) is an example 📭.
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 called NBMA networks or Point-to-MultiPoint networks, depending on which mode OSPF is using over them 🤝.
- Interface: The connection between a router and one of its attached networks. An interface has state info associated with it, which comes from the underlying lower level protocols and the routing protocol itself. An interface to a network has a single IP address and mask associated with it (unless the network is an unnumbered point-to-point network). An interface is sometimes also called a link 🔌.
- Neighboring routers: Two routers that have interfaces to a common network. Neighbor relationships are maintained by OSPF's Hello Protocol, which usually discovers them dynamically 👋.
- Adjacency: A relationship formed between selected neighboring routers so they can exchange routing info. Not every pair of neighboring routers becomes adjacent 💞.
- Link state advertisement: A unit of data describing the local state of a router or network. For a router, this includes the state of its interfaces and adjacencies. Each link state advertisement gets flooded throughout the routing domain, and the collected link state advertisements of all routers and networks form the protocol's link state database. Throughout this memo, link state advertisement is abbreviated as LSA 📦.
- Hello Protocol: The part of OSPF used to establish and maintain neighbor relationships. On broadcast networks, the Hello Protocol can also dynamically discover neighboring routers 👂.
- Flooding: The part of OSPF 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 running the protocol 👑. The Designated Router is elected by the Hello Protocol.
The Designated Router concept cuts down on 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, to OSPF. 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 🕰️
okay so OSPF is a link state routing protocol 🦋 (people also call these SPF-based or distributed-database protocols, iykyk). This section is a quick tour of the link-state glow-up that shaped OSPF. literally the whole family tree 🌳
The first link-state routing protocol was built for the ARPANET packet switching network 🧚 It's described in [Ref3], and it's the OG that every other link-state protocol kind of started from. The ARPANET was super homogeneous: single-vendor packet switches connected by synchronous serial lines. That made the original protocol way easier to design and implement, no cap.
Then [Ref4] came through with upgrades 💅 These mods made the routing protocol more fault tolerant, and one of the big moves was adding a checksum to the LSAs so database corruption can get caught. The paper also had ways to cut down routing traffic overhead. They did it by letting the interval between LSA originations grow by an order of magnitude. iconic behavior 👑
A link-state algorithm was also proposed for the ISO IS-IS routing protocol 🌸 It's described in [Ref2]. This one has methods for reducing data and routing traffic over broadcast networks. The trick is electing a Designated Router for each broadcast network, and that Designated Router then originates an LSA for the network.
Then the OSPF Working Group of the IETF took all of this and ran with it 🏃♀️✨ The Designated Router concept got a major glow-up to cut routing traffic even more. Multicast capabilities are used for extra routing bandwidth savings. An area routing scheme was developed so information can be hidden, protected, or reduced 🔒. And the algorithms were tailored to run efficiently in TCP/IP internets. main character energy 💜
1.4. Organization of this document 🗂️
okay so the first three sections give you the big-picture overview of what the protocol can do and what it's for 🎀 Sections 4-16 get into the nitty-gritty of how each mechanism works. The packet formats, protocol constants and configuration items all live in the appendices 📚
Labels like HelloInterval that show up in the text are protocol constants 🧠 They may or may not be configurable. The architectural constants are summed up in Appendix B, and the configurable constants are summed up in Appendix C.
The detailed spec is written in terms of data structures, because that makes the explanation way more precise 🎯 Implementations of the protocol are required to support the functionality described here, but they need not use the exact data structures that appear in this memo. the vibe is "match the behavior, not the furniture" 🪑✨
1.5. Acknowledgments 🫶
The author wants to give a huge thank-you to 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 the ideas and support they gave to this project. bestie squad goals 👯♀️
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 🔐 iconic duo behavior 🔥
2. The Link-state Database: organization and calculations 🧠
The following subsections describe how OSPF's link-state database is organized, and the routing calculations that run on the database to produce a router's routing table 💅
2.1. Representation of routers and networks 🕸️
The Autonomous System's link-state database describes a directed graph 🌈 The vertices of the graph are routers and networks. A graph edge connects two routers when they're attached via a physical point-to-point network. An edge connecting a router to a network means the router has an interface on that network. Networks can be either transit or stub networks. Transit networks are the ones that can carry data traffic that is neither locally originated nor locally destined. A transit network is a graph vertex with both incoming and outgoing edges, while a stub network's vertex only has incoming edges 🧚
The neighborhood of each network node in the graph 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 and network names start with N. Router interface names start with I. Lines between routers mean point-to-point networks. The left side of the figure shows the networks with their connected routers, and the resulting graphs are on the right 👀
**FROM**
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Physical point-to-point networks
**FROM**
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Stub networks
+---+ +---+
|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 componentsNetworks and routers are both 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. ngl that's the cleanest little rule ever 🍓
The top of Figure 1a shows two routers joined by a point-to-point link. In the resulting link-state database graph, the two router vertices are directly connected by a pair of edges, one in each direction ↔️ Interfaces on point-to-point networks don't need IP addresses. When interface addresses are assigned, they get modelled as stub links, with each router advertising a stub connection to the other router's interface address. You can also optionally assign an IP subnet to the point-to-point network. In that case, both routers advertise a stub link to the IP subnet, instead of advertising each other's 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 link-state database's graph 🌙
When multiple routers are attached to a broadcast network, the link-state database graph shows all of them bidirectionally connected to the network vertex. That's the picture at the bottom of Figure 1a 💕
Each network (stub or transit) in the graph has an IP address and an associated network mask 🎯 The mask tells you how many nodes are on the network. Hosts attached directly to routers (called 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 previously, 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 the non-broadcast network, and also how that network shows up 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 Designated Router originates an LSA for the network. The graph representation for broadcast and NBMA networks is identical, and it's the one pictured in the middle of Figure 1a 💅
NBMA mode is the most efficient way to run OSPF over non-broadcast networks, both for link-state database size and for the amount of routing protocol traffic 🔥 The catch is that it has 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. But it often isn't met on others, like PVC-only Frame Relay networks. On non-broadcast networks where not every router can talk directly, you can split the network into logical subnets. Routers on each subnet can communicate directly, and then each subnet runs as its own NBMA network (see [Ref15]). Heads up though, this takes quite a bit of administrative overhead and it's prone to misconfiguration 🙃 It's probably better to run that kind of 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 even show up in the link-state database graph 👻
Figure 1b illustrates how a Point-to-MultiPoint network is represented in the link-state database 🎨 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 though 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 how real point-to-point links are represented (see Figure 1a) ✨
On some non-broadcast networks, using Point-to-MultiPoint mode together with data-link protocols like Inverse ARP (see [Ref14]) will allow autodiscovery of OSPF neighbors even when broadcast support isn't available 🧚💜
2.1.2. An example link-state database 🗺️✨
Okay so picture this 💖. Figure 2 is a sample map of an Autonomous System, and it's giving full network drama. The rectangle labelled H1 is a host with a SLIP connection to Router RT12, which means 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 both of them display a set of BGP-learned routes 🌈.
A cost is attached to the output side of each router interface, and the system administrator can configure it 🎀. The lower the cost, the more likely that interface is to get used to forward data traffic 🔥. Costs also apply to the externally derived routing data, like those BGP-learned routes 💅.
Next up, 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 label have a cost of 0. Arcs leading from networks to routers always have cost 0, but they still matter, no cap 🙈. Also, the externally derived routing data shows up on the graph as stubs 🌸.
**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 addresses
+
| 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 System
**FROM**
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|N3|N6|N8|N9|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12| | | | |
----- ---------------------------------------------
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 graphHere's the vibe for the graph itself 📊: networks and routers are both 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. Super neat, right? 😭
The link-state database gets pieced together from the LSAs that routers generate 🧩. On the graph, the neighborhood of each router or transit network lives in its own separate LSA. Figure 4 shows these LSAs graphically 🎀. RT12 has an interface to two broadcast networks plus that SLIP line to the host 💀. Network N6 is a broadcast network with three attached routers, and every link from N6 to those routers costs 0 🍓.
Quick heads up 👑: the LSA for Network N6 isn't generated by the network itself. It's generated by one of the attached routers, specifically the router that was elected Designated Router for that network. Iykyk 🫶.
2.2. The shortest-path tree 🌳✨
okay so when there are no OSPF areas configured, every router in the Autonomous System has the exact same link-state database, which means they all see the same graph 👀 each router then builds its routing table by calculating a tree of shortest paths with itself as the root. main character energy fr 👑 the tree is different for every router because it depends on who's doing the math. for RT6 in our example, the shortest-path tree is in Figure 5 🫶
the tree gives the entire path to any destination network or host, but only the next hop actually gets used when forwarding 🦋 also, the best route to every router gets calculated too. for external data, RT6 notes the next hop and distance to any router advertising external routes. RT6's routing table is pictured in Table 2 💅 there's a separate route for each end of a numbered point-to-point network (in this case, the serial line between RT6 and RT10) 🎀
Here's the link-state stuff that feeds all of this (Figure 4):
**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 componentsnetworks and routers are both represented by 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. that's the whole rule, bestie 🧚
now here's the full SPF tree for RT6 (Figure 5) 🌸
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 RT6okay so edges that don't have a cost marked on them have a cost of zero 🙈 those are the network-to-router links. the routes to networks N12-N15 are external info, and we'll cover that in Section 2.3 🍓 routes to networks in other AS'es (like N12) show up as dashed lines on the tree in Figure 5. we'll get into how that external stuff gets used in the next section ✨
here's the local part of RT6's routing table (Table 2) 💖
Destination Next Hop Distance
__________________________________
N1 RT3 10
N2 RT3 10
N3 RT3 7
N4 RT3 8
Ib * 7
Ia RT10 12
N6 RT10 8
N7 RT10 12
N8 RT10 10
N9 RT10 11
N10 RT10 13
N11 RT10 14
H1 RT10 21
__________________________________
RT5 RT5 6
RT7 RT10 8
Table 2: The portion of Router RT6's routing table listing local
destinations.2.3. Use of external routing information 🌍
after the tree is built, the external routing information gets checked 🔍 this info can come from another routing protocol like BGP, or be statically configured (static routes). default routes can be part of the AS's external routing info too 🎀
external routing info is flooded unaltered throughout the AS 🌊 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 are expressed in the same units as OSPF interface cost (so, in terms of the link-state metric). Type 2 external metrics are an order of magnitude larger, and 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 major cost of routing a packet, and it means you don't need to convert external costs into internal link-state metrics 🦋
let's do Type 1 processing 🧠 say RT7 and RT5 in Figure 2 are both advertising Type 1 external metrics. for each advertised external route, the total cost from RT6 is the sum of the external route's advertised cost plus the distance from RT6 to the advertising router. when two routers advertise the same external destination, RT6 picks the one with the minimum total cost 🏆 then RT6 sets the next hop to that external destination equal to the next hop it would use to route packets to the chosen advertising router 🫶
in Figure 2, both RT5 and RT7 advertise an external route to destination N12. RT7 wins because it's advertising 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 the internal distance to that router is. so if RT5 and RT7 were both advertising Type 2 external routes, all traffic for N12 would go to RT7, since 2 < 8 🔥 when several equal-cost Type 2 routes exist, the internal distance to the advertising routers breaks the tie 🌈
Type 1 and Type 2 external metrics can both be in the AS at the same time 🙃 when that happens, Type 1 external metrics always take precedence 👑
this section has assumed that packets for external destinations always get routed through the advertising AS boundary router. that's not always ideal 🙈 for example, imagine RTX is attached to Network N6 in Figure 2. RTX doesn't participate 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 every destination that should go to RTX 💀 an extra hop gets introduced whenever packets for those destinations have to go to RT7 first (the advertising router) 😭
to fix that, OSPF lets an AS boundary router specify 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 other trick too 🧚 it lets routers inside the AS work as "route servers". for example, in Figure 2, RT6 could become a route server by gaining 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 originate a set of OSPF AS-external-LSAs. in each AS-external-LSA, RT6 would specify the correct Autonomous System exit point to use for the destination by setting the LSA's "forwarding address" field appropriately 💅
2.4. Equal-cost multipath 🛤️
everything above has been simplified by looking at only one route to any destination 🙈 in reality, if multiple equal-cost routes to a destination exist, they're all discovered and used 💖 this doesn't need any conceptual changes to the algorithm, and we'll talk about it more when we get into the tree-building process in detail 🫶
with equal-cost multipath, a router can potentially have several next hops available toward any given destination 🌸
3. Splitting the AS into Areas ✨
okay so OSPF lets you bundle up a group of contiguous networks and hosts into one big cozy bundle called an area 🫶 The group plus any routers with an interface to one of those networks is the area. Every area runs its own copy of the basic link-state routing algorithm, so each area gets its own link-state database and its own graph, just like we talked about in the last section 🧚
the area's topology is invisible from outside the area 🦋 and routers inside an area know nothing about the detailed topology outside of it. this isolation of knowledge is what lets the protocol seriously cut down on routing traffic, compared to treating the whole Autonomous System as one single link-state domain. iconic 💅
now the database situation changes: routers in the AS no longer all have an identical link-state database 🙈 a router actually keeps a separate 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, though 💜
routing in the AS happens on two levels 👑 depending on whether the source and destination of a packet live in the same area (intra-area routing) or in different areas (inter-area routing). with intra-area routing, the packet gets routed only on info from inside the area. no routing info from outside the area can be used, and that protects intra-area routing from bad routing info getting injected 🛡️ we'll get into inter-area routing in Section 3.2.
3.1. The backbone of the Autonomous System
the OSPF backbone is the special OSPF Area 0 🌈 (you'll also see it written as Area 0.0.0.0, since OSPF Area IDs are usually formatted like IP addresses). the backbone always contains all the area border routers ✨ its job is distributing routing info between the non-backbone areas. the backbone has to be contiguous. it doesn't have to be physically contiguous though! backbone connectivity can be set up and kept going by configuring virtual links 🎀
virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area 💖 virtual links belong to the backbone. the protocol treats two routers joined by a virtual link as if they were connected by an unnumbered point-to-point backbone network. on the backbone's graph, those two routers are joined by arcs whose costs are the intra-area distances between them 🍓 and the routing protocol traffic flowing along the virtual link uses intra-area routing only, periodt.
3.2. Inter-area routing
when a packet is routed between two non-backbone areas, the backbone gets used 🦋 the packet's path can be broken into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. the algorithm finds the set of these paths with the smallest cost 👑
another way to picture it: inter-area routing is like forcing a star configuration on the Autonomous System, with the backbone as the hub and each non-backbone area as a spoke 🌟
the topology of the backbone decides which backbone paths get used between areas. you can enhance the backbone's topology by adding virtual links, and that 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 is picked in exactly the same way routers advertising external routes are picked 💅 each area border router in an area summarizes its cost to all networks external to the area for that area. after the SPF tree is calculated for the area, routes to all inter-area destinations are calculated by checking those area border router summaries 💜
3.3. Classification of routers
before areas existed, the only OSPF routers with a specialized function were the ones advertising external routing info, like Router RT5 in Figure 2 🙈 once the AS gets split into OSPF areas, routers are further sorted by function into the following 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 info of their attached areas for distribution to the backbone, and the backbone in turn distributes that info 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 don't have to be area border routers. Routers with all interfaces connecting to the backbone area are supported too 🎀
- AS boundary routers: A router that exchanges routing info with routers belonging to other Autonomous Systems. These routers advertise AS external routing info 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 ones: 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 is made of networks N1-N4, along with their attached routers RT1-RT4. the second area is networks N6-N8, plus their attached routers RT7, RT8, RT10 and RT11. the third area is networks N9-N11 and Host H1, plus their attached routers RT9, RT11 and RT12. the third area is configured so that networks N9-N11 and Host H1 all get 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 ⭐
...........................
. + .
. | 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 configurationit also shows the complete view of the internet for the two internal routers RT1 and RT2 🧚 the area border routers RT3 and RT4 have the job of advertising into Area 1 the distances to all destinations external to the area. these show up in Figure 7 as the dashed stub routes 🦋 RT3 and RT4 also have to advertise into Area 1 where the AS boundary routers RT5 and RT7 are. and finally, AS-external-LSAs from RT5 and RT7 are flooded throughout the entire AS, including Area 1 ✨ those LSAs get included in Area 1's database and yield routes to Networks N12-N15 💖
routers RT3 and RT4 also have to summarize Area 1's topology for distribution 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 those networks from RT3 and RT4 respectively 🍓
the link-state database for the backbone is shown in Figure 8 👑 the routers pictured there are the backbone routers. Router RT11 is a backbone router because it belongs to two areas. 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 info of their attached non-backbone areas for distribution via the backbone. those are the dashed stubs in Figure 8 💜 remember that the third area is configured to condense Networks N9-N11 and Host H1 into a single route, which gives one dashed line for N9-N11 and Host H1 in Figure 8 ✨ and routers RT5 and RT7 are AS boundary routers, so their externally derived info also shows up on the Figure 8 graph as stubs 🌈
Network RT3 adv. RT4 adv.
_____________________________
N1 4 4
N2 4 4
N3 1 1
N4 2 3The backbone is where the area border routers swap their summaries, and it's giving main character energy 👑✨
Table 4: Networks advertised to the backbone
by Routers RT3 and RT4.
|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.
Networks and routers are represented by vertices.
An edge of cost X connects Vertex A to Vertex B iff
the intersection of Column A and Row B is marked
with an X.
**FROM**
|RT|RT|RT|RT|RT|RT|RT
|3 |4 |5 |6 |7 |10|11|
------------------------
RT3| | | |6 | | | |
RT4| | |8 | | | | |
RT5| |8 | |6 |6 | | |
RT6|8 | |7 | | |5 | |
RT7| | |6 | | | | |
* RT10| | | |7 | | |2 |
* RT11| | | | | |3 | |
T N1|4 |4 | | | | | |
O N2|4 |4 | | | | | |
* N3|1 |1 | | | | | |
* N4|2 |3 | | | | | |
Ia| | | | | |5 | |
Ib| | | |7 | | | |
N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |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.Okay so the backbone is basically the group chat where every area border router shares its area summaries with every other area border router 🫶. Each one then works out the distance to every network outside its own area by looking at all those collected LSAs and adding in the backbone distance to whichever router advertised them. Iconic teamwork, honestly 💅
Let's run it again with RT3 and RT4 as our examples 🦋. First they calculate the SPF tree for the backbone, which tells them the distances to all the other area border routers. They also note the distances to the networks Ia and Ib, plus the AS boundary routers RT5 and RT7, since those all belong to the backbone. That calculation is 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 up, RT3 and RT4 read the area summaries from those area border routers, and that tells them how far away every network outside their area is 🌸. Then they pass those distances along inside Area 1. Table 6 shows exactly what RT3 and RT4 will advertise into Area 1. Quick note: Table 6 assumes an area range has been configured for the backbone that groups Ia and Ib into one 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.Because of all that info, an internal router like RT1 can pick an area border router with a clear head 🧠✨. RT1 would send traffic for Network N6 through RT4, traffic for Network N10 through RT3, and split its traffic between the two for Network N8 🍓
RT1 can also work out the shortest path to the AS boundary routers RT5 and RT7 in this same way 💖. Then it checks the AS-external-LSAs from RT5 and RT7, so it can choose between RT5 and RT7 when it's sending to a destination in another Autonomous System (one of the networks N12-N15) 🧚
Heads up: if the line between Routers RT6 and RT10 goes down, the backbone gets disconnected 😭. Setting up a virtual link between Routers RT7 and RT10 gives the backbone more connectivity and makes it way more resistant to failures like that 🛡️💜
3.5. IP subnetting support 🎀
OSPF attaches an IP address mask to every route it advertises 🦋. The mask shows the range of addresses that route covers. For example, a summary-LSA for the destination 128.185.0.0 with a mask of 0xffff0000 is actually describing one single route to the whole group of destinations from 128.185.0.0 to 128.185.255.255 😍. Host routes work a little differently: they're always advertised with a mask of 0xffffffff, which means there's only one destination in there 💅
Putting the mask on each advertised destination is what makes variable-length subnetting possible, and that's literally so iconic 🔥. It means one IP class A, B, or C network number can be chopped up into lots of subnets of different sizes. For example, the network 128.185.0.0 could be split into 62 variable-sized subnets: 15 subnets of size 4K, 15 subnets of size 256, and 32 subnets of size 8 🌈. Table 7 shows a few of the resulting network addresses along with their masks.
Network address IP address mask Subnet size
_______________________________________________
128.185.16.0 0xfffff000 4K
128.185.1.0 0xffffff00 256
128.185.0.8 0xfffffff8 8
Table 7: Some sample subnet sizes.There are tons of ways to divide a class A, B, or C network into variable-sized subnets 🧁. The exact procedure for doing that is outside the scope of this specification, but this spec does set one guideline: when an IP packet is forwarded, it always goes to the network that is the best match for the packet's destination 💜. "Best match" just means the longest or most specific match. For example, the default route with destination 0.0.0.0 and mask 0x00000000 always matches every IP destination, but it's always less specific than any other match 🙈. So subnet masks have to be assigned in a way that makes the best match for any IP destination unambiguous ✨
Attaching an address mask to each route also makes IP supernetting possible 🧚♀️. For example, one physical network segment could be given the [address,mask] pair [192.9.4.0,0xfffffc00]. That segment would then be a single IP network covering addresses from the four consecutive class C network numbers 192.9.4.0 through 192.9.7.0 🌸. This kind of addressing is becoming super common now that CIDR is here (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. Lots of separate networks can sit inside one address range, the same way a subnetted network is made up of many separate subnets 💖. Area border routers then summarize what's inside the area, for distribution to the backbone, by advertising one single route per address range. The cost of that route is the maximum cost to any of the networks in that range 🔥
Here's an example: an IP subnetted network might be set up as a single OSPF area 🦋. In that case, you can configure one address range, which is a class A, B, or C network number along with its natural IP mask. Inside the area, you can define any number of variable-sized subnets 🎀. Outside the area, though, only a single route for the entire subnetted network gets distributed, so the fact that it's subnetted at all stays hidden 🙈. The cost of that route is the maximum of the costs to the component subnets 💅
3.6. Supporting stub areas 🧚
okay so in some Autonomous Systems, the majority of the link-state database is basically just AS-external-LSAs 💀. An OSPF AS-external-LSA usually gets flooded throughout the entire AS, which is a LOT. BUT OSPF lets you configure certain areas as "stub areas" 🦋. AS-external-LSAs are not flooded into or throughout stub areas, so routing to AS external destinations in these areas is based on a (per-area) default only. This shrinks the link-state database, and therefore the memory requirements, for a stub area's internal routers. iconic for the little routers 🫶
To take advantage of the OSPF stub area support, default routing must be used in the stub area ✨. Here's how it works: one or more of the stub area's area border routers advertise a default route into the stub area via summary-LSAs. These summary defaults get flooded throughout the stub area, but no further 🙈. (So these defaults only pertain to that particular stub area, nothing leaks out.) These summary default routes get used for any destination that isn't explicitly reachable by an intra-area or inter-area path, aka 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 has to travel through its single area border router RT11. If Area 3 were configured as a stub, RT11 would advertise a default route for distribution inside Area 3 (in a summary-LSA), instead of flooding the AS-external-LSAs for Networks N12-N15 into or throughout the area. main character energy 👑
OSPF makes sure all routers belonging to an area agree on whether the area has been configured as a stub. This guarantees no confusion in the flooding of AS-external-LSAs 💅.
There are a couple of restrictions though 😭. Virtual links cannot be configured through stub areas. And AS boundary routers cannot be placed internal to stub areas. literally no exceptions 🫠
3.7. Partitions of areas 🔧
OSPF doesn't actively try to repair area partitions. When an area becomes partitioned, each component simply becomes a separate area, and the backbone does the routing between the new areas. Some destinations that were reachable via intra-area routing before the partition will now need inter-area routing.
However, to keep full routing after the partition, an address range must not be split across multiple components 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 from Section 2. Area IDs can be viewed as colors for the graph's edges.[1] Each edge of the graph connects to a network, or is itself a point-to-point network. Either way, the edge is colored with the network's Area ID 🌈.
A group of edges, all 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). Routing in the Autonomous System keeps on working 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. Here's a quick summary of how the routing algorithm goes 🎀
When a router starts, it first initializes the routing protocol data structures. Then it waits for indications from the lower-level protocols that its interfaces are functional.
Next, the router uses OSPF's Hello Protocol to acquire neighbors. It sends Hello packets to its neighbors and, in turn, receives their Hello packets. On broadcast and point-to-point networks, the router dynamically detects its neighboring routers by sending its Hello packets to the multicast address AllSPFRouters. On non-broadcast networks, some configuration information may be necessary to discover neighbors. On broadcast and NBMA networks, the Hello Protocol also elects a Designated router for the network 👑
The router will try to form adjacencies with some of its newly acquired neighbors. Link-state databases get synchronized between pairs of adjacent routers. On broadcast and NBMA networks, the Designated Router decides which routers should become adjacent.
Adjacencies control the distribution of routing information. Routing updates are only sent and received 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 lets the protocol 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 is 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. That 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. 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.
Here's how the distillation works: each area border router is by definition connected to the backbone. Each area border router summarizes the topology of its attached 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, plus 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 to 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 ✨
okay so OSPF just runs straight on top of IP, using IP protocol 89 🧚. It doesn't have its own fragmentation or reassembly, so when a packet is too big, plain IP fragmentation/reassembly steps in. BUT the OSPF packets are designed so big ones can usually get chopped into several smaller ones, and that is RECOMMENDED bestie 💅. IP fragmentation SHOULD be avoided whenever possible 🙈.
Routing protocol packets SHOULD always be sent with the IP TOS field set to 0. If at all possible, they SHOULD get priority over regular IP data traffic, both when they're being sent and when they're being received 👑. To help make that happen, OSPF protocol packets SHOULD have their IP precedence field set to the value Internetwork Control (see [Ref5]) 🔥.
Every OSPF packet shares a common protocol header, and it's described in Appendix A 🎀. The packet types are listed in Table 8 🦋, and their formats are also in Appendix A.
Type Packet name
Protocol function
__________________________________________________________
1 Hello Discover/maintain neighbors
2 Database Description Summarize database contents
3 Link State Request Database download
4 Link State Update Database update
5 Link State Ack Flooding acknowledgment
Table 8: OSPF packet types.OSPF's Hello protocol uses Hello packets to discover and maintain neighbor relationships 🌸. The Database Description and Link State Request packets are used when forming adjacencies. OSPF's reliable update mechanism is built from the Link State Update and Link State Acknowledgment packets, so they're literally the dream team 🫶.
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, and the different OSPF LSA types are listed in Table 9 💖.
OSPF routing packets (except Hellos) are sent ONLY over adjacencies. Okay so that means all OSPF protocol packets travel a single IP hop, except the ones sent over virtual adjacencies 🧚. The IP source address of an OSPF protocol packet is one end of a router adjacency, and the IP destination address is either the other end of the adjacency or an IP multicast address 💜.
LS 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.
Table 9: OSPF link state advertisements (LSAs).4.4. Basic implementation requirements 🍓
An implementation of OSPF requires the following pieces of system support:
Timers ⏰
Two different kinds of timers are REQUIRED 💅. The first kind, called "single shot timers", fires once and causes a protocol event to be processed. The second kind, called "interval timers", fires at continuous intervals. These are used for sending packets at regular intervals, and a good example 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 synchronization of routing packets (which SHOULD be avoided) 😭. If timers cannot be implemented to avoid drift, small random amounts SHOULD be added to or subtracted from the interval timer at each firing 🎲.
IP multicast 📡
Certain OSPF packets take the form of IP multicast datagrams. Support for receiving and sending IP multicast datagrams, along with the appropriate lower-level protocol support, is REQUIRED 🔥. The IP multicast datagrams used by OSPF never travel more than one hop. For this reason, the ability to forward IP multicast datagrams is not REQUIRED. For information on IP multicast, see [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, so see Section 3.5 for details 💜.
IP supernetting support 🧩
The router's IP protocol support MUST include the ability to aggregate contiguous collections of IP class A, B, and C networks into larger quantities called supernets. Supernetting has been proposed as one way to improve the scaling of IP routing in the worldwide Internet. For more information on IP supernetting, see [Ref10] ✨.
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 🙈.
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 an X.25 clear with an appropriate cause and diagnostic, and this information would be passed to OSPF 🧚.
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 is 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 👑.
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 or 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 🧚.
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 ✨
okay so this section is the tour of OSPF's brain 🧠💖 it's all the top-level data structures the protocol runs on, plus any setup they need. (areas, interfaces, and neighbors get their own structs later, so don't worry about those yet 🫶)
Router ID 🆔 A 32-bit number that uniquely identifies this router in the AS. one possible move is to use the smallest IP interface address on the router. if the Router ID ever changes, the OSPF software should be restarted before the new one takes effect. and bestie, before that restart, the router should flush its self-originated LSAs from the routing domain (see Section 14.1), or they'll hang around for up to MaxAge minutes 💀
Area structures 🗺️ every area the router is connected to gets its own data structure. this one describes how the basic OSPF algorithm works in that area. remember: each area runs its own separate copy of the algorithm 🌸
Backbone (area) structure 🦴 the OSPF backbone area is responsible for spreading inter-area routing info. it's the main character of the whole network 👑
Virtual links configured 🔗 these are the virtual links with this router as one endpoint. to have any configured virtual links at all, 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. both endpoint routers must be attached to a common area, called the virtual link's Transit area. virtual links are part of the backbone and act like unnumbered point-to-point networks between the two routers 🦋 they use the intra-area routing of their Transit area to forward packets, and they come up and down as the shortest-path trees for the Transit area get built ✨
List of external routes 🌍 these are routes to destinations outside the Autonomous System. the router learned them through direct experience with another routing protocol (like BGP), through configuration, or through a mix of both (for example, dynamic external info that OSPF advertises with a configured metric). any router holding these external routes is called an AS boundary router, and it advertises them into the OSPF routing domain using AS-external-LSAs 🫠🔥
List of AS-external-LSAs 📜 part of the link-state database. they originate from the AS boundary routers and describe routes to destinations outside the Autonomous System. if the router is itself an AS boundary router, some of these AS-external-LSAs were self-originated 💅
The routing table 🧭 derived from the link-state database. every entry is indexed by a destination and holds that destination's cost plus a set of paths to use when forwarding packets to it. a path is described by its type and next hop. for more detail, see Section 11 🎀
Figure 9 shows all the data structures living in a typical router. the router pictured is RT10, from the map in Figure 6. RT10 has a virtual link configured to Router RT11, with Area 2 as the link's Transit area. that's the dashed line in the figure. once the virtual link is active (through building the shortest path tree for Area 2), it becomes an interface to the backbone. check out the two backbone interfaces in Figure 9 🥹
+----+
|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 structures6. The Area Data Structure 🏡
this is the area data structure, and it holds everything the basic OSPF routing algorithm needs to run. every area keeps its own link-state database 💖 a network belongs to one area, a router interface connects to one area, and each router adjacency belongs to one area too. no sharing, no drama 🙅♀️
the OSPF backbone is the special area in charge of spreading inter-area routing info. it's the bestie everyone relies on 👑
the area's link-state database is the collection of router-LSAs, network-LSAs and summary-LSAs that the area's routers originated. this info only gets flooded throughout that single area 🌸 the list of AS-external-LSAs (see Section 5) also counts as part of each area's link-state database.
Area ID 🪪 a 32-bit number identifying the area. the Area ID 0.0.0.0 is reserved for the backbone 🦴
List of area address ranges 📦 to aggregate routing info at area boundaries, area address ranges can be used. each range is an [address,mask] pair with a status of either Advertise or DoNotAdvertise (see Section 12.4.3) ✨
Associated router interfaces 🔌 this router's interfaces that connect to the area. a router interface belongs to one and only one area (or the backbone). for the backbone, 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 between the two routers 🫶
List of router-LSAs 📝 each router in the area generates one of these. 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. it describes the set of routers currently connected to that network 🎀
List of summary-LSAs 📨 these 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 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 says whether the area can carry data traffic that neither starts nor ends 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 (see Section 16.3). when an area's TransitCapability is TRUE, the area is called a "transit area" 🔥
ExternalRoutingCapability 🌐 this says 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 can't be configured through stub areas either. for more info, see Section 3.6 🙈
StubDefaultCost 💸 if the area is configured as a stub area and the router itself is an area border router, the StubDefaultCost is the cost of the default summary-LSA 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 works within a single area 🍓
7. Bringing Up Adjacencies 🤝
OSPF creates adjacencies between neighboring routers so they can swap routing info. not every pair of neighbors will become adjacent 🙃 this section covers the general stuff involved in making adjacencies. for the nitty-gritty, see 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 every router interface. bidirectional communication is indicated when the router sees itself listed in the neighbor's Hello Packet, which is honestly so iconic 🥹 on broadcast and NBMA networks, the Hello Protocol also elects a Designated Router for the network 👑
the Hello Protocol works differently on broadcast networks, NBMA networks and Point-to-MultiPoint networks 🦋
on broadcast networks, each router advertises itself by periodically multicasting Hello Packets. that's how neighbors get discovered dynamically 🔍 these Hello Packets carry the router's view of the Designated Router's identity, plus the list of routers whose Hello Packets it has seen recently 🫶
on NBMA networks, some configuration info might be needed for the Hello Protocol to work. each router that could potentially become Designated Router keeps 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 as soon as its NBMA interface 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 🌈 those neighbors might be discovered dynamically through a protocol like Inverse ARP (see [Ref14]), or they might be configured 🧚
once a neighbor has been discovered, bidirectional communication is ensured, and (if it's on a broadcast or NBMA network) a Designated Router has been elected, a decision gets made about whether an adjacency should form with that neighbor (see Section 10.4) 💅 if it should, the first step is synchronizing the neighbors' link-state databases. that's covered in the next section 🎀
7.2. The Synchronization of Databases ✨
okay so, in a link-state routing algorithm it is SO important that every router's link-state database stays in sync 🔥 OSPF makes this way easier by only requiring adjacent routers to stay synchronized 🫶 The sync process kicks off the moment two 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 that belong to the router's database. When the neighbor sees an LSA that's more recent than its own copy, it makes a little note that this newer LSA should be requested 👀
This back-and-forth of Database Description packets is called the "Database Exchange Process" 💅 During it, the two routers form a master/slave relationship (very dramatic, very iconic). Each Database Description Packet has a sequence number. The master's packets (the polls) get acknowledged by the slave echoing back that sequence number. Both the polls and the responses carry summaries of link state data. The master is the only one allowed to retransmit Database Description Packets, and it only does that at fixed intervals, whose length is the configured per-interface constant RxmtInterval ⏰
Each Database Description has an indication that there are more packets to follow, which is the M-bit 🎀 The Database Exchange Process is over when a router has both received and sent Database Description Packets with the M-bit off. Done and dusted ✨
During and after that exchange, each router has a list of LSAs where the neighbor has a more up-to-date instance. Those get requested in Link State Request Packets. Any Link State Requests that don't get satisfied are retransmitted at fixed intervals of time, again RxmtInterval 🔁 Once the Database Description Process has wrapped up and every Link State Request has 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 both routers' router-LSAs. Main character energy for real 👑
The flooding procedure starts using the adjacency 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 🌸 The Designated Router has 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 worked out 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 💖
The Designated Router is elected by the Hello Protocol. A router's Hello Packet contains its Router Priority, which can be configured on a per-interface basis 🎀 Generally speaking, when a router's interface to a network first becomes functional, it checks whether there's already a Designated Router for that network. If there is, it accepts that Designated Router, regardless of its Router Priority. (This makes it harder to predict who the Designated Router will be, but it means the Designated Router changes less often. More on that below 🙈) Otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network. A more detailed (and more accurate) description of Designated Router election is in Section 9.4 📖
The Designated Router is the endpoint of a lot of adjacencies. To optimize flooding on broadcast networks, the Designated Router multicasts its Link State Update Packets to the address AllSPFRouters, instead of sending separate packets over each adjacency. Efficient queen behavior 👸
Section 2 of this document talks about the directed graph representation of an area. Router nodes are labelled with their Router ID. Transit network nodes are actually labelled with the IP address of their Designated Router. So when the Designated Router changes, it looks like the network node on the graph gets replaced by a totally new node 😭 That causes the network and all its attached routers to originate new LSAs. Until the link-state databases converge again, some temporary loss of connectivity may happen, and this may result in ICMP unreachable messages being sent in response to data traffic. Which is exactly why the Designated Router should change only infrequently. Router Priorities should be configured so that the most dependable router on a network eventually becomes Designated Router 🧚
7.4. The Backup Designated Router
To make switching to a new Designated Router smoother, there's a Backup Designated Router for each broadcast and NBMA network 🍓 The Backup Designated Router is also adjacent to all routers on the network, and it becomes Designated Router when the previous Designated Router fails. Without a Backup Designated Router, when a new Designated Router became necessary, new adjacencies would have to be formed between the new Designated Router and all the other routers on the network. Part of forming an adjacency is synchronizing link-state databases, which can potentially take quite a long time ⏳ During that time the network wouldn't be available for transit data traffic. The Backup Designated obviates the need to form these adjacencies, since they already exist. So the disruption to transit traffic only lasts as long as it takes to flood the new LSAs (the ones announcing the new Designated Router) 🌈
The Backup Designated Router does not generate a network-LSA for the network. (If it did, the transition to a new Designated Router would be even faster. But that's a tradeoff between database size and speed of convergence when the Designated Router disappears 🤷♀️)
The Backup Designated Router is also elected by the Hello Protocol. Each Hello Packet has a field that specifies the Backup Designated Router for the network 💜
During some steps of the flooding procedure, the Backup Designated Router plays a passive role and lets the Designated Router do more of the work. This 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 bound to the network that the two routers have in common. If two routers have multiple networks in common, they can have multiple adjacencies between them 🫧
Picture the collection of adjacencies on a network as an undirected graph. The vertices are routers, with 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, depending on whether a Designated Router 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 communicate directly. On broadcast and NBMA networks, though, only the Designated Router and the Backup Designated Router become adjacent to all other routers attached to the network 🥹
Both graphs are shown in Figure 10. It's assumed that Router RT7 has become the Designated Router, and Router RT3 the Backup Designated Router, for the Network N2. The Backup Designated Router performs a lesser function during flooding than the Designated Router (see Section 13.3). That's why the lines connecting Backup Designated Router RT3 are dashed 💫
+---+ +---+
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2
RT7
o---------+
+---+ +---+ +---+ /|\ |
|RT7| |RT3| |RT4| / | \ |
+---+ +---+ +---+ / | \ |
| | | / | \ |
+-----------------------+ RT5o RT6o oRT4 |
| | N2 * * * |
+---+ +---+ * * * |
|RT5| |RT6| * * * |
+---+ +---+ *** |
o---------+
RT3Figure 10: The graph of adjacencies 🎨
8. Protocol Packet Processing
this section covers the general processing of OSPF routing protocol packets 🧠 It's super important that the router link-state databases stay synchronized, so routing protocol packets should get preferential treatment over ordinary data packets, both when sending and when receiving 🚀
Routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). That means all routing protocol packets travel a single IP hop, except those sent over virtual links 🛣️
All routing protocol packets begin with a standard header. The sections below explain how to fill in and verify this standard header. Then, for each packet type, there's a section giving more details on how that particular packet type gets processed 🎀
Part 12 done, bestie 🌈💖
8.1. Sending protocol packets ✨
okay so when a router sends a routing protocol packet, it fills in the fields of the standard OSPF packet header 💅 (the full breakdown is in Section A.3.1 if you wanna peek 👀):
Version #: set to2, the version of the protocol documented in this spec 🎀Packet type: the kind of OSPF packet, like a Link state Update or a Hello Packet 🦋Packet length: the length of the whole OSPF packet in bytes, header included 📏Router ID: the router's own identity, aka who's originating the packet 👑Area ID: the OSPF area 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 gets calculated as part of the right authentication procedure, and for some OSPF authentication types the checksum calculation is skipped entirely. See Section D.4 💜AuTypeandAuthentication: every OSPF packet exchange gets authenticated 🔐. Authentication types are assigned by the protocol and documented in Appendix D. Each IP network/subnet can use a different procedure.AuTypetells you which procedure is in use, and the 64-bit authentication field is for that procedure to use. This procedure SHOULD be the last one called when forming the packet to be sent. See Section D.4 for the deets.
So the IP destination address gets picked like this, and it's kinda giving main character energy 🎬. On physical point-to-point networks, the IP destination is always set to the address AllSPFRouters. On all other network types (including virtual links), most OSPF packets go out as unicasts, meaning they're sent directly to the other end of the adjacency. In that case the IP destination is just the Neighbor IP address for the other end of the adjacency (see Section 10). The only packets that aren't 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 the other routers send both their Link State Update and Link State Acknowledgment Packets to the multicast address AllDRouters. 🫶
Retransmissions of Link State Update packets are ALWAYS sent as unicasts. no exceptions, bestie 🙅♀️
The IP source address SHOULD be set to the IP address of the sending interface. Interfaces to unnumbered point-to-point networks don't have an associated IP address, so on those, the IP source SHOULD be set to any of the other IP addresses belonging to the router. For this reason, there MUST be at least one IP address assigned to the router.[2] ngl this is a lot of rules, but it all makes sense 🧠. Note that, for most purposes, virtual links act precisely the same as unnumbered point-to-point networks. However, each virtual link does have an IP interface address (discovered during the routing table build process), and that's what gets used as the IP source when sending packets over the virtual link 🌈.
For more info on the format of specific OSPF packet types, check the sections listed in Table 10 📚.
Type Packet name detailed section (transmit)
_________________________________________________________
1 Hello Section 9.5
2 Database description Section 10.8
3 Link state request Section 10.9
4 Link state update Section 13.3
5 Link state ack Section 13.5Table 10: Sections describing OSPF protocol packet transmission. 🍓
8.2. Receiving protocol packets ✨
okay, receiving is where things get spicy 🌶️. Whenever a protocol packet hits the router, it gets marked with the interface it arrived on. For routers with virtual links configured, it might not be obvious which interface a packet belongs to 🤔. Like, take 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). In the following, we assume the packet is initially associated with the non-virtual link.[3] 🦋
Before the packet even gets passed up to OSPF, it has to get through a bunch of IP-level checks. In order for the packet to be accepted at the IP level, it MUST pass a number of tests:
- 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 isn't a multicast packet the router itself generated. no self-replies, periodt 🙈
Next, the OSPF packet header gets verified. The fields specified in the header MUST match the ones configured for the receiving interface. 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:
- (1) Match the Area ID of the receiving interface. In this case, the packet was sent over a single hop, so the packet's IP source address is REQUIRED to be on the same network as the receiving interface. You can check this 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're assigned at all 🙃.
- (2) Indicate the backbone. In this case, the packet was 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 AllDRouters SHOULD only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1) 🎯.
- The AuType specified in the packet MUST match the AuType specified for the associated area.
- 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 SHOULD then be further processed by the Hello Protocol (see Section 10.5) 👋. All other packet types are sent and received only on adjacencies, which means the packet MUST have been sent by one of the router's active neighbors. If the receiving interface connects to a broadcast network, Point-to-MultiPoint network or NBMA network, the sender is identified by the IP source address found in the packet's IP header. If the receiving interface connects to a point-to-point network or a virtual link, the sender is identified by the Router ID (source router) found in the packet's OSPF header. The data structure associated with the receiving interface contains the list of active neighbors. Packets not matching any active neighbor are discarded 🫠.
At this point, every received protocol packet is associated with an active neighbor ✨. For further input processing of specific packet types, check the sections listed in Table 11 💖.
Type Packet name detailed section (receive)
________________________________________________________
1 Hello Section 10.5
2 Database description Section 10.6
3 Link state request Section 10.7
4 Link state update Section 13
5 Link state ack Section 13.7Table 11: Sections describing OSPF protocol packet reception. 🎀
9. The Interface Data Structure ✨
okay so an OSPF interface is basically the connection between a router and a network 🔌 we're assuming there's just one OSPF interface to each attached network/subnet, bestie. supporting multiple interfaces on a single network is a whole other vibe that gets covered in Appendix F 🎀 and each interface structure has at most one IP interface address 💅
an OSPF interface can be considered to belong to the area that contains the attached network 🌸 every routing protocol packet the router sends out over this interface gets labelled with the interface's Area ID 🏷️ you can have one or more router adjacencies developing over an interface, and a router's LSAs reflect the state of its interfaces and their associated adjacencies. it's giving full transparency ✨
here's the list of data items attached to an interface. heads up, a bunch of these are actually configuration for the attached network, so they must be the same for all routers connected to the network 🫶 (okay not the bold, the original says must in lowercase, but you get the vibe 😭)
- Type: the OSPF interface type is either point-to-point, broadcast, NBMA, Point-to-MultiPoint or virtual link 🦋
- State: the functional level of an interface 🌈 state decides whether or not full adjacencies are allowed to form over the interface, and state also shows up in the router's LSAs
- IP interface address: the IP address tied to the interface. it shows up as the IP source address in every routing protocol packet sent over this interface 💜 interfaces to unnumbered point-to-point networks don't have an associated IP address, so no drama there
- IP interface mask: also called the subnet mask 🍓 it marks the portion of the IP interface address that 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 🙈 the link itself isn't assigned an IP network number, so the addresses on each side get assigned independently, if they get assigned at all
- Area ID: the Area ID of the area the attached network belongs to 🌷 every routing protocol packet originating from the interface gets labelled with this Area ID
- HelloInterval: the length of time, in seconds, between the Hello packets the router sends on the interface ⏱️ it's advertised in Hello packets sent out this interface
- RouterDeadInterval: the number of seconds before the router's neighbors declare it down when they stop hearing its Hello Packets 💀 also 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 in 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 with Router Priority set to 0 is ineligible to become Designated Router on the attached network 😭 it's advertised in Hello packets sent out this interface
- Hello Timer: an interval timer that makes the interface send a Hello packet ⏰ it fires every HelloInterval seconds. note that on non-broadcast networks, a separate Hello packet goes to each qualified neighbor 🧚
- Wait Timer: a single shot timer that makes the interface exit the Waiting state and, as a result, select a Designated Router on the network 🎬 the timer length is RouterDeadInterval seconds
- List of neighboring routers: the other routers attached to this network 🫧 the Hello Protocol forms this list. adjacencies will form to 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 👑 it's chosen on all broadcast and NBMA networks by the Hello Protocol. two pieces of identification are kept 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's initialized to 0.0.0.0, which means there's no Designated Router yet 🌸
- Backup Designated Router: also selected on all broadcast and NBMA networks by the Hello Protocol 🦋 all routers on the attached network become adjacent to both the Designated Router and the Backup Designated Router. the Backup Designated Router becomes Designated Router when the current one fails 🛟 it's initialized to 0.0.0.0, meaning 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 belonging to this interface 🔁 it's also used when retransmitting Database Description and Link State Request Packets
- AuType: the type of authentication used on the attached network/subnet 🔐 authentication types are defined in Appendix D. all OSPF packet exchanges are authenticated, and different authentication schemes can be used on different networks/subnets 🌈
- Authentication key: configured data that lets the authentication procedure generate and/or verify OSPF protocol packets 🗝️ it can be configured on a per-interface basis. for example, if the AuType indicates simple password, the Authentication key is a 64-bit clear password inserted into the OSPF packet header. if AuType indicates Cryptographic authentication instead, the Authentication key is a shared secret that enables generating and/or verifying the message digests appended to the OSPF protocol packets. with Cryptographic authentication, multiple simultaneous keys are supported so you get a smooth key transition (see Section D.3) ✨
9.1. Interface states ✨
okay so here's the lineup of states a router interface can be in 🦋 they're listed in order of progressing functionality, so the inoperative one comes first, then a few intermediate ones, and then the final fully functional one 💅 the spec actually uses that ordering too, which is why you'll see stuff like "those interfaces in state greater than X" 👑 Figure 11 shows the graph of state changes, with each arc labelled by the event that causes it 🌈 those events live in Section 9.2, and the detailed state machine is in Section 9.3 🧚
+----+ UnloopInd +--------+
|Down|<--------------|Loopback|
+----+ +--------+
|
|InterfaceUp
+-------+ | +--------------+
|Waiting|<-+-------------->|Point-to-point|
+-------+ +--------------+
|
WaitTimer|BackupSeen
|
|
| NeighborChange
+------+ +-+<---------------- +-------+
|Backup|<----------|?|----------------->|DROther|
+------+---------->+-+<-----+ +-------+
Neighbor | |
Change | |Neighbor
| |Change
| +--+
+---->|DR|
+--+
Figure 11: Interface State changes
In addition to the state transitions pictured,
Event InterfaceDown always forces Down State, and
Event LoopInd always forces Loopback StateDown 💀 this is the initial interface state 🫶 the lower-level protocols have indicated that the interface is unusable, so no protocol traffic at all will be sent or received on it. in this state, 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 looped back. the interface may be looped back in hardware or software 🍓 it will be unavailable for regular data traffic, but it may still be desirable to get info on the quality of the interface, either by sending ICMP pings to it or with something like a bit error test 🔍 so IP packets may still be addressed to an interface in Loopback state ✨ to make that work, these 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 the identity of the (Backup) Designated Router for the network. to do that, it monitors 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 Waiting state 🙅♀️ this prevents unnecessary changes of (Backup) Designated Router, which is honestly such a relief 💜
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. the moment it enters this state, the router attempts to form an adjacency with the neighboring router 🤝 Hello Packets are sent to the neighbor every HelloInterval seconds 📨
DR Other 👀 the interface connects to a broadcast or NBMA network where another router has been selected to be the Designated Router. in this state, the router itself has not been selected as Backup Designated Router either 🙃 it 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 current Designated Router fails 😭 the router establishes adjacencies to all other routers attached to the network. the Backup Designated Router does slightly different things during the Flooding Procedure compared to the Designated Router (see Section 13.3) 🌈 see Section 7.4 for more on what the Backup Designated Router does 🫶
DR 👑 in this state, this router itself is the Designated Router on the attached network. adjacencies are established to all other routers attached to the network 🤝 the router must also originate a network-LSA for the network node 📣 that network-LSA will contain links to all routers (including the Designated Router itself) attached to the network 🕸️ see Section 7.3 for more on the functions the Designated Router performs ✨
9.2. Events causing interface state changes 🔥
state changes can be triggered by a bunch of different events 🎀 they show up as the labelled arcs in Figure 11, and the label definitions are below 💖 for a detailed explanation of how these events affect OSPF protocol operation, check out Section 9.3 🧚
InterfaceUp 🆙 lower-level protocols have indicated that the network interface is operational 🟢 this lets the interface transition out of Down state. on virtual links, the interface operational indication is actually a result of the shortest path calculation (see Section 16.7) 🧮
WaitTimer ⏰ the Wait Timer has fired, which marks the end of the waiting period required before electing a (Backup) Designated Router 🏁
BackupSeen 👀 the router has detected the existence or non-existence of a Backup Designated Router for the network. this happens in one of two ways 🔀 first, a Hello Packet may be received from a neighbor claiming to be the Backup Designated Router itself. alternatively, a Hello Packet may be received from a neighbor claiming to be the Designated Router itself, and indicating that there is no Backup Designated Router. in either case there must be bidirectional communication with the neighbor, i.e., the router must also appear in the neighbor's Hello Packet 🤳 this event signals the end of the Waiting state 🛑
NeighborChange 🔄 there has been a change in the set of bidirectional neighbors associated with the interface, so the (Backup) Designated Router needs to be recalculated 🧠 the following neighbor changes lead to the NeighborChange event. for an explanation of neighbor states, see Section 10.1 📖
- Bidirectional communication has been established to a neighbor. in other words, the state of the neighbor has transitioned to 2-Way or higher 🤝
- There is no longer bidirectional communication with a neighbor. in other words, the state of the neighbor has transitioned to Init or lower 💔
- One of the bidirectional neighbors is newly declaring itself as either Designated Router or Backup Designated Router. this is detected through examination of that neighbor's Hello Packets 👀
- One of the bidirectional neighbors is no longer declaring itself as Designated Router, or is no longer declaring itself as Backup Designated Router. this is again detected through examination of that neighbor's Hello Packets 🙅♀️
- The advertised Router Priority for a bidirectional neighbor has changed. this is again detected through examination of that neighbor's Hello Packets 🔁
LoopInd 🔁 an indication has been received that the interface is now looped back to itself 🪞 this indication can come either from network management or from the lower level protocols 📡
UnloopInd ➡️ an indication has been received that the interface is no longer looped back 🙌 as with LoopInd, this indication can come either from network management or from the lower level protocols 📡
InterfaceDown 🚫 lower-level protocols indicate that this interface is no longer functional 😵 no matter what the current interface state is, the new interface state will be Down 💀
9.3. The Interface state machine 🦋
okay so this is the interface state machine, and it's giving main character energy ✨ Every state change is kicked off by an event (see Section 9.2) 💅 but the same event can do totally different things depending on what state the interface is already in. That's why the machine is organized by current interface state and then received event 🫶 Each entry tells you the new interface state and the actions you need to take.
When an interface changes state, you might need to originate a new router-LSA. See Section 12.4 for more details 🌸
Some of the actions below generate events for the neighbor state machine. Like, when an interface becomes inoperative, every neighbor connection tied to it has to be destroyed 💀 For more on the neighbor state machine, check Section 10.3 🧚
State(s): Down
Event: InterfaceUp
New state: Depends upon action routineOkay so when InterfaceUp hits while the interface is Down, you start the interval Hello Timer, which keeps Hello packets flowing out the interface on a regular schedule 🎀 Then it depends on the network. If the attached network is a physical point-to-point network, a Point-to-MultiPoint network, or a virtual link, the interface moves to Point-to-Point 💖 If that's not the case and the router isn't eligible to become Designated Router, the interface moves to DR Other 🌈
Otherwise, the attached network is a broadcast or NBMA network and the router is eligible to become Designated Router. In this case, the interface goes to Waiting so it can try to discover the attached network's Designated Router, and the single shot Wait Timer starts ⏳ Also, if the network is NBMA, you 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.When BackupSeen happens in Waiting, calculate the attached network's Backup Designated Router and Designated Router, following Section 9.4 👑 That calculation decides the new state, which will be DR Other, Backup or DR. No other options, bestie 💅
State(s): Waiting
Event: WaitTimer
New state: Depends upon action routine.Same energy for WaitTimer in Waiting. You run the exact same calculation from Section 9.4 for the attached network's Backup Designated Router and Designated Router, and the result is still DR Other, Backup or DR ✨
State(s): DR Other, Backup or DR
Event: NeighborChange
New state: Depends upon action routine.If NeighborChange shows up while you're in DR Other, Backup or DR, you recalculate the attached network's Backup Designated Router and Designated Router as shown in Section 9.4 🦋 The result, once again, will be DR Other, Backup or DR. It's giving consistency, honestly 🫶
State(s): Any State
Event: InterfaceDown
New state: DownInterfaceDown is the drama queen of this whole table, and it works from any state 💀 The new state is Down. All interface variables get reset, and the interface timers get disabled. Every neighbor connection tied to the interface also gets destroyed, which happens by generating the event KillNbr on all of the associated neighbors (see Section 10.2) 😭
State(s): Any State
Event: LoopInd
New state: LoopbackLoopInd also works from any state, and it sends the interface into Loopback 🔁 The reason is that the interface isn't connected to the attached network anymore, so you run all the actions that go with the InterfaceDown event above ✨
State(s): Loopback
Event: UnloopInd
New state: DownLast but not least, UnloopInd in Loopback takes the interface back to Down 🌸 No actions are necessary here. For example, the interface variables were already reset when the interface entered Loopback, so there's nothing left to clean up 🧹 Just remember that the interface needs to receive an InterfaceUp event before it becomes fully functional again 💜
9.4. Electing the Designated Router 👑
okay so this section is all about the algorithm for calculating a network's Designated Router and Backup Designated Router 🧠 The Interface state machine is the one that invokes it. The very first time a router runs the election for a network, the network's Designated Router and Backup Designated Router both get set to 0.0.0.0. That value means there's no Designated Router and no Backup Designated Router yet 🫧
Here's how the election goes. Call the router doing the calculation Router X. You look at the list of neighbors attached to the network that have established bidirectional communication with Router X. This list is precisely the collection of Router X's neighbors on this network whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself is also on the list 🎀 Next, you throw out every router on the list that is ineligible to become Designated Router. Routers with a Router Priority of 0 are ineligible 💀 Then the following steps run, but only on the routers that are still on the list:
(1) Note the current values for the network's Designated Router and Backup Designated Router. You'll compare against these later 📝
(2) Calculate the new Backup Designated Router for the network. Only the routers on the list that haven't declared themselves Designated Router are eligible here 🌈 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 gets declared Backup Designated Router 🥇 If there's a tie, the one with the highest Router ID wins. If no routers have declared themselves Backup Designated Router, pick the router with the highest Router Priority (again excluding routers that have declared themselves Designated Router), and use the Router ID to break ties 💖
(3) Calculate the new Designated Router for the network. If one or more routers have declared themselves Designated Router (meaning they list themselves as Designated Router in their Hello Packets), the one with the highest Router Priority is declared Designated Router 👑 If there's a tie, the one with the highest Router ID is chosen. If no routers have declared themselves Designated Router, the Designated Router is set to the same router as the newly elected Backup Designated Router 🫶
(4) If Router X is now newly the Designated Router or newly the Backup Designated Router, or if it's now no longer the Designated Router or no longer the Backup Designated Router, repeat steps 2 and 3, and then move on to step 5 🔁 For example, if Router X is now the Designated Router, then when step 2 is repeated, X won't be eligible for Backup Designated Router election anymore. Among other things, this makes sure that no router ends up declaring itself both Backup Designated Router and Designated Router.[5] 🙈
(5) Because of these calculations, the router itself might now be the Designated Router or the Backup Designated Router. See Sections 7.3 and 7.4 for the extra duties that come with that 🧚 The router's interface state should be set to match. If the router itself is now Designated Router, the new interface state is DR. If 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 the neighbors that aren't eligible to become Designated Router (see Section 9.5.1) 📨 To do that, invoke the neighbor event Start for each neighbor with a Router Priority of 0 💜
(7) If these calculations have changed the identity of either the Designated Router or the Backup Designated Router, the set of adjacencies tied to this interface will need to be modified. Some adjacencies may need to be formed, and others may need to be broken 💅 To make that happen, invoke the event AdjOK? on all neighbors whose state is at least 2-Way. This 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 handover from Backup Designated Router to Designated Router when the current Designated Router fails 🦋 That orderly handover comes from hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities 🫶
The procedure above may elect the same router to be both Designated Router and Backup Designated Router, although 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 either 🌈 If Router X isn't eligible to become Designated Router itself, it's possible that the procedure won't select a Backup Designated Router or a Designated Router at all 💀 And if Router X is the only attached router that's eligible to become Designated Router, it will select itself as Designated Router, and there won't be any Backup Designated Router for the network 👑
9.5. Sending Hello packets ✨
Okay bestie, Hello packets go out of each functioning router interface 📡💖. They're how routers discover and maintain their neighbor relationships.[6] On broadcast and NBMA networks, Hello Packets also help elect the Designated Router and Backup Designated Router 👑.
The format of an Hello packet is in Section A.3.2 🎀. The Hello Packet carries the router's Router Priority (used when choosing the Designated Router) and the interval between Hello Packets sent out the interface (HelloInterval). It also says how often a neighbor has to be heard from to stay active (RouterDeadInterval). HelloInterval and RouterDeadInterval MUST be the same for all routers attached to a common network 🫶. The packet also has 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 adjacent routers can talk both ways, the Hello packet lists every router on the network that has sent a Hello Packet recently 🦋. It also carries the router's current pick for Designated Router and Backup Designated Router. A value of 0.0.0.0 in these fields means nobody has been selected yet 🙈.
On broadcast networks and physical point-to-point networks, Hello packets go out every HelloInterval seconds to the IP multicast address AllSPFRouters 📣. On virtual links, Hello packets are sent as unicasts (addressed directly to the other end of the virtual link) every HelloInterval seconds. On 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 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 is 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 are sent 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 on a timer, and other times it's sent as a reply to a received Hello Packet. How often 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 💜. If the router is itself the Designated Router or Backup Designated Router, it MUST also send periodic Hello Packets to all other neighbors. That means any two eligible routers are always exchanging Hello Packets, which is necessary for the correct operation of the Designated Router election algorithm 🔥. 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 sending Hello packets periodically to any neighbor, the interval depends on that neighbor's state. If the neighbor is in state Down, Hello Packets go out every PollInterval seconds. Otherwise, they go out every HelloInterval seconds ⏱️✨.
10. The Neighbor Data Structure 🎀
An OSPF router chats with its neighboring routers all the time 💬. Each separate conversation is described by a "neighbor data structure". Each conversation is bound to a particular OSPF router interface, and is 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 described by its own unique neighbor data structure 👯. Each separate conversation is loosely called a separate "neighbor" in the text.
The neighbor data structure holds everything about the forming or formed adjacency between two neighbors. (Remember, though, that 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 whose firing means no Hello Packet has been seen from this neighbor recently. The length of the timer is RouterDeadInterval seconds ⏰.
Master/Slave When two neighbors are exchanging 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 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. It's used to figure out whether the next Database Description packet 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) 🪪.
Neighbor Priority The Router Priority of the neighboring router. It's contained in the neighbor's Hello packets, and it's used when selecting 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's also used in router-LSAs as the Link ID for the attached network if the neighboring router is selected to be Designated Router (see Section 12.4.1). The Neighbor IP address is learned when Hello packets are received from the neighbor. For virtual links, the Neighbor IP address is learned during the routing table build process (see Section 15) 🗺️.
Neighbor Options The optional OSPF capabilities supported by the neighbor 🧩. These are learned during the Database Exchange process (see Section 10.6). The neighbor's optional OSPF capabilities are also listed in its Hello packets. This lets received Hello Packets be rejected (i.e., neighbor relationships won't even start to form) if there's a mismatch in certain crucial OSPF capabilities (see Section 10.5) 🚫. The optional OSPF capabilities are documented in Section 4.5.
Neighbor's Designated Router The neighbor's idea of the Designated Router. If this is the neighbor itself, it matters for the local calculation of the Designated Router. Only defined on broadcast and NBMA networks 📻.
Neighbor's Backup Designated Router The neighbor's idea of the Backup Designated Router. If this is the neighbor itself, it matters for the local calculation of the Backup Designated Router. Only defined on broadcast and NBMA networks 🛟.
The next set of variables are lists of LSAs 📚. These lists describe subsets of the area link-state database. This memo defines five distinct types of LSAs, all of which may be present in an area link-state database: router-LSAs, network-LSAs, and Type 3 and 4 summary-LSAs (all stored in the area data structure), and AS-external-LSAs (stored in the global data structure) 🗂️.
Link state retransmission list The list of LSAs that have been flooded but not acknowledged on this adjacency. They'll be 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 goes into Database Exchange state. This list is sent to the neighbor in Database Description packets 📋.
Link state request list The list of LSAs that need to be received from this neighbor in order to synchronize the two neighbors' link-state databases. It's created as Database Description packets are received, then sent to the neighbor in Link State Request packets. The list gets depleted as the appropriate Link State Update packets are received 🥹✨.
10.1. Neighbor states ✨
okay bestie, neighbor states time 🦋 A neighbor's state is really the state of a conversation the router is having with a neighboring router, so it's not about the neighbor itself 💅 The states are listed in order of how functional they get. The inoperative one comes first, then a bunch of intermediate states, then the fully functional one 👑 The spec leans on that ordering too, with stuff like "those neighbors/adjacencies in state greater than X" 🙈 Figures 12 and 13 are the state change graphs, with each arc labelled by the event that causes the change. The neighbor events live in Section 10.2 🌸
Figure 12 is all about the Hello Protocol 💖 That's the thing in charge of neighbor acquisition and maintenance, and of making sure two-way communication is actually happening between neighbors 🫶
Figure 13 shows how an adjacency forms 🔥 Not every pair of neighboring routers ends up adjacent (see Section 10.4), so don't assume it'll happen 🙃 The adjacency starts forming when the neighbor reaches ExStart. Once the two routers work out their master/slave status, it moves to Exchange. Now the neighbor gets used in the flooding procedure, and the two routers start syncing their databases ✨ When that sync is finished, the neighbor is Full and we say the two routers are fully adjacent. At that point the adjacency gets listed in LSAs 🎀
For the detailed version of each state change, plus the extra actions that go with them, check out Section 10.3 🧚
Down 🌙
This is the starting point of a neighbor conversation. It means no recent information has come in from the neighbor 🥺 On NBMA networks, Hello packets may still be sent to "Down" neighbors, just at a reduced frequency (see Section 9.5.1).
+----+
|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,
Event KillNbr always forces Down State,
Event Inactivity Timer always forces Down State,
Event LLDown always 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,
Event SeqNumberMismatch forces ExStart state,
Event BadLSReq forces ExStart state,
Event 1-Way forces Init state,
Event KillNbr always forces Down State,
Event InactivityTimer always forces Down State,
Event LLDown always forces Down State,
Event AdjOK? leads to adjacency forming/breakingAttempt 📮
This state only applies to neighbors attached to NBMA networks 🌐 It means no recent info has come from the neighbor, but we should make a more serious effort to reach them. So we send the neighbor Hello packets at intervals of HelloInterval (see Section 9.5.1).
Init 👀
In this state, a Hello packet has recently been seen from the neighbor 📨 But bidirectional communication isn't set up yet, because the router itself didn't show up in the neighbor's Hello packet 🙈 All neighbors in this state or higher get listed in the Hello packets sent out from the associated interface 💜
2-Way 🤝
In this state, the two routers can talk both ways, and the Hello Protocol is what makes that sure 👑 This is the most advanced state before adjacency establishment starts. The (Backup) Designated Router gets picked from the set of neighbors in 2-Way or greater 🌈
ExStart 🚀
This is the very 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 is describing its whole 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 go out in this state, asking the neighbor for its more recent LSAs. All adjacencies in Exchange state or greater are used by the flooding procedure 🔥 Honestly these adjacencies can transmit and receive all types of OSPF routing protocol packets, so they're fully capable 💪
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 Exchange 🕵️♀️
Full 💯
Here the neighboring routers are fully adjacent, period 🎉 These adjacencies will now show up in router-LSAs and network-LSAs 👑
10.2. Events causing neighbor state changes 🎀
State changes can happen because of a bunch of different events 🌸 They're the stuff shown in the labels on the arcs of Figures 12 and 13. Here's what each label means:
HelloReceived 📨
A Hello packet has been received from the neighbor.
Start 🏁
This is basically a signal that Hello packets should now be sent to the neighbor every HelloInterval seconds 💌 This event only gets generated for neighbors associated with NBMA networks 🌐
2-WayReceived 🤝
Bidirectional communication has been realized between the two neighboring routers 🙌 You can tell because the router 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 transmitted a full sequence of Database Description packets 💅 Each router now knows which parts of its link state database are out of date. For more on how this event gets generated, consult Section 10.8 🧠
BadLSReq 💀
A Link State Request has been received for an LSA that isn't in the database. This means something went wrong in the Database Exchange process 😭
Loading Done 🏆
Link State Updates have been received for all out-of-date portions of the database ✅ You can tell because the link state request list goes empty after the Database Exchange process has completed 🥳
AdjOK? 🤔
A decision has to be made about whether an adjacency should be established or maintained with the neighbor 💭 This event will kick off some adjacencies forming, and destroy others 💥
The following events cause well developed neighbors to revert to lesser states 🍂 Unlike the events above, these can happen when the neighbor conversation is in any of a bunch of different states 🌀
SeqNumberMismatch 🙅♀️
A Database Description packet has been received that either a) has an unexpected DD sequence number, b) unexpectedly has the Init bit set, or c) has an Options field that differs from the last Options field received in a Database Description packet 😬 Any of these means some error happened during adjacency establishment.
1-Way 🙉
A Hello packet has been received from the neighbor, and the router isn't mentioned in it 🫠 That means communication with the neighbor isn't bidirectional.
KillNbr ☠️
This is an indication that all communication with the neighbor is now impossible, so the neighbor is forced back to Down state 💔
InactivityTimer ⏰
The Inactivity Timer has fired 😵 That means no Hello packets have been seen from the neighbor recently, so it reverts to Down state.
LLDown 🔌
This is an indication from the lower level protocols that the neighbor is now unreachable 📡 For example, on an X.25 network this could be signaled by an X.25 clear indication with appropriate cause and diagnostic fields. This event forces the neighbor into Down state 🌈
10.3. The Neighbor state machine
okay so this is the neighbor state machine and it is giving drama 💅✨ Every state change gets kicked off by an event (see Section 10.2), but the same event can do totally different things depending on what state the neighbor is already in 🙈 So the machine is organized by current neighbor state and received event, and each entry tells you the new state plus the extra actions you need to take 🎀
When a neighbor's state changes, you might need to rerun the Designated Router election algorithm 🗳️ Whether you do depends on if the interface NeighborChange event gets generated (see Section 9.2). And if the Interface is in DR state (meaning the router is itself the Designated Router), neighbor state changes can cause a new network-LSA to be originated (see Section 12.4) 🌸
When the neighbor state machine needs to invoke the interface state machine, it should do that as a scheduled task (see Section 4.4) 🧚 This keeps things clean because neither state machine ends up running recursively inside the other. no spaghetti, bestie 🍝🚫
Here are the entries, verbatim so you can see every detail 👀
State(s): Down
Event: Start
New state: Attempt
Action: Send an Hello Packet to the neighbor (this neighbor
is always associated with an NBMA network) and start
the Inactivity Timer for the neighbor. The timer's
later firing would indicate that communication with
the neighbor was not attained.Starting from Down with the Start event moves you to Attempt. You send a Hello and start the Inactivity Timer, and if that timer fires it means the neighbor never answered 💀
State(s): Attempt
Event: HelloReceived
New state: Init
Action: Restart the Inactivity Timer for the neighbor, since
the neighbor has now been heard from.Attempt plus HelloReceived gets you to Init. The neighbor finally talked back, so the Inactivity Timer gets restarted 🦋
State(s): Down
Event: HelloReceived
New state: Init
Action: Start the Inactivity Timer for the neighbor. The
timer's later firing would indicate that the neighbor
is dead.From Down, a HelloReceived also takes you to Init, but this time you start the Inactivity Timer. If it fires later, that means the neighbor is dead ☠️ rip bozo
State(s): Init or greater
Event: HelloReceived
New state: No state change.
Action: Restart the Inactivity Timer for the neighbor, since
the neighbor has again been heard from.If you're already at Init or greater and another HelloReceived comes in, the state stays exactly where it is. You just restart the Inactivity Timer because the neighbor is still around 🫶
State(s): Init
Event: 2-WayReceived
New state: Depends upon action routine.
Action: Determine whether an adjacency should be established
with the neighbor (see Section 10.4). If not, the
new neighbor state is 2-Way.
Otherwise (an adjacency should be established) the
neighbor state transitions to ExStart. Upon
entering this state, the router increments the DD
sequence number in the neighbor data structure. If
this is the first time that an adjacency has been
attempted, the DD sequence number should be assigned
some unique value (like the time of day clock). It
then declares itself master (sets the master/slave
bit to master), and starts sending Database
Description Packets, with the initialize (I), more
(M) and master (MS) bits set. This Database
Description Packet should be otherwise empty. This
Database Description Packet should be retransmitted
at intervals of RxmtInterval until the next state is
entered (see Section 10.8).This is the big moment where Init meets 2-WayReceived 👑 First the router figures out whether an adjacency should happen (see Section 10.4). If not, the neighbor lands in 2-Way. If so, it goes to ExStart, bumps the DD sequence number, and declares itself master by setting the master/slave bit to master. Then it starts sending Database Description Packets with the I, M and MS bits set. That packet should be otherwise empty and gets retransmitted every RxmtInterval until the next state is entered (see Section 10.8) 🎀
State(s): ExStart
Event: NegotiationDone
New state: Exchange
Action: The router must list the contents of its entire area
link state database in the neighbor Database summary
list. The area link state database consists of the
router-LSAs, network-LSAs and summary-LSAs contained
in the area structure, along with the AS-external-
LSAs contained in the global structure. AS-
external-LSAs are omitted from a virtual neighbor's
Database summary list. AS-external-LSAs are omitted
from the Database summary list if the area has been
configured as a stub (see Section 3.6). LSAs whose
age is equal to MaxAge are instead added to the
neighbor's Link state retransmission list. A
summary of the Database summary list will be sent to
the neighbor in Database Description packets. Each
Database Description Packet has a DD sequence
number, and is explicitly acknowledged. Only one
Database Description Packet is allowed outstanding
at any one time. For more detail on the sending and
receiving of Database Description packets, see
Sections 10.8 and 10.6.Once ExStart sees NegotiationDone, the router moves to Exchange and has to list its whole area link state database in the neighbor Database summary list 📚 That means the router-LSAs, network-LSAs and summary-LSAs in the area structure, plus the AS-external-LSAs in the global structure. But AS-external-LSAs get left out for a virtual neighbor, and also left out if the area is configured as a stub (see Section 3.6). LSAs sitting at MaxAge go onto the neighbor's Link state retransmission list instead. The summary gets sent in Database Description packets, each with a DD sequence number and an explicit acknowledgement, and only one of those packets can be outstanding at a time. More details live in Sections 10.8 and 10.6 🫠
State(s): Exchange
Event: ExchangeDone
New state: Depends upon action routine.
Action: If the neighbor Link state request list is empty,
the new neighbor state is Full. No other action is
required. This is an adjacency's final state.
Otherwise, the new neighbor state is Loading. Start
(or continue) sending Link State Request packets to
the neighbor (see Section 10.9). These are requests
for the neighbor's more recent LSAs (which were
discovered but not yet received in the Exchange
state). These LSAs are listed in the Link state
request list associated with the neighbor.When Exchange sees ExchangeDone, it depends on whether the Link state request list is empty. If it is, you're at Full, which is the adjacency's final state, and nothing else is needed ✨ If it isn't, you go to Loading and start (or keep) sending Link State Request packets to ask for the neighbor's newer LSAs, the ones you discovered but haven't received yet (see Section 10.9) 📬
State(s): Loading
Event: Loading Done
New state: Full
Action: No action required. This is an adjacency's final
state.Loading plus Loading Done lands you at Full. Nothing to do, you made it 🏆
State(s): 2-Way
Event: AdjOK?
New state: Depends upon action routine.
Action: Determine whether an adjacency should be formed with
the neighboring router (see Section 10.4). If not,
the neighbor state remains at 2-Way. Otherwise,
transition the neighbor state to ExStart and perform
the actions associated with the above state machine
entry for state Init and event 2-WayReceived.From 2-Way, an AdjOK? check decides things. If no adjacency should form (see Section 10.4), you stay at 2-Way. If one should, you move to ExStart and run the same actions as the Init plus 2-WayReceived entry above 🔁
State(s): ExStart or greater
Event: AdjOK?
New state: Depends upon action routine.
Action: Determine whether the neighboring router should
still be adjacent. If yes, there is no state change
and no further action is necessary.
Otherwise, the (possibly partially formed) adjacency
must be destroyed. The neighbor state transitions
to 2-Way. The Link state retransmission list,
Database summary list and Link state request list
are cleared of LSAs.For ExStart or greater, AdjOK? asks whether the neighbor should still be adjacent. If yes, nothing changes. If no, the possibly half-built adjacency has to be destroyed 💔 The neighbor drops to 2-Way, and the Link state retransmission list, Database summary list and Link state request list all get cleared of LSAs.
State(s): Exchange or greater
Event: SeqNumberMismatch
New state: ExStart
Action: The (possibly partially formed) adjacency is torn
down, and then an attempt is made at
reestablishment. The neighbor state first
transitions to ExStart. The Link state
retransmission list, Database summary list and Link
state request list are cleared of LSAs. Then the
router increments the DD sequence number in the
neighbor data structure, declares itself master
(sets the master/slave bit to master), and starts
sending Database Description Packets, with the
initialize (I), more (M) and master (MS) bits set.
This Database Description Packet should be otherwise
empty (see Section 10.8).Uh oh, SeqNumberMismatch in Exchange or greater means the adjacency gets torn down and then rebuilt from scratch 😭 The neighbor goes back to ExStart, the three lists get cleared, the DD sequence number goes up, and the router declares itself master again and starts sending Database Description Packets with I, M and MS set. Same empty packet as before (see Section 10.8). fresh start, no drama 🌈
State(s): Exchange or greater
Event: BadLSReq
New state: ExStart
Action: The action for event BadLSReq is exactly the same as
for the neighbor event SeqNumberMismatch. The
(possibly partially formed) adjacency is torn down,
and then an attempt is made at reestablishment. For
more information, see the neighbor state machine
entry that is invoked when event SeqNumberMismatch
is generated in state Exchange or greater.BadLSReq is basically SeqNumberMismatch's twin 👯 Same exact action: tear it down, try again, and go look at the SeqNumberMismatch entry above if you want the full details.
State(s): Any state
Event: KillNbr
New state: Down
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs. Also, the Inactivity Timer is disabled.KillNbr works from any state and sends the neighbor to Down. All three lists get cleared, and the Inactivity Timer gets disabled ☠️
State(s): Any state
Event: LLDown
New state: Down
Action: The Link state retransmission list, Database summary
list and Link state request list are cleared of
LSAs. Also, the Inactivity Timer is disabled.LLDown does the exact same cleanup from any state and drops you to Down 📉
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.InactivityTimer also sends you to Down from any state. This time the lists get cleared, but the timer is already doing its thing, so there's no mention of disabling it 💅
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.If you're at 2-Way or greater and a 1-WayReceived shows up, you fall back to Init and clear those three lists 🙃
State(s): 2-Way or greater
Event: 2-WayReceived
New state: No state change.
Action: No action required.2-Way or greater getting another 2-WayReceived means no state change and no action required. Chill 🧘♀️
State(s): Init
Event: 1-WayReceived
New state: No state change.
Action: No action required.Last one! At Init, a 1-WayReceived just leaves you right where you are with nothing to do 🌸
10.4. Whether to become adjacent
okay so not every neighbor gets an adjacency, and that's a whole decision 🤔 Some subset of the router's neighbors get adjacent, and the rules are pretty clear. Routers on point-to-point networks, Point-to-MultiPoint networks and virtual links always become adjacent 💜 On broadcast and NBMA networks, though, every router becomes adjacent to both the Designated Router and the Backup Designated Router 🎀
The adjacency-forming decision happens in two places in the neighbor state machine. The first is when bidirectional communication is 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 these 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 📨
Okay bestie, this part is the deep dive on how a received Hello Packet gets processed 💅 (peep Section A.3.2 for the format of Hello packets 🎀). By now the generic input processing has already checked the IP header and the OSPF packet header, so we're past that. Next, the Network Mask, HelloInterval, and RouterDeadInterval fields in the Hello MUST be checked against what's configured on the receiving interface. Any mismatch means processing stops and the packet gets dropped 🙅♀️. These fields are really describing the attached network's config, so they have to line up. BUT there's one lowkey exception 👀: 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 (yes, that could be the backbone 🌈). The E-bit in the Hello's Options field has to match that area's ExternalRoutingCapability. If AS-external-LSAs aren't flooded into or throughout the area (aka the area is a "stub" 🧸), the E-bit MUST be clear in received Hello Packets. Otherwise the E-bit MUST be set. A mismatch means processing stops and the packet is dropped. The rest of the bits in the Options field SHOULD be ignored 🤷♀️.
Now we try to match the source of the Hello to one of the receiving interface's neighbors 🔍. If the 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 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 neighbor list lives in the interface's data structure. If no matching neighbor structure exists (aka this is the first time we've spotted this neighbor 👀), one gets created, and its initial state is set to Down 🌸.
When a Hello comes in from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID to the Router ID from the packet's OSPF header. On a point-to-point network (but not on a virtual link), set the neighbor structure's Neighbor IP address to the packet's IP source address 💖.
Now the rest of the Hello gets examined, generating events for the neighbor and interface state machines 🦋. These state machines are either executed or scheduled (see Section 4.4 💜). For example, if the neighbor state machine is 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, the Hello Packet's
Router Priorityfield is examined. If this field is different than the one previously received from the neighbor, the receiving interface's state machine is scheduled with the eventNeighborChange. In any case, theRouter Priorityfield in the neighbor data structure SHOULD be updated accordingly 🍓. - Next the
Designated Routerfield in the Hello Packet is examined. If the neighbor is both declaring itself to be Designated Router (Designated Routerfield = Neighbor IP address) and theBackup Designated Routerfield in the packet is equal to0.0.0.0and the receiving interface is in stateWaiting, the receiving interface's state machine is scheduled with the eventBackupSeen🙌. Otherwise, if the neighbor is declaring itself to be Designated Router and it had not previously, or the neighbor is not declaring itself Designated Router where it had previously, the receiving interface's state machine is scheduled with the eventNeighborChange🔥. In any case, the Neighbors' Designated Router item in the neighbor structure is updated accordingly. - Finally, the
Backup Designated Routerfield in the Hello Packet is examined. If the neighbor is declaring itself to be Backup Designated Router (Backup Designated Routerfield = Neighbor IP address) and the receiving interface is in stateWaiting, the receiving interface's state machine is scheduled with the eventBackupSeen🎀. Otherwise, if the neighbor is declaring itself to be Backup Designated Router and it had not previously, or the neighbor is not declaring itself Backup Designated Router where it had previously, the receiving interface's state machine is scheduled with the eventNeighborChange🌈. In any case, the Neighbor's Backup Designated Router item in the neighbor structure is updated accordingly.
On NBMA networks, receipt of 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 ✨
okay so this section is the deep dive on how a received Database Description Packet gets processed 🧚. by the time it gets here, the generic input packet processing (Section 8.2) has already matched it up with a neighbor and a receiving interface 💅. whether it gets accepted, and what happens next, totally depends on the neighbor state 🫶
if a Database Description packet is accepted, save these fields in the corresponding 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 those fields are set identically in two consecutive Database Description packets from the neighbor, the second one counts as a "duplicate" in everything below 👯
if the Interface MTU field shows an IP datagram size that's bigger than what the router can accept on the receiving interface without fragmentation, the packet gets rejected 🙅. otherwise, here's what happens based 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 SHOULD then continue in that new state by falling through to case ExStart below 🦋
2-Way
The packet SHOULD be ignored. Database Description Packets are only used for bringing up adjacencies, so that's all they're for 🙈[7]
ExStart
if the received packet matches one of the following cases, then the neighbor state machine SHOULD be executed with the event NegotiationDone (which moves the state 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)andmaster(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 the one specified by the master. - The
initialize(I)andmaster(MS)bits are off, the packet's DD sequence number equals the neighbor data structure's DD sequence number (that's the acknowledgment 🤝), and the neighbor's Router ID is smaller than the router's own. in this case the router is Master 👑.
Exchange
duplicate Database Description packets get discarded by the master, and they make the slave retransmit the last Database Description packet it sent 🔁. otherwise (the packet is not a duplicate):
- if the state of the MS-bit doesn't match the master/slave state of the connection, generate the neighbor event
SeqNumberMismatchand 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 were previously received from the neighbor (recorded in the Neighbor Options field 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 one 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 one stored in the neighbor data structure. either way, if the packet is next in sequence, it SHOULD be accepted and its contents processed as described below ✅.
- anything 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, so it's basically done with the chat 🎉. the only packets that should show up are duplicates (see above). in particular, the packet's Options field SHOULD match the set of optional OSPF capabilities the neighbor already indicated (stored in the neighbor structure's Neighbor Options field) 🧐. any other packets received, including one with the Initialize(I) bit set, SHOULD generate the neighbor event SeqNumberMismatch.[8] duplicates SHOULD be discarded by the master, and 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 gets checked for validity. if the LS type is unknown (for example, not one of the LS types 1-5 defined by this specification), or if this is an AS-external-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 the LSA up in its database to see whether it also has an instance of that LSA 👀. if it doesn't, or if its database copy is less recent (see Section 13.1), the LSA goes on the Link state request list, so it can be requested (right away 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 packet that was just accepted has the more bit (M) set to 0, the neighbor event ExchangeDone gets 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 gets generated 🏁. note that the slave always generates this event before the master 🥇.
10.7. Receiving Link State Request Packets 🎀
this section explains the detailed processing of received Link State Request packets 📦. these are basically the neighbor asking for a list of LSAs they want 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 went wrong with the Database Exchange process, and the neighbor event BadLSReq SHOULD be generated 😬.
10.8. Sending Database Description Packets 🍰
this section walks through how Database Description Packets get sent to a neighbor 📤. the Interface MTU field in the Database Description packet SHOULD be set to the size of the largest IP datagram that can go 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 the router's optional capabilities somehow change, the Database Exchange procedure SHOULD be restarted by going back to neighbor state ExStart 🔁. 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 0️⃣.
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 get 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) gets 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 get removed from the Database summary list once the previous packet is acknowledged ✔️.
in state Exchange, when a Database Description packet gets sent depends on whether the router is master or slave 🎭:
Master
Database Description packets are sent when either a) the slave acknowledges the previous one by echoing the DD sequence number, or b) RxmtInterval seconds pass without an acknowledgment, in which case the previous Database Description packet gets 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 gets sent. otherwise, the previous Database Description packet gets resent 💌.
in states Loading and Full, the slave MUST resend its last Database Description packet in response to duplicate Database Description packets received from the master 🥹. for this reason the slave MUST wait RouterDeadInterval seconds before freeing the last Database Description packet ⌛. 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 ✨
okay so, in neighbor states Exchange or Loading, the Link state request list 📋 holds all the LSAs that a router still needs to grab from its neighbor. 🦋 To ask for them, the router sends the neighbor the beginning of that list, packed up in a Link State Request packet 💌
when the neighbor answers with the right Link State Update packet(s), the router chops off the part of the list that got answered and sends a fresh Link State Request packet ✂️ this keeps going until the Link state request list is totally empty 🎉 and any Link State Request packets that haven't been answered get resent every RxmtInterval ⏰ also, there should be at most one Link State Request packet outstanding at any one time, so no spamming your bestie with requests 🙈
once the Link state request list is empty AND the neighbor state is Loading (aka a complete run of Database Description packets has been sent to and received from the neighbor), the router generates the Loading Done neighbor event 🥳 that's the signal that the adjacency is basically caught up 💅
10.10. An Example 🌸
okay this is my favorite part, we're going to watch an adjacency form in real time 🧚 Figure 14 shows it happening. so we've got RT1 and RT2, both hanging out on the same broadcast network 🌈 RT2 is the Designated Router for that network, and RT2 has a higher Router ID than RT1 👑
the neighbor state changes each router goes through are listed on the sides of the figure, so keep your eyes peeled 👀
at the very start, RT1's interface to the network comes up ✨ it starts blasting Hello Packets, even though it has no clue who the Designated Router is or who any of its other neighbors are 🙈 RT2 hears that hello (so RT1 moves to Init state on RT2's side 🫶), and then RT2's next Hello Packet says "hey, I'm the Designated Router, and I've heard your hellos" 💜 that pushes RT1 into ExStart as it starts bringing up the adjacency 🔥
RT1 starts out by claiming it's the master 😤 but when it sees that RT2 is actually the master (because RT2 has the higher Router ID), RT1 flips to slave state and adopts its neighbor's DD sequence number 🎀 now Database Description packets get swapped, with the polls coming from the master (RT2) and the responses coming from the slave (RT1) 💖 this whole sequence wraps up when both the poll and its response have the M-bit off 🏁
in this example, RT2 already has a completely up to date database 🙌 so RT2 goes straight to Full state 💅 RT1 gets to Full too, once it updates the parts of its database it's missing 🦋 it does that by sending Link State Request Packets and getting Link State Update Packets back 📬
one tea ☕ RT1 waited until it had received a full set of Database Description Packets from RT2 before sending any Link State Request Packets, but that isn't required. RT1 could have mixed sending Link State Request Packets in with receiving Database Description Packets too 🍓
+---+ +---+
|RT1| |RT2|
+---+ +---+
Down Down
Hello(DR=0,seen=0)
------------------------------>
Hello (DR=RT2,seen=RT1,...) Init
<------------------------------
ExStart D-D (Seq=x,I,M,Master)
------------------------------>
D-D (Seq=y,I,M,Master) ExStart
<------------------------------
Exchange D-D (Seq=y,M,Slave)
------------------------------>
D-D (Seq=y+1,M,Master) Exchange
<------------------------------
D-D (Seq=y+1,M,Slave)
------------------------------>
...
...
...
D-D (Seq=y+n, Master)
<------------------------------
D-D (Seq=y+n, Slave)
Loading ------------------------------>
LS Request Full
------------------------------>
LS Update
<------------------------------
LS Request
------------------------------>
LS Update
<------------------------------
Full
Figure 14: An adjacency bring-up example11. The Routing Table Structure ✨
okay so the routing table is literally the brain of the router 🧠✨ it holds everything needed 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 packet shows up, the router hunts for the entry that gives the best match for the packet's IP destination, and that entry tells it the next hop toward the destination 💅 OSPF also has a default route (Destination ID = DefaultDestination, Address Mask = 0x00000000). When it exists, it matches every single IP destination (though any other matching entry is a better match, ngl 💀). Finding the entry that best matches an IP destination is explained more in Section 11.1 🎀
There is exactly one routing table in each router 👑 Two sample routing tables are described in Sections 11.2 and 11.3 🌈 and the building of the routing table is discussed in Section 16 🧚
The rest of this section defines the fields found in a routing table entry. The first set of fields describes the 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 used solely 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 also falls into this category ✨
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 supported by the destination router. 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. This means there may 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 has led to the routing table entry's collection of paths. This is called the entry's associated area. For sets of AS external paths, this field is not defined. For destinations of type "router", there may be separate sets of paths (and therefore separate routing table entries) associated with each of several areas. For example, this will happen 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 one of the paths contained in a routing table entry is of the same path-type and cost (see below) ✨
Path-type
There are four possible types of paths used to route traffic to the destination, listed here in order of preference: intra-area, inter-area, type 1 external or type 2 external. Intra-area paths indicate destinations belonging to one of the router's attached areas. Inter-area paths are paths to destinations in other OSPF areas. These are discovered through the examination of received summary-LSAs. AS external paths are paths to destinations external to the AS. These are detected through the examination of 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 is the most significant part of the total path cost. For example, a type 2 external path with type 2 cost of 5 is always preferred over a path with type 2 cost of 10, regardless of the cost of the two paths' internal components 😭🔥
Link State Origin
Valid only for intra-area paths, this field indicates the 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, however a tie-breaking scheme always reduces the choice to a single LSA. The Link State Origin field is not used by the OSPF protocol, but it is used by the routing table calculation in OSPF's Multicast routing extensions (MOSPF) 🍓
When multiple paths of equal path-type and cost exist to a destination (called elsewhere "equal-cost" paths), they are stored in a single routing table entry. Each one of the "equal-cost" paths is distinguished by the following fields 🌈
Next hop
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 towards 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. This routing table entry then provides the outgoing interface and next hop router to use in forwarding the packet. This section describes the process of finding the best matching routing table entry. The process consists of a number of steps, wherein the collection of routing table entries is progressively pruned. In the end, the single routing table entry remaining is called the "best match" 🔥
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] 💖
Note that the steps described below may fail to produce a best match routing table entry (i.e., all existing routing table entries are pruned for some reason or another), or the best match routing table entry may be one of the above "discard" routing table entries. In these cases, the packet's IP destination is considered unreachable. Instead of being forwarded, the packet should be discarded and an ICMP destination unreachable message should be returned to the packet's source 😭
(1) Select the complete set of "matching" routing table entries from the routing table. Each routing table entry describes a (set of) path(s) to a range of IP addresses. If the data packet's IP destination falls into an entry's range of IP addresses, the routing table entry is called a match. (It is quite likely that multiple entries will match the data packet. For example, a default route will match all packets.) 🧚
(2) Reduce the set of matching entries to those having the most preferential path-type (see Section 11). OSPF has a four level hierarchy of paths. Intra-area paths are the most preferred, followed in order by inter-area, type 1 external and type 2 external paths 👑
(3) Select the remaining routing table entry that provides the most specific (longest) match. Another way of saying this is to choose the remaining 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 🌸
11.2. Sample routing table, without areas
Consider the Autonomous System pictured in Figure 2. No OSPF areas have been configured. A single metric is shown per outbound interface. The calculation of Router RT6's routing table proceeds as described in Section 2.2. The resulting routing table is shown in Table 12. Destination types are abbreviated: Network as "N", Router as "R" ✨
There are no instances of multiple equal-cost shortest paths in this example. Also, since there are no areas, there are no inter-area paths 🫶
Routers RT5 and RT7 are AS boundary routers. Intra-area routes have been calculated to Routers RT5 and RT7. This allows external routes to be calculated to the destinations advertised by RT5 and RT7 (i.e., Networks N12, N13, N14 and N15). It is assumed all AS-external-LSAs originated by RT5 and RT7 are advertising type 1 external metrics. This results in type 1 external paths being calculated to destinations N12-N15 🦋
11.3. Sample routing table, with areas 🗺️
okay so bestie, let's take that last example and split it up into OSPF areas 💅 An OSPF area configuration is pictured in Figure 6. We're gonna look at Router RT4's routing table for this setup. RT4 is connected to Area 1 and the backbone, so it sees the AS as the combo of the two graphs in Figures 7 and 8. The result is in Table 13 ✨
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).Okay, so RT5 and RT7 are both AS boundary routers 🫶 RT3, RT4, RT7, RT10 and RT11 are area border routers 🦋 RT3 gets two routing entries because it shares two areas with RT4 (Area 1 and the backbone). Iconic, honestly.
Backbone paths are calculated to every area border router, and those paths get used when figuring out the inter-area routes. All the inter-area routes are tied to the backbone. That's always the case when the calculating router is itself an area border router, so no surprises there 🌸 Routing info also gets condensed at area boundaries. In this example, Area 3 is set up so that N9-N11 and the host route to H1 all get squished into one route when RT11 advertises them into the backbone. The cost of that condensed route is the maximum of the costs of its individual components. Main character cost calculation, ngl 💜
There's a virtual link between RT10 and RT11 🧚 Without that configured virtual link, RT11 couldn't advertise a route for N9-N11 and Host H1 into the backbone, and RT4's routing table would have no entry for those networks at all 💀
There are two equal-cost paths to Network N12, but they both go through the same next hop, which is RT5. Simple and clean 🍓
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.Now here's the glow-up 🌈 RT4's routing table would get better (some paths would get shorter) if you added another virtual link between RT4 and RT3. That new virtual link would be tied to the first RT3 entry in Table 13, which is the intra-area path through Area 1. That gives the virtual link a cost of 1 ✨ The changes to the routing table from adding this link are in Table 14.
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) 💜
Every router in the Autonomous System originates one or more link state advertisements (LSAs) 🫶 This memo defines five distinct types of LSAs, which we'll get into in Section 4.3. All of them together form the link-state database. Each type has its own job, though 💅 Router-LSAs and network-LSAs describe how an area's routers and networks are connected. Summary-LSAs are the way to condense an area's routing info. AS-external-LSAs are how you transparently advertise externally-derived routing info across the whole Autonomous System. Serving organization, honestly 👑
Each LSA starts with a standard 20-byte header. We'll break that header down below 🎀
12.1. The LSA Header 🌸
The LSA header has the LS type, Link State ID and Advertising Router fields. Put those three together and you get a unique ID for the LSA 🦋
There can be several instances of the same LSA in the Autonomous System all at once. When that happens, somebody has to figure out which instance is more recent. That's decided by checking the LS sequence, LS checksum and LS age fields, which also live in that 20-byte header 🔥
Lots of OSPF packet types list LSAs. When which instance it is doesn't matter, you just refer to the LSA by its LS type, Link State ID and Advertising Router (check out Link State Request Packets). Otherwise, you also need the LS sequence number, LS age and LS checksum fields 🧚
Here's a detailed rundown of the fields in the LSA header, coming right up 💖
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's set to 0 when the LSA is originated. It must be incremented by InfTransDelay on every hop of the flooding procedure. LSAs also age while they're sitting in each router's database 🙈
The age of an LSA never goes past MaxAge. LSAs with age MaxAge are not used in the routing table calculation. When an LSA's age first hits MaxAge, it gets reflooded. An LSA at MaxAge is finally flushed from the database once it's no longer needed to keep databases in sync. For more on how LSAs age, go check Section 14 📚
The LS age field gets checked when a router receives two instances of an LSA that have identical LS sequence numbers and LS checksums. An instance with age MaxAge is always accepted as the most recent, which lets old LSAs get flushed out of the routing domain quickly 🧹 Otherwise, if the ages differ by more than MaxAgeDiff, the instance with the smaller age is accepted as most recent.[12] See Section 13.1 for the full details 💀
12.1.2. Options 🎛️
The Options field in the LSA header shows which optional capabilities are associated with the LSA. OSPF's optional capabilities are described in Section 4.5. This specification defines one optional capability, represented by the E-bit in the Options field. Any unrecognized bits in the Options field should be set to zero. The E-bit represents OSPF's ExternalRoutingCapability. This bit should be set in all LSAs associated with the backbone, and in all LSAs associated with non-stub areas (see Section 3.6). It should also be set in all AS-external-LSAs. It should be reset in all router-LSAs, network-LSAs and summary-LSAs associated with a stub area. For all LSAs, the E-bit is for informational purposes only; it doesn't affect the routing table calculation 🫧
12.1.3. LS type 🏷️
The LS type field decides the format and function of the LSA. LSAs of different types have different names, like router-LSAs or network-LSAs 🎀 Every LSA type defined by this memo gets flooded throughout a single area only, except for AS-external-LSAs (LS type = 5). Those get flooded throughout the entire Autonomous System, excluding stub areas (see Section 3.6) 🌍 Each separate LSA type is briefly described below in Table 15 ✨
12.1.4. Link State ID 💖
okay so this field tells you which piece of the routing domain the LSA is describing 👀 what goes in it depends on the LSA's LS type, and Table 16 has the full tea 🫖
ok wait, plot twist 🙈 for Type 3 summary-LSAs (LS type = 3) and AS-external-LSAs (LS type = 5), the Link State ID can also have one or more of the destination network's "host" bits set. for example, if you're originating an AS-external-LSA for the network 10.0.0.0 with mask 255.0.0.0, the Link State ID can be anything from 10.0.0.0 through 10.255.255.255 inclusive (but 10.0.0.0 should be used whenever possible 💅). this freedom is what lets a router originate separate LSAs for two networks that have the same address but different masks 🦋 see Appendix E for the details.
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).
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.when the LSA is describing a network (LS type = 2, 3 or 5), you can easily get the network's IP address by masking the Link State ID with the network/subnet mask 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 has the OSPF Router ID of whoever originated the LSA 💌 for router-LSAs, it's identical to the Link State ID field. network-LSAs get originated by the network's Designated Router, summary-LSAs get originated by area border routers, and AS-external-LSAs get originated by AS boundary routers 🫶
12.1.6. LS sequence number 🔢
ok this one is so good 😭 the sequence number field is a signed 32-bit integer, and it's how routers figure out which LSAs are old and which are duplicates 🕵️♀️ the space of sequence numbers is linearly ordered, so the bigger the number (compared as signed 32-bit integers), the more recent the LSA. to get precise, in the discussion below let N stand for the constant 2**31 🧮
the sequence number -N (0x80000000) is reserved and unused 🚫 that leaves -N + 1 (0x80000001) as the smallest, and therefore oldest, sequence number. this one is called the constant InitialSequenceNumber 🍼 a router uses InitialSequenceNumber the first time it originates any LSA. after that, the LSA's sequence number goes up by one each time the router originates a new instance of it ✨
now the spicy part 🌶️ when someone tries to increment the sequence number past the maximum value of N - 1 (0x7fffffff, also called MaxSequenceNumber), the current instance of the LSA has to be flushed from the routing domain first 💀 this happens by prematurely aging the LSA (see Section 14.1) and reflooding it. once every adjacent neighbor has acknowledged that flood, a new instance can be originated with the sequence number InitialSequenceNumber 🔄
a router may be forced to bump the sequence number of one of its LSAs when a more recent instance of that LSA shows up unexpectedly during flooding. this should be a rare event 🙏 it may mean that an out-of-date LSA, originated by the router itself before its last restart/reload, is still floating around the Autonomous System 👻 for more info, see Section 13.4.
12.1.7. LS checksum 🧮
this field is the checksum of the complete contents of the LSA, except the LS age field 🙃 the LS age is left out so an LSA's age can keep ticking up without the checksum needing an update. the checksum is the same one used for ISO connectionless datagrams, commonly called the Fletcher checksum, and it's documented in Annex B of [Ref6] 📚 the LSA header also has the LSA's length in bytes. subtract the size of the LS age field (two bytes) and you get the amount of data to checksum 💅
the checksum is there to catch data corruption in an LSA, which can happen while the LSA is being flooded or while it's sitting in a router's memory 🛡️ the LS checksum field can't be zero, and a zero value should be considered a checksum failure. basically, calculating the checksum is not optional 🫡
an LSA's checksum gets verified in two situations: a) when it's received in a Link State Update Packet, and b) at times during the aging of the link state database. a checksum failure leads to different actions in each case, so check out Sections 13 and 14 for the details 👀
whenever the LS sequence number field says two instances of an LSA are the same, the LS checksum field gets examined. if they differ, the instance with the larger LS checksum is considered the 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, and all routers in the same area have identical link state databases for that area 👯
each area's database is always dealt with separately ✂️ the shortest path calculation is run separately for each area (see Section 16), components of an area's link-state database only get flooded throughout that area, and when an adjacency (belonging to Area A) is being brought up, only the Area A database gets synchronized between the two routers 💕
the area database is made up of router-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 OSPF implementation 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's only a single instance of each LSA in the database (the most up-to-date one) ✨ the lookup function gets invoked during the LSA flooding procedure (Section 13) and the routing table calculation (Section 16). using this lookup function, a router can also figure out whether it has ever originated a particular LSA and, if so, what LS sequence number it used 🕵️♀️
an LSA gets added to a router's database when either a) it's received during flooding (Section 13) or b) the router originates it itself (Section 12.4). an LSA gets deleted from a router's database when either a) it's been overwritten by a newer instance during flooding (Section 13), b) the router originates a newer instance of one of its self-originated LSAs (Section 12.4), or c) the LSA ages out and gets 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 older versions of the OSPF specification ([Ref9]), TOS-specific info can be included in router-LSAs, summary-LSAs and AS-external-LSAs 🧸 the way TOS gets encoded in OSPF LSAs is laid out in Table 17. that table connects the OSPF encoding to the TOS field in the IP packet header (defined in [Ref12]) 🌸 the OSPF encoding is written as a decimal integer, while the IP packet header's TOS field uses the binary TOS values from [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 OSPF area is gonna have a bunch of LSAs getting originated 💅 Each router originates a router-LSA. And if the router is the Designated Router for any of the area's networks, it also originates network-LSAs for those networks 🦋
Area border routers originate a single summary-LSA for each known inter-area destination. AS boundary routers originate a single AS-external-LSA for each known AS external destination. Destinations get advertised one at a time, so when one route changes, only that route gets flooded and not the whole collection of routes 🫶 During flooding, lots of LSAs can ride along in a single Link State Update packet 📦
Okay, example time! Look at Router RT4 in Figure 6. It's an area border router with a connection 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). RT4 also originates 8 distinct LSAs into Area 1 (one router-LSA and seven summary-LSAs, as pictured in Figure 7). And if RT4 has been selected as Designated Router for Network N3, it will also originate a network-LSA for N3 into Area 1 💜
Now, Router RT5 in that same figure is originating 3 distinct AS-external-LSAs (one for each of the networks N12-N14) 🧚 These get flooded through the entire AS, assuming none of the areas have been configured as stubs. But if area 3 has been configured as a stub area, the AS-external-LSAs for N12-N14 will not be flooded into area 3 (see Section 3.6). Instead, Router RT11 would originate a default summary-LSA that gets flooded throughout area 3 (see Section 12.4.3). This basically 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, itsLS sequence numberis incremented, itsLS ageis set to 0, itsLS checksumis calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces. See Section 13.2 for the details on installing the LSA into the link state database, and Section 13.3 for the details on flooding newly originated LSAs 🔥
Okay, now the ten events that can cause a new instance of an LSA to be originated 👑
(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 is originated, even though the contents of the LSA (apart from the LSA header) will be the same. This guarantees periodic originations of all LSAs, and this periodic updating adds robustness to the link state algorithm 💖 LSAs that solely describe unreachable destinations should not be refreshed. They should instead be flushed from the routing domain (see Section 14.1) 💀
When whatever is being described by an LSA changes, a new LSA gets originated. However, two instances of the same LSA may not be originated within the time period MinLSInterval, so the generation of the next instance may get delayed by up to MinLSInterval 🙈 The following events may cause the contents of an LSA to change. 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 it's necessary to produce a new instance of the router-LSA 🍓
(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 it's necessary to produce a new instance of the router-LSA. 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 should 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 (i.e., 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 ✨
okay so a router makes a router-LSA for every area it belongs to 🎀 Each one describes the router's collected states of its links to that area. It gets flooded throughout that particular area, and no further 🙈 The format lives in Appendix A (Section A.4.2), and the first 20 bytes are the generic LSA header we covered in Section 12.1. Router-LSAs have LS type = 1 🦋
A router also flags whether it's an area border router or an AS boundary router by setting the right bits 💅
....................................
. 192.1.2 Area 1 .
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ _______N3 .
. + \/ \ . 1+---+
. * 192.1.1 *------|RT4|
. + /\_______/ . +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+8 . 6+---+
. | |RT3|----------------|RT6|
. + +---+ . +---+
. 192.1.3 |2 . 18.10.0.6|7
. | . |
. +------------+ .
. 192.1.4 (N4) .
....................................
Figure 15: Area 1 with IP addresses shown(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 it's the endpoint of one or more fully adjacent virtual links that have Area A as their Transit area. Bit V is how 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 by the kind of attached network, and each one gets a Link ID that names the entity on the other end 💜 Table 18 has the rundown of Type and Link ID values:
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.Every link also gets a Link Data field, which holds 32 bits of extra info 🍓 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, see 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 gets specified 💖 The output cost of a link is configurable. Except for links to stub networks, the output cost must always be non-zero.
Okay, so how do you actually build the list of link descriptions? Say a router wants to build a router-LSA for Area A 🔥 It checks its collection of interface data structures, and for each interface:
- If the attached network doesn't belong to Area A, no links get added to the LSA, and you move on to the next interface.
- 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 it isn't 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 for point-to-point interfaces are 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 all the router interfaces are considered, host links get added to the router-LSA by looking through the list of attached hosts that belong to Area A 🌈 A host route is represented as a Type 3 link (stub network) whose Link ID is the host's IP address, whose Link Data is the all-ones mask (0xffffffff), and whose 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 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, a single link description gets added to the router-LSA like so 🫶
- 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.
- Otherwise, there's a Designated Router elected for the attached network. If the router is fully adjacent to the Designated Router, or if the router itself is the 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 only gets added to the router-LSA 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 as follows 🌸
- 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 ✨
Okay bestie, let's look at the router-LSAs that RT3 makes 🎀 Check out Figure 6 first, then peek at Area 1 with real network addresses in Figure 15. Pretend the last byte of every RT3 interface is 3, so it has 192.1.1.3 and 192.1.4.3, and the other routers have similar addressing vibes 💅 We're also assuming every link works, and Router IDs are the smallest IP interface address.
RT3 makes two router-LSAs, one for Area 1 and one for the backbone. Let's say Router RT4 got picked as the Designated Router for network 192.1.1.0. RT3's Area 1 router-LSA says RT3 has two connections into Area 1: a link to the transit network 192.1.1.0, and a link to the stub network 192.1.4.0. The transit network is named by its Designated Router's IP interface, so the Link ID = 192.1.1.4 is RT4's interface to 192.1.1.0 🦋 RT3 also flags itself as an area border router, which is so iconic of it 👑
; 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 backbone router-LSA 💜 RT3 only has one attachment to the backbone, and that's an unnumbered point-to-point link to Router RT6. Once again, RT3 marks itself as 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 gets generated for every transit broadcast or NBMA network. (Quick reminder: a transit network is one with two or more attached routers.) The network-LSA describes every router attached to that network, so it's basically the guest list 🎀
The Designated Router for the network is the one that originates the LSA. It only does that if it's fully adjacent to at least one other router on the network. The network-LSA gets flooded throughout the area containing the transit network, and not any further 🛑 It lists the routers that are fully adjacent to the Designated Router, with each one identified by its OSPF Router ID. The Designated Router puts itself on that list too 💅
The Link State ID for a network-LSA is the IP interface address of the Designated Router. Mask that value with the network's address mask (which also lives in the network-LSA) and you get the network's IP address 🔥
Now here's some drama 🙈 A router that used to be the Designated Router for a network, but isn't anymore, should flush the network-LSA it originated before. That LSA doesn't get used in the routing table calculation anymore. To flush it, you prematurely bump the LSA's age to MaxAge and reflood (see Section 14.1). There's another case too: if a router's Router ID has changed, any network-LSAs that were originated with the old Router ID must be flushed. The router might have no idea what its previous Router ID was, so these network-LSAs are spotted by having their Link State ID equal one of the router's IP interface addresses, and their Advertising Router equal 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 ⭐
Let's look at the Figure 6 area setup again 🍓 Network-LSAs are originated for Network N3 in Area 1, Networks N6 and N8 in Area 2, and Network N9 in Area 3. Say Router RT4 was picked as the Designated Router for Network N3. Then RT4 generates this network-LSA on behalf of Network N3 (check 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 🌈
A summary-LSA describes one of three things: an IP network, an AS boundary router, or a range of IP addresses. These get flooded throughout a single area only. The destination it describes sits outside that area but still belongs to the Autonomous System 💖
Area border routers are the ones that originate summary-LSAs. Which summary routes get advertised into an area comes from looking at the routing table structure (see Section 11), following the algorithm below. Heads up: only intra-area routes get advertised into the backbone, while both intra-area and inter-area routes get advertised into the other areas 🫶
To decide which routes go out to an attached Area A, process each routing table entry like this. Remember that each routing table entry describes a set of equal-cost best paths to one 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, skip to 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, skip to the next routing table entry.
- Else, if the area associated with this set of paths is Area A itself, don't generate a summary-LSA for the route.[17]
- Else, if the next hops associated with this set of paths belong to Area A itself, don't 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. That means the network sits inside one of the router's directly attached areas. Generally, this info has to be condensed before it shows up in summary-LSAs. Remember that an area has a configured list of address ranges, where each range is an [address,mask] pair with a status of either Advertise or DoNotAdvertise. At most a single Type 3 summary-LSA is originated for each range. When the range's status is Advertise, 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 is DoNotAdvertise, the Type 3 summary-LSA gets suppressed and the component networks stay hidden from other areas 🙈
By default, if a network isn't inside 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 can carry transit traffic (meaning its TransitCapability is set to TRUE), routing info about backbone networks should not be condensed before being summarized into the area. The advertisement of backbone networks into transit areas shouldn't get suppressed either. Put simply, the backbone's configured ranges should be ignored when originating summary-LSAs into transit areas 🌊
If a router advertised a summary-LSA for a destination that then becomes unreachable, the router must flush that LSA from the routing domain by setting its age to MaxAge and reflooding (see Section 14.1). Also, if the destination is still reachable but can no longer be advertised under the procedure above (for example, it's now an inter-area route when it used to be an intra-area route tied to some non-backbone area, so it would 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 ✨
okay so the algorithm in Section 12.4.3 is optional 💅 when Area A is an OSPF stub area. Area border routers hooked up to a stub area can originate summary-LSAs into it using the Section 12.4.3 algorithm, OR they can choose to originate only a subset of them, maybe because of configuration control 🎀. Fewer LSAs means a smaller link state database for the stub area, which takes some pressure off its routers' resources ✨. BUT omitting LSAs might lead to sub-optimal inter-area routing, although routing will still work 🙈.
As specified in Section 12.4.3, Type 4 summary-LSAs (ASBR-summary-LSAs) are never originated into stub areas 🚫. That's a hard no, bestie 💀.
In a stub area, the area border routers don't import external routes. Instead, each one originates a "default summary-LSA" into the area 🧚. The Link State ID for that default summary-LSA is set to DefaultDestination, and its metric is set to the per-area configurable parameter StubDefaultCost 🍓. Also, StubDefaultCost doesn't have to be configured the same way on every area border router in the stub area, so don't panic if they differ 🌈.
12.4.3.2. Examples of summary-LSAs 🦋
Consider again the area configuration in Figure 6 🗺️. Routers RT3, RT4, RT7, RT10 and RT11 are all area border routers, so they're originating summary-LSAs. Let's focus on Router RT4 🔥. Its routing table was calculated in the example in Section 11.3. RT4 originates summary-LSAs into both the backbone and Area 1 ✨.
Into the backbone, Router RT4 originates separate LSAs for each of the networks N1-N4 💜. Into Area 1, Router 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 🎀. That condensation was originally done by Router RT11, so credit where it's due 👑.
These LSAs are illustrated graphically in Figures 7 and 8 🦋. Two of the summary-LSAs originated by Router RT4 are shown below. The actual IP addresses for the networks and routers in question were 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 👑
AS-external-LSAs describe routes to destinations outside the Autonomous System 🌍. Most of them describe routes to specific external destinations. In those cases, the LSA's 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, and Appendix E has the details 🧐. A default route for the whole Autonomous System can be described in an AS-external-LSA too, by setting the Link State ID to DefaultDestination (0.0.0.0) 🌸. AS-external-LSAs get originated by AS boundary routers 🚪. An AS boundary router originates a single AS-external-LSA for each external route it has learned, whether that came from another routing protocol (like BGP) or from configuration information ⚙️.
AS-external-LSAs are the only type of LSA that gets flooded throughout the entire Autonomous System 🌊. Every other type of LSA is specific to a single area. AS-external-LSAs are not flooded into or throughout stub areas (see Section 3.6) 🙅♀️. That's what keeps the link state database smaller for routers inside stub areas 💖.
The metric advertised for an external route can be one of two types 📏. Type 1 metrics are comparable to the link state metric. Type 2 metrics are assumed to be larger than the cost of any intra-AS path 💅.
If a router advertises an AS-external-LSA for a destination that then becomes unreachable, the router must then flush that LSA from the routing domain. It does this by setting the LSA's age to MaxAge and reflooding it (see Section 14.1) 🧹.
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 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 that example, the forwarding address field is set to 0.0.0.0. That tells everyone to forward packets for the external destination to the advertising OSPF router (RT7) 📮. But that's not always the move 🙈. Check out the example pictured in Figure 16 👀. There are three OSPF routers (RTA, RTB and RTC) connected to a common network. Only one of them, RTA, is exchanging BGP information with the non-OSPF router RTX 🤖. So RTA must then originate AS-external-LSAs for the destinations it learned from RTX. By using the AS-external-LSA's forwarding address field, RTA can say that packets for those destinations should be forwarded directly to RTX 🎯. Without this feature, Routers RTB and RTC would take an extra hop to reach those destinations 😩.
When the forwarding address field is non-zero, it should point to a router that belongs to another Autonomous System 🔁.
A forwarding address can also be set for the default route 🛣️. For example, in Figure 16, RTA may want to say that all externally-destined packets should, by default, be forwarded to its BGP peer RTX 🫡. The resulting AS-external-LSA is shown below. Notice that 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 addressNow, in Figure 16, suppose both RTA and RTB exchange BGP information with RTX instead 👯. In that case, RTA and RTB would originate the same set of AS-external-LSAs. If those LSAs specify the same metric, they're functionally equivalent, since they name the same destination and forwarding address (RTX) 🙃. That's a clear duplication of effort 😭. If only one of RTA or RTB originated the set, the routing would stay the same and the link state database would shrink 📉. BUT it has to be unambiguously defined which router originates the LSAs. Otherwise neither might, or the identity of the originator could oscillate 🌀. So here's the rule 📜: 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 with the highest OSPF Router ID is used ✅. The router with the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1 🧹💜.
13. The Flooding Procedure ✨
Okay bestie, flooding is where LSAs actually get passed around 🌊 Link State Update packets do the delivering 🚚. One packet can carry several distinct LSAs, and each one gets pushed one hop further from where it started. Iconic. To make this reliable, each LSA must be acknowledged separately 🫶 Those acks ride in Link State Acknowledgment packets, and a bunch of separate acks can get bundled into one packet. Efficient, no cap.
The whole flooding procedure kicks off once a Link State Update packet has been received 💌 Before it gets handed over, it has already gone through a ton of consistency checks (see Section 8.2). Most importantly, the packet has been tied to a particular neighbor and a particular area. Also, if the neighbor is in a lesser state than Exchange, the packet should be dropped without further processing. Bye bye 👋
Here's a little picture of a forwarding address situation, because it's giving diagram energy 🦋
+
|
+---+.....|.BGP
|RTA|-----|.....+---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+Figure 16: Forwarding address example 🌸
Now the tea. All types of LSAs, except AS-external-LSAs, are tied to a specific area. BUT LSAs don't have an area field 🙈 So the area has to be figured out from the Link State Update packet header instead. Detective vibes 🕵️♀️
For each LSA inside a Link State Update packet, these steps happen, in this order:
(1) 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. Bad checksum? Not today, sis 💀
(2) 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). So anything outside 1 through 5 is a no-go 🙅♀️
(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/throughout stub areas (see Section 3.6). Stub areas are not for these, periodt 💅
(4) 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, 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).
- (b) Purge all outstanding requests for equal or previous instances of the LSA from the sending neighbor's Link State Request list (see Section 10).
- (c) If the sending neighbor is in state Exchange or in state Loading, then install the MaxAge LSA in the link state database. Otherwise, simply discard the LSA. In either case, examine the next LSA (if any) listed in the Link State Update packet. Dramatic exit, but make it make sense 😭
(5) 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 installed less than MinLSArrival seconds 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). Boomerang energy 🪃
- (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 MinLSArrival seconds have elapsed. The LSA installation process is discussed further in Section 13.2. Timestamps, obsessed 🧚
- (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.
- (f) If this new LSA indicates that it was originated by the receiving router itself (i.e., is considered a self-originated LSA), the router must take special action, either updating the LSA or in some cases flushing it from the routing domain. For a description of how self-originated LSAs are detected and subsequently handled, see Section 13.4. Main character energy, the router literally has to deal with its own stuff 👑
(6) Else, if there is an instance of the LSA on the sending neighbor's Link state request list, an error has occurred in the Database Exchange process. In this case, restart the Database Exchange process by generating the neighbor event BadLSReq for the sending neighbor and stop processing the Link State Update packet. Oops, we gotta restart the whole Database Exchange 😬
(7) Else, if the received LSA is the same instance as the database copy (i.e., neither one is more recent) the following two steps should be performed:
- (a) If the LSA is listed in the Link state retransmission list for the receiving adjacency, the router itself is expecting 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 termed an "implied acknowledgment". Its occurrence should be noted for later use by the acknowledgment process (Section 13.5). Ngl, this is so clever 🧠✨
- (b) 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.
(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, simply 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, send the database copy back to the sending neighbor, encapsulated within a Link State Update Packet. The Link State Update Packet should be unicast to the neighbor. In so doing, 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. Sequence number wrap-around is a whole mood 🌈
13.1. Determining which LSA is newer
When a router encounters two instances of an LSA, it must determine which is more recent. This occurred above when comparing a received LSA to its database copy. This comparison must also be done during the Database Exchange procedure which occurs 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 are used to determine which instance is more recent:
- The LSA having 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, then the instance having the larger LS checksum (when considered 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 to be more recent.
- Else, if the LS age fields of the two instances differ by more than MaxAgeDiff, the instance having the smaller (younger) LS age is considered to be more recent.
- Else, the two instances are considered to be identical.
Basically, sequence number first, then checksum, then age. It's a whole ladder 🪜💖
13.2. Installing LSAs in the database
Installing a new LSA in the database, either as the result of flooding or a newly self-originated LSA, may cause the OSPF routing table structure to be recalculated. The contents of the new LSA should be compared to the old instance, if present. If there is no difference, there is no need to recalculate the routing table. When comparing an LSA to its previous instance, the following are all considered to be differences in contents:
- The LSA's Options field has changed.
- One of the LSA instances has LS age set to MaxAge, and the other does not.
- 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 that the shortest path calculation cannot 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] Whole routing table, full reset 🔄
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). Clean up crew, every time 🧹✨
13.3. Next step in the flooding procedure ✨
okay bestie, when a new (and more recent) LSA has been received, it must be flooded out some set of the router's interfaces 🦋. This is the second half of the flooding procedure (the first half is what happened in Section 13 💅), and it's all about picking the outgoing interfaces and adding the LSA to the neighbors' Link state retransmission lists. Maintaining the neighbors' Link state request lists is also part of this step 🫶.
This section is equally applicable to the flooding of an LSA that the router itself has just originated (see Section 12.4) 🎀.
For these LSAs, this section gives you the entire flooding procedure. The processing of Section 13 is not performed 🙈, since the LSA hasn't been received from a neighbor and therefore doesn't need to be acknowledged.
Depending on the LSA's LS type, the LSA can only be flooded out certain interfaces. These are called the eligible interfaces 👑:
AS-external-LSAs (LS Type = 5): AS-external-LSAs are flooded throughout the entire AS, with the exception of stub areas (see Section 3.6) 🌸. The eligible interfaces are all 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 the 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 above eligible interfaces 🌈. This is accomplished by executing 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 is a high probability that the attached neighbors have already received the LSA. However, in these 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 are examined, to determine whether they must receive the new LSA. The following steps are executed for each neighbor:
- (a) If the neighbor is in a lesser state than
Exchange, it does not participate in flooding, and the next neighbor should be examined. - (b) Else, if the adjacency is not yet full (neighbor state is
ExchangeorLoading), examine the Link state request list associated with this adjacency. If there is an instance of the new LSA on the list, it indicates that the neighboring router has an instance of the LSA already. Compare the new LSA to the neighbor's copy:- If the new LSA is less recent, then examine the next neighbor.
- If the two copies are the same instance, then 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 are not positive that 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 ensures that the flooding procedure is reliable; the LSA will be retransmitted at intervals until an acknowledgment is seen from the neighbor.
(2) The router must now 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 is 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 that all the neighbors have received the LSA already. Therefore, 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) If this step is reached, the LSA must be flooded out the interface. Send a Link State Update packet (including the new LSA as contents) out the interface. The LSA's LS age must be incremented by InfTransDelay (which must be > 0) when it is copied into the outgoing Link State Update packet (until the LS age field reaches the maximum value of MaxAge).
On broadcast networks, the Link State Update packets are multicast. The destination IP address specified for the Link State Update Packet depends on the state of the interface. 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 (i.e., those in state Exchange or greater). The destination IP addresses for these packets are the neighbors' IP addresses.
13.4. Receiving self-originated LSAs
It is a common occurrence for a router to receive self-originated LSAs via the flooding procedure. A self-originated LSA is detected when either 1) the LSA's Advertising Router is equal to the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID is equal to one of the router's own IP interface addresses. 🪞
However, if the received self-originated LSA is newer than the last instance that the router actually originated, the router must take special action. ⚠️ The reception of such an LSA indicates that there are LSAs in the routing domain that were originated by the router before the last time it was restarted. 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.
It may be the case the router no longer wishes to originate the received LSA. 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 (this latter case should be rare, and it indicates that the router's Router ID has changed since originating 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 ✨
Okay bestie, every newly received LSA must be acknowledged 💅 Usually that happens by sending Link State Acknowledgment packets. But acks can also happen implicitly by sending Link State Update packets (see step 7a of Section 13) 🦋 so no extra packet is needed, iconic!
Lots of acknowledgments can get bundled into one Link State Acknowledgment packet 📦 That packet goes back out the same interface the LSAs came in on. There are two ways to send it: delayed, on an interval timer, or direct, as a unicast straight to one neighbor. Which one you use depends on the situation around receiving the LSA 🌸
Delayed acks are giving three main vibes 🌈 1) they let you pack multiple acks into one Link State Acknowledgment packet, 2) one packet can ack several neighbors at once (by multicasting), and 3) they randomize when the various routers on a shared network send their Link State Acknowledgment packets 🎀 The fixed gap between a router's delayed transmissions must be short (less than RxmtInterval) or you'll get needless retransmissions, and nobody wants that 🙈
Direct acks go to one particular neighbor when they send you duplicate LSAs 💜 They're unicast, and they go out right away when the duplicate shows up ⚡
Here's the exact procedure, Table 19 🍓 The circumstances for receiving the LSA are in the left column, and the ack action goes in one of the two right columns. The action depends on the state of the interface, and interfaces in state Backup act differently from interfaces in every other state 👑 Delayed acks must reach all adjacent routers linked to the interface. On broadcast networks, that means sending the delayed Link State Acknowledgment packets as multicasts 📣 The destination IP address depends on the interface state: if it's DR or Backup, the destination is AllSPFRouters. In all other states, the destination is AllDRouters. 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 (see
Section 13, step 4).
Table 19: Sending link state acknowledgments.Why are these multicasts? Let's check the example 🧚 Look at the network 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 onto N3, RT1, RT2, and RT3 all receive it 👀 These routers won't flood the LSA back onto net N3, but they still need their link-state databases to stay synced with their adjacent neighbors 🤝 So RT1, RT2, and RT4 are all waiting to see an ack from RT3. And RT4 and RT3 are both waiting to see acks from RT1 and RT2. The way to handle that is to send the acks as multicasts 💖
Backup DRs get slightly different ack logic, and the reason is that they behave differently while LSAs are flooding (see Section 13.3, step 4) 🎀
13.6. Retransmitting LSAs 🔁
LSAs flooded out an adjacency go onto that adjacency's Link state retransmission list ✨ To make flooding reliable, those 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, you'll get needless retransmissions 😩 If it's set too high, flooding speed can suffer when packets get lost 🐢
Several retransmitted LSAs can fit in one Link State Update packet 📦 When LSAs need retransmitting, 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 as unicasts (directly to the neighbor's physical address) 💌 They are never sent as multicasts 🙅♀️ 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 hits the maximum value of MaxAge ⏳
If an adjacent router goes down, retransmissions might keep happening until OSPF's Hello Protocol destroys the adjacency 👋 Once the adjacency is destroyed, the Link state retransmission list gets cleared 🧹
13.7. Receiving link state acknowledgments 📬
Before a received Link State Acknowledgment packet even reaches the flooding procedure, it gets a bunch of consistency checks 🕵️♀️ Most importantly, it's been tied to a particular neighbor. If that neighbor is in a state lower than Exchange, the Link State Acknowledgment packet gets tossed 🗑️
Otherwise, for each acknowledgment in the packet, these steps happen:
- Does the LSA acknowledged have an instance on the Link state retransmission list for the neighbor? If not, examine the next acknowledgment. Otherwise:
- If the acknowledgment is for the same instance that is contained on the list, remove the item from the list and examine the next acknowledgment. Otherwise:
- Log the questionable acknowledgment, and examine the next one.
14. Aging The Link State Database 🕰️
Every LSA has an LS age field, measured in seconds ⏱️ An LSA's LS age field goes up while the LSA sits in a router's database. And when it's copied into a Link State Update Packet for flooding out a particular interface, its LS age goes up by InfTransDelay too 📈
An LSA's LS age never goes past MaxAge 🛑 LSAs with age MaxAge don't get used in the routing table calculation 🙅♀️ As a router ages its link state database, an LSA's LS age might reach MaxAge.[21] At that point, the router must try to flush the LSA from the routing domain 🧹 It does this by reflooding the MaxAge LSA just like it would a newly originated LSA (see Section 13.3) 🔥
When a newly forming adjacency builds its Database summary list, any MaxAge LSAs in the link state database get added to the neighbor's Link state retransmission list instead of its Database summary list 💅 See Section 10.3 for more details.
A MaxAge 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 list and b) none of the router's neighbors are in states Exchange or Loading ✨
When the router is aging its link state database and an LSA's LS age hits a multiple of CheckAge, its LS checksum should be verified 🔍 If the LS checksum is wrong, a program or memory error has been detected, and at the very least the router itself should be restarted 😱
Yikes, a bad checksum is a big deal. Restart the router, bestie 🚨
14.1. Premature aging of LSAs 👋
An LSA can get flushed from the routing domain by setting its LS age to MaxAge and reflooding it 🌊 This follows the same course as flushing an LSA whose LS age naturally reached MaxAge (see Section 14). Specifically, the MaxAge LSA is removed from the router's link state database as soon as a) it's no longer on any neighbor Link state retransmission list and b) none of the router's neighbors are in states Exchange or Loading 💫 We call setting an LSA's LS age to MaxAge "premature aging" 🦋
Premature aging is used when a self-originated LSA's sequence number field is about 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 info 📖
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 be used when unexpectedly receiving 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) the LSA's Advertising Router equals the router's own Router ID or 2) the LSA is a network-LSA and its Link State ID equals one of the router's own IP interface addresses 🫶
15. Virtual Links ✨
okay so the single backbone area (0.0.0.0, the Area ID) can NEVER get disconnected 😭 bc then some areas of the whole Autonomous System would become unreachable and that's a total disaster 💀. to keep the backbone connected, you can set up virtual links through non-backbone areas 🦋. they basically stitch together backbone pieces that are physically separated, and the two endpoints are both area border routers. the virtual link has to be configured on both routers. each router needs to know two things: the other virtual endpoint (the other area border router), and the non-backbone area the two routers share, which is called the Transit area 🧚. and virtual links can't be configured through stub areas (see Section 3.6), so don't even try 🙅♀️
the virtual link gets treated as if it were an unnumbered point-to-point network that belongs to the backbone and connects the two area border routers 🎀. the router tries to bring up an adjacency over it. once that adjacency is up, the virtual link shows up in the backbone router-LSAs, and OSPF packets for the backbone area flow over the adjacency 💜. this kind of adjacency is what this document calls a "virtual adjacency" ✨
in each endpoint router, the cost and viability of the virtual link come from looking at the routing table entry for the other endpoint router 👀. (that entry's associated area has to be the configured Transit area.) this is called the virtual link's corresponding routing table entry 🌸. the InterfaceUp event fires for a virtual link when its corresponding routing table entry becomes reachable, and the InterfaceDown event fires when that entry becomes unreachable 🔥. so basically, the virtual link is only viable if there's an intra-area path between the two endpoints, going through the Transit area 💖. also, a virtual link whose underlying path has a cost greater than 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 at all 🙈
here's the rest of the virtual link tea:
- AS-external-LSAs are NEVER flooded over virtual adjacencies 💀. that would just be duplicated work, since the same AS-external-LSAs are already flooded all over the virtual link's Transit area. for the same reason, AS-external-LSAs don't get 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 IP interface address for the virtual interface and the virtual neighbor's IP address are also figured out through the routing table build process, the same way the cost and viability are 🧠. they're used when sending OSPF protocol packets over the virtual link 📦. heads up though: if one (or both) of the endpoints connects to the Transit area through an unnumbered point-to-point link, it might be impossible to calculate either the virtual interface's IP address or the virtual neighbor's IP address, and then the virtual link fails 😭
- in each endpoint's backbone router-LSA, the virtual link is represented as a Type 4 link. the Link ID is set to the virtual neighbor's OSPF Router ID, and the Link Data is set to the virtual interface's IP address 🌈. see Section 12.4.1 for more info ✨
- a non-backbone area can carry transit data traffic (in other words, it counts as 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 for that. a transit area needs special treatment when backbone networks get summarized into it (see Section 12.4.3), and also 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. this can be hard to estimate for a virtual link, so it's better to err on the side of making it too large 🍓
16. Calculation of the routing table 🧮
this section breaks down the OSPF routing table calculation 💅. the router takes its attached areas' link state databases as input and runs the following algorithm, building its routing table step by step 🪜. at each step, the router has to access individual pieces of the link state databases (for example, a router-LSA originated by a certain router) 👀. that access is done with the lookup function discussed in Section 12.2. heads up: the lookup process might return an LSA whose LS age is equal to MaxAge 💀. that LSA should NOT be used in the routing table calculation, and it gets treated just like the lookup process failed 🙈
the OSPF routing table's organization is explained in Section 11, and there are two examples of the routing table build process in Sections 11.2 and 11.3 🦋. this process can be broken into these steps:
(1) the present routing table gets invalidated 🗑️. the routing table is built again from scratch, but the old one is saved so you can figure out which routing table entries changed ✨
(2) the intra-area routes are calculated by building the shortest-path tree for each attached area 🌳. specifically, all routing table entries whose Destination Type is "area border router" get calculated in this step 💜. this step happens in two parts. first, the tree is built using only the 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 also gets calculated so it's ready for Step 4 🎀
(3) the inter-area routes are calculated by looking at summary-LSAs 👀. if the router is attached to multiple areas (in other words, it's an area border router), only backbone summary-LSAs get examined 🌸
(4) in area border routers connecting to one or more transit areas (that is, non-backbone areas whose TransitCapability is found to be TRUE) 🚦, the transit areas' summary-LSAs get examined to see if there are better paths through the transit areas than the ones found in Steps 2-3 above 🔍
(5) routes to external destinations get calculated by looking at AS-external-LSAs 🌍. the locations of the AS boundary routers (the ones that originate the AS-external-LSAs) were already figured out in steps 2-4 💖
Steps 2-5 get explained in more detail below 🫶
changes made to routing table entries from these calculations can make the OSPF protocol take further actions 🔥. for example, a change to an intra-area route 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 🌳
this calculation gives you the set of intra-area routes associated with an area (called Area A from here on) ✨. a router calculates the shortest-path tree using itself as the root.[22] the shortest path tree gets formed in two stages 🪄. in the first stage, only the links between routers and transit networks are considered, and a tree gets built from this subset of the link state database using the Dijkstra algorithm 🧠. in the second stage, leaves get added to the tree by looking at the links to stub networks 🍃
the procedure is explained using the graph terminology from Section 2 📐. Area A's link state database is represented as a directed graph 🕸️. the graph's vertices are routers, transit networks, and stub networks. the first stage only deals with the transit vertices (routers and transit networks) and their connecting links 🫧. throughout the shortest path calculation, each transit vertex also has the following data associated with it:
Vertex (node) ID 🆔 A 32-bit number that uniquely identifies the vertex. for router vertices, this is the router's OSPF Router ID. for network vertices, this is the IP address of the network's Designated Router.
An LSA 📜 each transit vertex has an associated LSA. for router vertices, that's a router-LSA. for transit networks, it's a network-LSA (which is actually originated by the network's Designated Router). either way, the LSA's Link State ID is always equal to the Vertex ID above 💅.
List of next hops 🦋 the list of next hops for the current set of shortest paths from the root to this vertex. there can be multiple shortest paths thanks to the equal-cost multipath capability 🌈. each next hop tells you 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 there is one) in the path toward the destination 🧭.
Distance from root 📏 the link state cost of the current set of shortest paths from the root to the vertex. the link state cost of a path is the sum of the costs of the path's constituent links (as advertised in router-LSAs and network-LSAs) ➕. one path is "shorter" than another if it has a smaller link state cost 🏃♀️
the first stage of the procedure (the Dijkstra algorithm) can be summed up like this 💫. at each iteration, there's a list of candidate vertices. paths from the root to these vertices have been found, but they're not necessarily the shortest ones yet. however, the path to the candidate vertex closest to the root is guaranteed to be shortest. so that vertex gets added to the shortest-path tree and removed from the candidate list, and its adjacent vertices get examined for possible addition to or modification of the candidate list 🔁. then the algorithm iterates again. it stops when the candidate list is empty 🏁
here are the detailed steps. remember, we're computing the shortest path tree for Area A, so every link state database lookup below is from Area A's database 📚
(1) initialize the algorithm's data structures 🧹. clear the list of candidate vertices. set the shortest-path tree to just the root (which is the router doing the calculation) 🌱. set Area A's TransitCapability to FALSE 🙅♀️
(2) call the vertex just added to the tree vertex V 🎯. examine the LSA associated with vertex V. this is a lookup in Area A's link state database based on the Vertex ID. if this is a router-LSA, and bit V of the router-LSA (see Section A.4.2) is set, set Area A's TransitCapability to TRUE ✅. in any case, each link described by the LSA gives the cost to an adjacent vertex. for each described link (say it joins vertex V to vertex W) 🔗:
(a) if this is a link to a stub network, examine the next link in V's LSA 🙋♀️. links to stub networks get considered in the second stage of the shortest path calculation 🌸
(b) Okay so, if W is not a router, it's a transit vertex (router or transit network) 💖. Look up W's LSA (router-LSA or network-LSA) in Area A's link state database 🔍. If the LSA doesn't exist, or its LS age is equal to MaxAge, or it doesn't have a link back to vertex V, just move on and check the next link in V's LSA.[23]
(c) If vertex W is already on the shortest-path tree, examine the next link in the LSA 🫶.
(d) Now we calculate the link state cost D of the resulting path from the root to vertex W 🧮. D is equal to the sum of the link state cost of the (already calculated) shortest path to vertex V and the advertised cost of the link between vertices V and W. Then we compare D:
- If D is greater than the value that already appears for vertex W on the candidate list, examine the next link. Bye bye 👋
- If D is equal to the value that appears for vertex W on the candidate list, calculate the set of next hops that result from using the advertised link. Input to this calculation is the destination (W), and its parent (V). This calculation is shown in Section 16.1.1. This set of hops should be added to the next hop values that appear for W on the candidate list. ✨
- If D is less than the value that appears for vertex W on the candidate list, or if W does not yet appear on the candidate list, then set the entry for W on the candidate list to indicate a distance of D from the root. Also calculate the list of next hops that result from using the advertised link, setting the next hop values for W accordingly. The next hop calculation is described in Section 16.1.1; it takes as input the destination (W) and its parent (V). 🎀
(3) If at this step the candidate list is empty, the shortest-path tree (of transit vertices) has been completely built and this stage of the procedure terminates. 🏁 Otherwise, choose the vertex belonging to the candidate list that is closest to the root, and add it to the shortest-path tree (removing it from the candidate list in the process). Note that when there is a choice of vertices closest to the root, network vertices must be chosen before router vertices in order to necessarily find all equal-cost paths. This is consistent with the tie-breakers that were introduced in the modified Dijkstra algorithm used by OSPF's Multicast routing extensions (MOSPF). It's giving organized 🌸.
(4) Possibly modify the routing table. For those routing table entries modified, the associated area will be set to Area A, the path type will be set to intra-area, and the cost will be set to the newly discovered shortest path's calculated distance. 💅
If the newly added vertex is an area border router or AS boundary router, a routing table entry is added whose destination type is "router". The Options field found in the associated router-LSA is copied into the routing table entry's Optional capabilities field. Call the newly added vertex Router X. If Router X is the endpoint of one of the calculating router's virtual links, and the virtual link uses Area A as Transit area: the virtual link is declared up, the IP address of the virtual interface is set to the IP address of the outgoing interface calculated above for Router X, and the virtual neighbor's IP address is set to Router X's interface address (contained in Router X's router-LSA) that points back to the root of the shortest-path tree. Equivalently, this is the interface that points back to Router X's parent vertex on the shortest-path tree (similar to the calculation in Section 16.1.1). 🦋
If the newly added vertex is a transit network, the routing table entry for the network is located. The entry's Destination ID is the IP network number, which can be obtained by masking the Vertex ID (Link State ID) with its associated subnet mask (found in the body of the associated network-LSA). If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. 🙈
If there is no routing table entry for the network (the usual case), a routing table entry for the IP network should be added. The routing table entry's Link State Origin should be set to the newly added vertex' LSA. 🍓
(5) Iterate the algorithm by returning to Step 2. 🔁
The stub networks are added to the tree in the procedure's second stage. In this stage, all router vertices are again examined. Those that have been determined to be unreachable in the above first phase are discarded. For each reachable router vertex (call it V), the associated router-LSA is found in the link state database. Each stub network link appearing in the LSA is then examined, and the following steps are executed:
(1) Calculate the distance D of stub network from the root. D is equal to the distance from the root to the router vertex (calculated in stage 1), plus the stub network link's advertised cost. Compare this distance to the current best cost to the stub network. This is done by looking up the stub network's current routing table entry. If the calculated distance D is larger, go on to examine the next stub network link in the LSA. 🙅♀️
(2) If this step is reached, the stub network's routing table entry must be updated. Calculate the set of next hops that would result from using the stub network link. This calculation is shown in Section 16.1.1; input to this calculation is 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, simply add this set of next hops to the routing table entry's list of next hops. In this case, the routing table already has a Link State Origin. If this 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. Overwrite the current routing table entry by setting the routing table entry's cost to D, and by setting the entry's list of next hops to the newly calculated set. Set the routing table 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/modified in the second stage, the associated area will be set to Area A and the path type will be set to intra-area. When the list of reachable router-LSAs is exhausted, the second stage is completed. At this time, all intra-area routes associated with Area A have been determined. 🥳
The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1]. 🧠
16.1.1. The next hop calculation 🧚
This section explains how to calculate the current set of next hops to use for a destination. Each next hop consists of the outgoing interface to use in forwarding packets to the destination together with the IP address of the next hop router (if any). The next hop calculation is invoked each time a shorter path to the destination is discovered. This can happen in either stage of the shortest-path tree calculation (see Section 16.1). In stage 1 of the shortest-path tree calculation a shorter path is found as the destination is added to the candidate list, or when the destination's entry on the candidate list is 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 to use for the destination may be recalculated several times during the shortest-path tree calculation, as shorter and shorter paths are discovered. In the end, the destination's routing table entry will always reflect the next hops resulting from the absolute shortest path(s). ✨
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 (i.e., always a router or a transit network).
If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply 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). This means that the destination is either a directly connected network or directly connected router. The outgoing interface in this case is simply the OSPF interface connecting to the destination network/router. If the destination is a router which connects to the calculating router via a Point-to-MultiPoint network, the destination's next hop IP address(es) can be determined by examining the destination's router-LSA: each link pointing back to the calculating router and having a Link Data field belonging to the Point-to-MultiPoint network provides an IP address of the next hop router. If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required. If the destination is a router connected to the calculating router via a virtual link, the setting of 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 provides the IP address of a next hop router. The outgoing interface to use can then be derived from the next hop IP address (or it can be inherited from the parent network). 💜
16.2. Calculating the inter-area routes 💖
okay so inter-area routes get calculated by looking at summary-LSAs 🫶 If the router is attached to multiple areas, it only checks the backbone's summary-LSAs. Routers attached to a single area check that area's summary-LSAs instead. Either way, all the summary-LSAs we look at come from one area's link state database (let's call it Area A) ✨
Summary-LSAs get originated by the area border routers. We check each summary-LSA in Area A one at a time 💅 Remember, the destination in a summary-LSA is either a network (Type 3 summary-LSAs) or an AS boundary router (Type 4 summary-LSAs). For each summary-LSA:
- If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA. 🙈
- If the LSA was originated by the calculating router itself, examine the next LSA. 💀
- If it is 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 the particular area address range is active, then the summary-LSA should be ignored. "Active" means that there are one or more reachable (by intra-area paths) networks contained in the area range. 🌸
- Else, 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 the area border originating the LSA BR. Look up the routing table entry for BR having Area A as its associated area. If no such entry exists for router BR (i.e., BR is unreachable in Area A), do nothing with this LSA and consider the next in the list. Else, 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. 🧚
- 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. 👑
- Else, if the paths present in the table are intra-area paths, do nothing with the LSA (intra-area paths are always preferred). 💜
- Else, the paths present in the routing table are also inter-area paths. Install the new path through BR if it is cheaper, overriding the paths in the routing table. Otherwise, if the new path is the same cost, add it to the list of paths that appear in the routing table entry. 🦋
16.3. Examining transit areas' summary-LSAs 🌈
okay this step is only performed by area border routers attached to one or more non-backbone areas that are capable of carrying transit traffic (i.e., "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 whole point of this calculation is to check the transit areas and see whether they offer any better (shorter) paths than the ones we already worked out in Sections 16.1 and 16.2. Any paths that are better than or equal to what we've already found get installed in the routing table 🔥
Here's how it goes. 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.
- 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. 🍓
- If the summary-LSA was originated by the calculating router itself, examine the next LSA. 🎀
- 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. 🌸
- Look up the routing table entry for the advertising router BR associated with the 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. 🧮
- If this cost is less than the cost occurring in N's routing table entry, overwrite N's list of next hops with those used for BR, and set N's routing table cost to IAC. Else, if IAC is the same as N's current cost, add BR's list of next hops to N's list of next hops. In any case, the area associated with N's routing table entry must remain the backbone area, and the path type (either intra-area or inter-area) must also remain the same. 💖
. Area 1 (transit) . +
. . |
. +---+1 1+---+100 |
. |RT2|----------|RT4|=========|
. 1/+---+********* +---+ |
. /******* . |
. 1/*Virtual . |
1+---+/* Link . Net|work
=======|RT1|* . | N1
+---+\ . |
. \ . |
. \ . |
. 1\+---+1 1+---+20 |
. |RT3|----------|RT5|=========|
. +---+ +---+ |
. . |
........................ +Figure 17: Routing through transit areas 🦋
It's really important to know that this calculation never makes unreachable destinations reachable 🙅♀️ It just potentially finds better paths to destinations that were already reachable. Any better cost it finds gets installed into the routing table entry, and from there it may be readvertised in summary-LSAs to other areas ✨
Let's walk through an example using the Autonomous System pictured in Figure 17. There's a single non-backbone area (Area 1) that physically splits the backbone into two separate pieces 😭 To keep the backbone connected, a virtual link has been configured between routers RT1 and RT4. On the right side of the figure, Network N1 belongs to the backbone. The dotted lines show that there's a much shorter intra-area backbone path between router RT5 and Network N1 (cost 20) than there is between Router RT4 and Network N1 (cost 100). Both Router RT4 and Router RT5 will inject summary-LSAs for Network N1 into Area 1. 🌈
After the shortest-path tree has been calculated for the backbone in Section 16.1, Router RT1 (left end of the virtual link) will have calculated a path through Router RT4 for all data traffic destined for Network N1. However, since Router RT5 is so much closer to Network N1, all routers internal to Area 1 (e.g., Routers RT2 and RT3) will forward their Network N1 traffic towards Router RT5, instead of RT4. And indeed, after examining Area 1's summary-LSAs by the above calculation, Router RT1 will also forward Network N1 traffic towards RT5. Note that in this example the virtual link enables transit data traffic to be forwarded through Area 1, but the actual path the transit data traffic takes does not follow the virtual link. In other words, virtual links allow transit traffic to be forwarded through an area, but do not dictate the precise path that the traffic will take. 💅✨
16.4. Calculating AS external routes ✨
okay bestie, AS external routes get figured out by digging through the AS-external-LSAs 🔍. we go through each one in turn 💅. most of them describe routes to specific IP destinations, but an AS-external-LSA can also describe a default route for the whole Autonomous System (Destination ID = DefaultDestination, network/subnet mask = 0x00000000) 🌈. here's the drill for each AS-external-LSA:
(1) if the cost in the LSA is LSInfinity, or the LSA's LS age is equal to MaxAge, then skip to the next LSA 🙈.
(2) if the LSA was originated by the router doing the calculating, skip to the next LSA. no self-drama here 💀.
(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 the router ASBR (aka ASBR is unreachable), do nothing with this LSA and consider 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. that's 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. out of 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 (the prune step is giving main character 🎀). either way, among the remaining entries, pick the one with the least cost. when there's a tie for 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 specified by the preferred routing table entry for the ASBR/forwarding address, and Y the cost specified 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 no entry exists for N, install the AS external path to N, with next hop equal to the list of next hops to the forwarding address, and advertising router equal to ASBR. if the external metric type is 1, the path-type is set to type 1 external and the cost is equal to X+Y. if the external metric type is 2, the path-type is set to type 2 external, the link state component of the route's cost is X, and the type 2 cost is Y.
(6) compare the AS external path described by the LSA with the existing paths in N's routing table entry 🪞, as follows. 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's added to N's routing table entry'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
RFC1583Compatibilityis set to "disabled", select 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, select the preferred path based on a least cost comparison. type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the forwarding addresses.
16.4.1. External path preferences
when multiple intra-AS paths are available to ASBRs/forwarding addresses, these rules tell you which paths are preferred 🗺️. they apply when the same ASBR is reachable through multiple areas, or when you're deciding which of several AS-external-LSAs should be preferred. in the first case, the paths all terminate at the same ASBR. in the second, the paths terminate at separate ASBRs/forwarding addresses. either way, each path is represented by a separate routing table entry, as defined in Section 11.
this section only applies when RFC1583Compatibility is set to "disabled" ⚠️ so don't skip it, bestie.
the path preference rules, from highest to lowest preference, are below. note that because of these rules there may still be multiple paths at the highest preference. in that case, the path to use must be determined based on cost, as described in Section 16.4.
- Intra-area paths using non-backbone areas are always the most preferred 🌸.
- Otherwise, intra-area backbone paths are preferred.
- Inter-area paths are the least preferred.
16.5. Incremental updates -- summary-LSAs
when a new summary-LSA comes in, you don't have to recalculate the entire routing table 🙌. call the destination described by the summary-LSA N (N's address is obtained by 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:
Case 1: Area A is the backbone and/or the router is not an area border router. 👑 In this case, the following calculations must be performed. First, if there is presently an inter-area route to destination N, N's routing table entry is invalidated, saving the entry's values for later comparisons. then the calculation in Section 16.2 is run again for the single destination N. in this calculation, all of Area A's summary-LSAs that describe a route to N are examined. in addition, if the router is an area border router attached to one or more transit areas, the calculation in Section 16.3 must be run again for the single destination. if the results of these calculations have changed the cost/path to an AS boundary router (as would be the case for a Type 4 summary-LSA) or to any forwarding addresses, 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.
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 presently contains one or more inter-area paths that utilize the transit area Area A, these paths should be removed. if this removes all paths 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 the results of this calculation have caused the cost to N to increase, the complete routing table calculation must be rerun, starting with the Dijkstra algorithm specified in Section 16.1. otherwise, if the cost/path to an AS boundary router (as would be the case for 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 is received, you don't need to recalculate the entire routing table 🦋. call the destination described by the AS-external-LSA N. N's address is obtained by 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 is performed, 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 is not simply a change of 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 age to MaxAge and 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 will cause a virtual adjacency to begin to form (see Section 10.3). at this time, the virtual link's IP interface address and the virtual neighbor's Neighbor IP address are also calculated.
if the entry indicates that the area border router is no longer reachable, 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 🌈.
16.8. Equal-cost multipath ✨
OSPF keeps track of multiple equal-cost routes to every destination 🛣️✨ You can see this in the steps we used above to calculate the routing table, and in how the routing table structure is defined 💅
Each of those routes has the same type (intra-area, inter-area, type 1 external, or type 2 external) 🎀 and the same cost 💖 and the same associated area 🌸 The difference is that every route has its own next hop and its own Advertising router 🦋
Okay, but here's the lowkey chill part 🫶 A router running OSPF has no requirement to track every possible equal-cost route to a destination 🙈 An implementation can keep only a fixed number of routes to any one destination, and that doesn't change any of the algorithms in this spec 💜
Footnotes 📝
[1] The graph's vertices stand for routers, transit networks, or stub networks 🕸️ Routers can belong to more than one area, so it's 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 🤔 When that happens, an IP address has to be assigned to the router 🏷️ That address then gets advertised in the router's router-LSA as a host route ✨
[3] Heads up: in these cases, the non-virtual interface and the virtual interface would both 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 no matter what state the interface is in 💀
[5] Let's think about what happens when the Designated Router for a network crashes 😭 Call the Designated Router for the network RT1, and the Backup Designated Router RT2 🎀 If Router RT1 crashes (or maybe its interface to the network dies), the other routers on the network will notice RT1 is gone within RouterDeadInterval seconds 👀 They won't all notice at the exact same moment 🕰️ The routers that notice RT1's absence before RT2 does will, for a little while, pick RT2 to be both Designated Router and Backup Designated Router 🤝 Once RT2 realizes RT1 is gone, it moves itself up to Designated Router 🦸♀️ Then the remaining router with the highest Router Priority gets picked as Backup Designated Router 👑
[6] On point-to-point networks, the lower-level protocols tell you whether the neighbor is up and running 📡 Existence of the neighbor on virtual links is shown by the routing table calculation 🧮 But in both of these cases, the Hello Protocol is still used 💖 That makes sure communication between the neighbors goes both ways, and that each neighbor has a working routing protocol layer 🫶
[7] When the identity of the Designated Router is changing, a neighbor in this state might often send the router a Database Description packet 💬 That just means there's some momentary disagreement about who the Designated Router is 🙈
[8] A router can resynchronize any of its fully established adjacencies by setting the adjacency's state back to ExStart 🔄 That makes the other end of the adjacency process a SeqNumberMismatch event, so it also goes back to ExStart state 🎀
[9] The address space of IP networks and the address space of OSPF Router IDs can overlap 🌀 So a network might have an IP address that's identical (when you treat it as a 32-bit number) to some router's Router ID 🤯
[10] "Discard" entries are necessary to make sure route summarization at area boundaries won't cause packet looping 🔁 Not optional, babe 💅
[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 break this assumption 💀 Those subnet mask configurations can't be handled by the OSPF protocol 🙅♀️
[12] MaxAgeDiff is an architectural constant 📐 It shows the maximum dispersion of ages, in seconds, that can happen for a single LSA instance while it's being flooded through 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 🙈 If the two LSAs have the same LS sequence number, there's no way to tell which one is actually newer 🤷♀️ But if the wrong LSA gets accepted as newer, the originating router will just originate another instance 🔁 See Section 13.4 for further details 📖
[14] There's one place where a lookup has to be done based on partial information 👀 That's during the routing table calculation, when a network-LSA has to be found using only 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 perks: a) it doesn't 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 that interface (which is handy for diagnostics), 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, the one protocols like RIP use 🕰️
[17] This clause covers the case where inter-area routes are not summarized to the backbone 🦴 That's because inter-area routes are always associated with the backbone area 🏠
[18] This clause only gets invoked when a non-backbone Area A supports transit data traffic (in other words, has TransitCapability set to TRUE) 🚦 For example, in the area configuration of Figure 6, Area 2 can support transit traffic because of the configured virtual link between Routers RT10 and RT11 🌉 So Router RT11 only needs to originate a single summary-LSA into Area 2 (having the collapsed destination N9-N11,H1) 🎀 That's because all of Router RT11's other eligible routes have next hops inside Area 2 itself 💅 Those only need to be advertised by other area border routers, which in this case are Routers RT10 and RT7 🫶
[19] By keeping more information in the routing table, an implementation can recalculate the shortest path tree for just a single area 🌳 There are actually incremental algorithms that let an implementation recalculate only a portion of a single area's shortest path tree [Ref1] ✨ These algorithms are beyond the scope of this specification 🙈
[20] This is how the Link state request list gets emptied, which eventually makes the neighbor state move to Full 🎉 See Section 10.9 for more details 📖
[21] It should be pretty rare for an LSA's LS age to reach MaxAge this way 🌙 Usually the LSA gets replaced by a more recent instance before it ages out ⏳
[22] Strictly speaking, because of equal-cost multipath, the algorithm doesn't actually create a tree 🌲 We keep using the "tree" terminology anyway, because that's what shows up most in the existing literature 📚
[23] Note that the presence of any link back to V is enough, and it doesn't need to be the matching half of the link under consideration from V to W 🔗 That's enough to make sure that, before data traffic flows between a pair of neighboring routers, their link state databases will be synchronized 🫶
[24] When the forwarding address is non-zero, it should point to a router that belongs to another Autonomous System 🌍 See Section 12.4.4 for more details 📖
References 📚
- [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, USC/Information Sciences Institute, September 1981.
- [Ref6] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, ISO, April 1984.
- [Ref7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, 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, Hughes LAN Systems, Performance Systems International, March 1991.
- [Ref9] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.
- [Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519, BARRNet, cisco, MERIT, OARnet, September 1993.
- [Ref11] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, 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, Proteon, Inc., March 1994.
- [Ref19] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994.
- [Ref20] Ferguson, D., "The OSPF External Attributes LSA", work in progress.
- [Ref21] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995.
- [Ref22] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.
- [Ref23] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.
- [Ref24] Hinden, R., "Internet Routing Protocol Standardization Criteria", BBN, October 1991.
A. OSPF data formats ✨
okay bestie, this appendix is where we get into the actual packet formats 💅 OSPF runs directly over the IP network layer, so before we look at any data formats we need to talk about how OSPF gets encapsulated 🎀
Then we're gonna check out the OSPF Options field, which is how routers flag the capabilities they do or don't support. It shows up in OSPF Hello packets, Database Description packets, and OSPF LSAs 🦋
The packet formats are in Section A.3, and the LSA formats are in Section A.4 🌸
A.1 Encapsulation of OSPF packets
OSPF runs directly on top of the Internet Protocol's network layer 🌐 So OSPF packets get wrapped in nothing but IP and local data-link headers. Simple and iconic 💖
OSPF doesn't have its own way to fragment packets. It relies on IP fragmentation when a packet is bigger than the network MTU 🙈 The packet can be up to 65,535 bytes long, IP header included, if it needs to be. The OSPF packet types that tend to get big (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several smaller protocol packets without losing any functionality 🧩 That's the move. IP fragmentation should be avoided whenever possible ✨
So the rule of thumb here is to keep OSPF packets sent over virtual links to 576 bytes, unless Path MTU Discovery is being performed (see [Ref22]) 🫶
Here are the other key features of OSPF's IP encapsulation:
- 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, because 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 to this destination. Certain OSPF protocol packets are also sent here during the flooding procedure 🌊
- AllDRouters. This multicast address has been assigned the value 224.0.0.6 💜 Both the Designated Router and the Backup Designated Router must be prepared to receive packets destined for this address. Certain OSPF protocol packets are sent here during the flooding procedure ⭐
- OSPF is IP protocol number 89 🔢 This number was registered with the Network Information Center. IP protocol number assignments are documented in [Ref11] 📚
- All OSPF routing protocol packets are sent using the normal service TOS value of binary 0000, which is defined in [Ref12] 🍓
- Routing protocol packets are sent with IP precedence set to Internetwork Control 👑 OSPF protocol packets should be given precedence over regular IP data traffic, both when they're sent and when they're received. Setting the IP precedence field in the IP header to Internetwork Control [Ref5] may help make this happen 🎀
A.2 The Options field
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 (or don't support) optional capabilities, and how they tell other OSPF routers what their capability level is. That's the magic that lets routers with different capabilities hang out in the same OSPF routing domain 🧚
In Hello packets, the Options field lets a router reject a neighbor because of a capability mismatch 🙅♀️ When capabilities are exchanged in Database Description packets, a router can choose not to forward certain LSAs to a neighbor because that neighbor has reduced functionality 🫣 And when capabilities are listed in LSAs, routers can route traffic around the reduced-functionality routers by leaving them out of parts of the routing table calculation 🛣️ Lowkey genius.
Five bits of the OSPF Options field have been assigned 🔥 Only one of them, the E-bit, is fully described by this memo, but I'll give you a quick rundown of each one below 💖 Routers should reset (i.e. clear) unrecognized bits in the Options field when they send Hello packets or Database Description packets and when they originate LSAs. On the flip side, when routers run into unrecognized Option bits in received Hello packets, Database Description packets, or LSAs, they should ignore that capability and process the packet or 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 how Type-7 LSAs are handled, 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 how the router handles demand circuits, as specified in [Ref21] 🍓
A.3 OSPF Packet Formats
There are five distinct OSPF packet types 🎀 Every single one of them starts with a standard 24 byte header. We'll go through that header first, and then each packet type gets its own section after it. In those sections, you'll see how each packet is divided into fields, followed by the field definitions 📦
All OSPF packet types except the OSPF Hello packets deal with lists of LSAs 🫶 For example, Link State Update packets are what handle flooding LSAs throughout the OSPF routing domain. Because of that, you can't parse OSPF protocol packets unless you also understand the format of LSAs 🤯 The LSA format is covered in Section A.4, so go check it out 💅
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 has all the info needed to decide whether a packet should be accepted for further processing. That decision is described in Section 8.2 of the specification 🔍
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Version #. This is the OSPF version number. This specification documents version 2 of the protocol 🔢
Type. This is the OSPF packet type. The types are listed below, and you can find the details in Sections A.3.2 through A.3.6 🗂️
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State AcknowledgmentPacket length. This is the length of the OSPF protocol packet in bytes. The length includes the standard OSPF header 📏
Router ID. This is the Router ID of the packet's source 🆔
Area ID. This is a 32 bit number that identifies the area the packet belongs to. Every OSPF packet is associated with a single area. Most travel a single hop only. Packets traveling over a virtual link are labelled with the backbone Area ID of 0.0.0.0 🗺️
Checksum. This is the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but leaving out the 64-bit authentication field 🧮 It's calculated as the 16-bit one's complement of the one's complement sum of all the 16-bit words in the packet, excluding the authentication field. If the packet's length isn't an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. The checksum is considered part of the packet authentication procedure, and for some authentication types the checksum calculation is omitted 🔐
AuType. This identifies the authentication procedure to be used for the packet. Authentication is discussed in Appendix D of the specification. Check Appendix D for a list of the currently defined authentication types 🛡️
Authentication. This is a 64-bit field for use by the authentication scheme. See Appendix D for details 🔑
A.3.2 The Hello packet ✨
okay so Hello packets are OSPF packet type 1 🎀. They get sent periodically on all interfaces (including virtual links) to establish and maintain neighbor relationships 💖. On physical networks with multicast or broadcast capability, Hello packets are also multicast, which is how routers dynamically discover their neighbors 🦋
all routers on a common network have to agree on certain parameters (Network mask, HelloInterval and RouterDeadInterval) 💅. These parameters ride along in Hello packets, so any differences can block neighbor relationships from forming 🙈. the detailed receive processing for Hello packets is in Section 10.5, and the sending side is covered in Section 9.5 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network mask 🎀 the network mask linked to this interface. for example, if the interface goes to a class B network whose third byte is used for subnetting, the network mask is 0xffffff00 ✨
Options 💖 the optional capabilities this router supports, as documented in Section A.2 💅
HelloInterval ⏱️ the number of seconds between this router's Hello packets 🌸
Rtr Pri 👑 this router's Router Priority. it's used in (Backup) Designated Router election 🦋. if it's set to 0, the router is ineligible to become (Backup) Designated Router 🙈
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 here by its IP interface address on the network. set to 0.0.0.0 if there is no Designated Router 🫶
Backup Designated Router 🧚 the identity of the Backup Designated Router for this network, from the sending router's point of view. it's identified here by its IP interface address on the network. set to 0.0.0.0 if there is no Backup Designated Router 🫶
Neighbor 💜 the Router IDs of each router whose valid Hello packets have been seen recently on the network. "recently" means in the last RouterDeadInterval seconds 🌈
A.3.3 The Database Description packet
okay bestie, Database Description packets are OSPF packet type 2 🌸. they get exchanged when an adjacency is being initialized 🦋, and they describe the contents of the link-state database 💖. it can take more than one packet to describe the whole database, so there's a poll-response procedure for that 💅. one router is designated the master and the other is the slave 👑. the master sends Database Description packets (polls), and the slave acknowledges them with its own Database Description packets (responses) ✨. the responses get linked back to the polls through the packets' 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 layout of the Database Description packet is super similar to the Link State Request and Link State Acknowledgment packets 👯. the main bit of all three is a list of items, and each item describes a piece of the link-state database 💅. the sending side is documented in Section 10.8, and the reception side is in Section 10.6 🌸
Interface MTU 📏 the size in bytes of the largest IP datagram that can be sent out the associated interface without fragmentation 🦋. the MTUs of common Internet link types can be found in Table 7-1 of [Ref22] ✨. Interface MTU should be set to 0 in Database Description packets sent over virtual links 🙈
Options 💖 the optional capabilities this router supports, as documented in Section A.2 💅
I-bit 👑 the Init bit. when it's set to 1, this packet is the first in the sequence of Database Description Packets 🎀
M-bit 🧚 the More bit. when it's set to 1, it means more Database Description Packets are to follow 🌸
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 (indicated by the Init bit being set) should be unique. then the DD sequence number increments until the complete database description has been sent 🌈
the rest of the packet is a (possibly partial) list of the link-state database's pieces 💖. each LSA in the database is described by its LSA header, which is documented in Section A.4.1 ✨. the header has all the info needed to uniquely identify both the LSA and the LSA's current instance 😭
A.3.4 The Link State Request packet
Link State Request packets are OSPF packet type 3 🦋. after a router swaps Database Description packets with a neighbor, it might notice that parts of its link-state database are out-of-date 🙈. that's where the Link State Request packet comes in, to ask for the pieces of the neighbor's database that are more up-to-date 💅. it may take more than one Link State Request packet to do the job 🌸
a router that sends a Link State Request packet has a precise instance of the database pieces in mind 🎯. each instance is defined by its LS sequence number, LS checksum, and LS age, even though those fields aren't actually specified in the Link State Request Packet itself 🫶. the router may even receive more recent instances in response 👑
the sending side of Link State Request packets is documented in Section 10.9, and the reception side 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 is specified by its LS type, Link State ID, and Advertising Router 🔍. that combo uniquely identifies the LSA, but not its instance 💖. Link State Request packets are understood to be requests for the most recent instance (whatever that might be) ✨
A.3.5 The Link State Update packet 📦✨
Link State Update packets are OSPF packet type 4 🎀. These are the packets that actually handle the flooding of LSAs. Each one carries a collection of LSAs one hop further from their origin, and you can fit several LSAs into a single packet 💅.
Link State Update packets are multicast on those physical networks that support multicast/broadcast. To make flooding reliable, flooded LSAs get acknowledged in Link State Acknowledgment packets 🫶. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more on reliable flooding of LSAs, check out Section 13 🌸.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |# LSAs
The number of LSAs included in this update.
The body of the Link State Update packet is a list of LSAs. Each LSA begins with a common 20 byte header, described in Section A.4.1. Detailed formats of the different types of LSAs are described in Section A.4 🧚.
A.3.6 The Link State Acknowledgment packet 🦋
Link State Acknowledgment packets are OSPF packet type 5 💜. To make flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. This acknowledgment happens through sending and receiving Link State Acknowledgment packets, and multiple LSAs can be acknowledged in a single one 🍓.
Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent either to the multicast address AllSPFRouters, to the multicast address AllDRouters, or as a unicast. The sending of these packets is documented in Section 13.5, and the reception is documented in Section 13.7 ✨.
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply 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 documented in Section A.4.1 💖. It contains all the information required to uniquely identify both the LSA and the LSA's current instance, so it's basically the LSA's ID card 🪪.
A.4 LSA formats 🌸
This memo defines five distinct types of LSAs 👑. Each LSA begins with a standard 20 byte LSA header, which is explained in Section A.4.1. Succeeding sections then diagram the separate LSA types 🎀.
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. On top of that, whenever a router is elected Designated Router, it originates a network-LSA. Other types of LSAs may also be originated (see Section 12.4). All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of LSAs (see Section 13 for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database 🗂️.
From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16 🧠.
A.4.1 The LSA header 🔥
All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router) 🔍. Multiple instances of the LSA may exist in the routing domain at the same time, so it's necessary to figure out which instance is more recent. This is done by examining the LS age, LS sequence number and LS checksum fields, which are also contained in the LSA 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 a separate 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 one. It describes the state and cost of the router's links (aka interfaces) to the area. all of the router's links to the area must be described in a single router-LSA, no splitting it up 🫶 for the deets on building these, see 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 (i.e., interface). each router link is typed (see the below Type field). the Type field tells you the kind of link being described: it may be a link to a transit network, to another router, or to a stub network. the values of all the other fields describing a router link depend on the link's Type. for example, each link has an associated 32-bit Link Data field. for links to stub networks this field specifies the network's IP address mask. for other link types, the Link Data field specifies the router interface's IP address. that's the vibe check for the Type field 🍓
Type a quick description of the router link. one of the following. note that host routes are classified as links to stub networks with network mask of 0xffffffff 🙈
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual linkLink ID identifies the object that this router link connects to. 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 Data specifies 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 latter piece of information 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 TOS-specific link information may be encoded as follows:
TOS IP the 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 🦋
okay, network-LSAs are the Type 2 LSAs 🌸 a network-LSA gets 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. the LSA 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 so summary-LSAs are the Type 3 and 4 LSAs 💅 area border routers are the ones who originate them, and they describe inter-area destinations 🦋 if you want the full breakdown of how they get built, check out Section 12.4.3 ✨
Type 3 summary-LSAs are used when the destination is an IP network 🌸 in that case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). when the destination is an AS boundary router, a Type 4 summary-LSA is used and the Link State ID field is the AS boundary router's OSPF Router ID. (to see why it's necessary to advertise the location of each ASBR, consult Section 16.4 🙈) other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical 💖
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |for stub areas, Type 3 summary-LSAs can also be used to describe a (per-area) default route 🎀 default summary routes are used in stub areas instead of flooding a complete set of external routes, which is so smart ngl. when describing a default summary route, the summary-LSA's Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0 ✨
- Network Mask: for Type 3 summary-LSAs, this indicates the destination network's IP address mask. for example, when advertising the location of a class A network, the value
0xff000000would be used. this field is not meaningful and must be zero for Type 4 summary-LSAs 🍓 - metric: the cost of this route, expressed in the same units as the interface costs in the router-LSAs 💜
additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). for each desired TOS, the TOS-specific information is 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.5 AS-external-LSAs 🔥
AS-external-LSAs are the Type 5 LSAs 💖 these get originated by AS boundary routers, and they describe destinations external to the AS 🦋 for the details on how they're constructed, see Section 12.4.3 ✨
AS-external-LSAs usually describe a particular external destination. for these LSAs the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS-external-LSAs are also used to describe a default route 🌸 default routes are used when no specific route exists to the destination. when describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0 🙈
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, when advertising a class A network, the mask
0xff000000would be used 💅 - bit E: the type of external metric. if bit E is set, the metric specified is a Type 2 external metric, which means the metric is considered larger than any link state path. if bit E is zero, the specified metric is a Type 1 external metric, which means it is expressed in the same units as the link state metric (i.e., the same units as interface cost) ✨
- metric: the cost of this route. the interpretation depends on the external type indication (bit E above) 🦋
- Forwarding address: data traffic for the advertised destination will be forwarded to this address. if the Forwarding address is set to
0.0.0.0, data traffic will be forwarded instead to the LSA's originator (i.e., the responsible AS boundary router) 🫶 - External Route Tag: a 32-bit field attached to each external route. this is not used by the OSPF protocol itself. it may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification 🌸
additional TOS-specific information may also be included, for backward compatibility with previous versions of the OSPF specification ([Ref9]). for each desired TOS, the TOS-specific information is encoded as follows 💜
- TOS: the Type of Service that the following fields concern. the encoding of TOS in OSPF LSAs is described in Section 12.3 🌈
- bit E: for backward-compatibility with [Ref9] 🍓
- TOS metric: TOS-specific metric information 👑
- Forwarding address: for backward-compatibility with [Ref9] 🧚
- External Route Tag: for backward-compatibility with [Ref9] 💖
B. Architectural Constants ✨
okay so a bunch of OSPF protocol parameters have fixed architectural values 🌸 they get referred to in the text by names like LSRefreshTime, and the same naming convention is used for the configurable protocol parameters (those are defined in Appendix C) 🎀 below, you'll find each architectural constant with its value and a short description of what it does 💅
LSRefreshTime: the maximum time between distinct originations of any particular LSA. if the LS age field of one of the router's self-originated LSAs reaches the valueLSRefreshTime, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. the value ofLSRefreshTimeis set to 30 minutes ⏰MinLSInterval: the minimum time between distinct originations of any particular LSA. the value ofMinLSIntervalis set to 5 seconds 🦋MinLSArrival: for any particular LSA, the minimum time that must elapse between reception of new LSA instances during flooding. LSA instances received at higher frequencies are discarded. the value ofMinLSArrivalis set to 1 second 🙈MaxAge: the maximum age that an LSA can attain. when an LSA's LS age field reachesMaxAge, it is reflooded in an attempt to flush the LSA from the routing domain (see Section 14). LSAs of ageMaxAgeare not used in the routing table calculation. the value ofMaxAgeis set to 1 hour 🔥CheckAge: when the age of an LSA in the link state database hits a multiple ofCheckAge, the LSA's checksum is verified. an incorrect checksum at this time indicates a serious error. the value ofCheckAgeis set to 5 minutes 🌈MaxAgeDiff: the maximum time dispersion that can occur as an LSA is flooded throughout the AS. most of this time is accounted for by the LSAs sitting on router output queues (and therefore not aging) during the flooding process. the value ofMaxAgeDiffis set to 15 minutes 🍓LSInfinity: the metric value indicating that the destination described by an LSA is unreachable. used in summary-LSAs and AS-external-LSAs as an alternative to premature aging (see Section 14.1). it is defined to be the 24-bit binary value of all ones:0xffffff👑DefaultDestination: the Destination ID that indicates 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 stub areas' type 3 summary-LSAs. its value is the IP address0.0.0.0. its associated Network Mask is also always0.0.0.0🧚InitialSequenceNumber: the value used for LS Sequence Number when originating the first instance of any LSA. its value is the signed 32-bit integer0x80000001💜MaxSequenceNumber: the maximum value that LS Sequence Number can attain. its value is the signed 32-bit integer0x7fffffff🫶
C. Configurable Constants ✨
okay so OSPF has quite a few configurable parameters 🎀 They're grouped into general buckets (area parameters, interface parameters, and so on), and some of them come with sample values so you have a starting point 💖
some settings have to match across groups of routers. like, all the routers in an area need to agree on that area's parameters, and all the routers on a network need to agree on that network's IP network number and mask 🫶
some parameters can be figured out by router algorithms that live outside this spec, like the address of a host hooked up to the router over a SLIP line. from OSPF's point of view those are still configurable, so it's not a free pass 💅
C.1 Global parameters
in general, OSPF runs a separate copy for each area 🌸 which means most config params are defined per area. the few global ones are below 👑
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). if it doesn't, they'll stick around for up to MaxAge minutes 💀
RFC1583Compatibility this one controls the preference rules used in Section 16.4 when the router is choosing between multiple AS-external-LSAs that advertise the same destination 🧚 When set to "enabled", the preference rules stay the ones from RFC 1583 ([Ref9]). When set to "disabled", the preference 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 (see Section G.7). it's "enabled" by default 🍓
to keep the chance of routing loops low, every OSPF router in a routing domain should have RFC1583Compatibility set the same way. if there are routers around that haven't been updated with the functionality in Section 16.4.1 of this memo, then everyone should be "enabled". otherwise, everyone should be "disabled", and that blocks all the routing loops 🔥
C.2 Area parameters
all the routers in an area have to agree on that area's config 💜 if two routers disagree, adjacencies can't form between them, and the flow of routing protocol and data traffic gets hindered. these are the items you have to configure for an area:
Area ID This is a 32-bit number that identifies the area. The Area ID of 0.0.0.0 is reserved for the backbone 👑 If the area represents a subnetted network, the IP network number of that subnetted network may be used as the Area ID ✨
List of address ranges an OSPF area is defined as a list of address ranges 🌈 Each address range has these 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 are seen as belonging to multiple areas, depending on the area membership of their attached networks.- Status: set to either Advertise or DoNotAdvertise. Routing information gets condensed at area boundaries 💅 Outside the area, at most a single route gets advertised (via a summary-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges let the existence of certain networks get intentionally hidden from other areas, which is lowkey iconic 🙈 Status is set to Advertise by default.
as an example, say an IP subnetted network is going to be its own OSPF area 🎀 The area would be configured as a single address range, where the IP address is the address of the subnetted network and the mask is the natural class A, B, or C address mask. A single route would be advertised outside the area, describing the entire subnetted network 🌸
ExternalRoutingCapability this is about whether AS-external-LSAs get flooded into and throughout the area 🧚 If AS-external-LSAs are excluded from the area, the area is called a "stub". Inside stub areas, routing to external destinations is based only on a default summary route. The backbone cannot be configured as a stub area, and virtual links can't be configured through stub areas either 😭 For more information, see Section 3.6.
StubDefaultCost if the area has been configured as a stub area, and the router itself is an area border router, then StubDefaultCost 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 imply properties of the attached networks 🫶 so they have to 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 the IP protocol address for this interface. It uniquely identifies the router across the entire internet 🌈 An IP address isn't 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 💖 It indicates the portion of the IP interface address that 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 isn't defined. On those networks the link itself isn't assigned an IP network number, so the address on each side of the link is assigned independently, if it's assigned at all 🧚
Area ID the OSPF area that the attached network belongs to 👑
Interface output cost the cost of sending a packet on the interface, expressed in the link state metric 🔥 This is 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 the number of seconds between LSA retransmissions, for adjacencies that belong to this interface 💜 It's also used when retransmitting Database Description and Link State Request Packets. It should be well over the expected round-trip delay between any two routers on the attached network 🌸 Keep this setting conservative, or you'll get needless retransmissions 🙈 Sample value for a local area network: 5 seconds.
InfTransDelay the estimated number of seconds it takes to transmit a Link State Update Packet over this interface ⭐ LSAs in 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 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 takes precedence. If there'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 is only configured for interfaces to broadcast and NBMA networks.
HelloInterval the length of time, in seconds, between the Hello Packets the router sends on the interface 🦋 This 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 topological 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 another router's Hello Packets, this is how many seconds pass before its neighbors declare that router 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 identifies the authentication procedure to be used on the attached network 🧚 This value must be the same for all routers attached to the network. See Appendix D for a discussion of the defined authentication types 🔥
Authentication key this configured data lets the authentication procedure verify OSPF protocol packets received over the interface 💖 For example, if the AuType indicates simple password, the Authentication key would be a clear 64-bit password 🙈 Authentication keys for the other OSPF authentication types are discussed in Appendix D.
C.4 Virtual link parameters
virtual links are used to restore or increase connectivity of the backbone 🌸 They can be configured between any pair of area border routers that have interfaces to a common (non-backbone) area 🫶 The virtual link shows up in the graph for the backbone 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 the parameters a router interface has (see Section C.3) 🦋 Even though it acts like an unnumbered point-to-point link, it does have an associated IP interface address 🌈 That address is used as the IP source in OSPF protocol packets sent along the virtual link, and it's set dynamically during the routing table build process 🧚 Interface output cost is also set dynamically on virtual links, to be the cost of the intra-area path between the two routers 🍓 The parameter RxmtInterval must be configured, and should be well over the expected round-trip delay between the two routers 🔥 This can be hard to estimate for a virtual link, so it's better to err on the side of making it too large 🙈 Router Priority isn't 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 ✨
okay so OSPF treats an NBMA network pretty much like a broadcast network 🦋 Since there can be lots of routers plugged into it, a Designated Router gets picked for the network. That Designated Router then makes a network-LSA listing every router attached to the NBMA network 💅
BUT 😭 NBMA networks don't have broadcast, so sometimes you need to configure stuff for the Designated Router election. These parameters only need to be set on routers that can actually become Designated Router (aka their Router Priority on the network is non-zero), and only if there's no automatic way to discover neighbors 🫶
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, you also have to define whether that router is eligible to become Designated Router. When an interface to an NBMA network comes up, the router sends Hello Packets only to neighbors that are eligible to become Designated Router, until it finds out who the Designated Router is 🌸
PollInterval : If a neighboring router has gone inactive (no Hello Packets seen for RouterDeadInterval seconds), you may still need to keep sending Hello Packets to that dead neighbor 💀 Those get 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, you might need 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 aren't elected on Point-to-MultiPoint networks, so the Designated Router eligibility of configured neighbors is undefined 🙈
Or, if you'd rather not, neighbors on Point-to-MultiPoint networks can be dynamically discovered by lower-level protocols such as Inverse ARP ([Ref14]) 💜
C.7 Host route parameters 🍓
Host routes get advertised in router-LSAs as stub networks with mask 0xffffffff. They show up for router interfaces to point-to-point networks, looped router interfaces, or IP hosts directly connected to the router (for example, over 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. Since the host probably has only one connection to the internet, though, the configured cost is often unimportant, meaning it won't affect routing at all 🥹
Area ID : The OSPF area the host belongs to.
D. Authentication 🔐
All OSPF protocol exchanges are authenticated, no cap 💖 The OSPF packet header (see Section A.3.1) has an authentication type field, plus 64-bits of data for whatever authentication scheme the type field picks 🎀
The authentication type is configurable per interface (or equivalently, per network/subnet). Extra authentication data is also configurable per interface 💅
Authentication types 0, 1 and 2 are defined by this specification. Every other authentication type is reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is in Table 20 below ✨
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 🙈
Using this type means routing exchanges over the network/subnet aren't authenticated at all 💀 The 64-bit authentication field in the OSPF header can hold anything, and it isn't checked on reception. With Null authentication, the whole OSPF packet (except the 64-bit authentication field) still gets checksummed to catch data corruption 🫶
D.2 Simple password authentication 🔑
With this type, a 64-bit field is configured per network. Every packet sent on that network has to carry this value in its OSPF header 64-bit authentication field. It's basically a "clear" 64-bit password 🌸 The whole OSPF packet (except the 64-bit authentication field) is checksummed too, to catch data corruption.
Simple password authentication keeps routers from accidentally joining the routing domain. Each router has to get its attached networks' passwords configured before it can take part in routing 🧚 BUT, and this is a big but, simple password authentication is vulnerable to passive attacks that are super 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 😭🔥
D.3 Cryptographic authentication 🛡️
With this type, a shared secret key is configured on 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 👑 The secret key is never sent over the network in the clear, so you get protection against passive attacks. iconic 🦋
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 💜
A non-decreasing sequence number is also included in each OSPF protocol packet to protect against replay attacks. That's long-term protection, but it's still possible to replay an OSPF packet until the sequence number changes 🥺 To pull this off, each neighbor data structure contains a new field called the "cryptographic sequence number". This field is initialized to zero, and it's also set back to zero whenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number gets set to the received packet's sequence number ✨
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 employedThis specification does NOT provide a rollover procedure for the cryptographic sequence number 😬 When the sequence number a router is sending hits the maximum value, the router should reset the number it's sending back to 0. After that happens, the router's neighbors will reject its OSPF packets for a period of RouterDeadInterval, and then the router will be forced to re-establish all adjacencies over the interface. HOWEVER, many implementations are expected to 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 long ⭐
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 gets redefined as shown in Figure 18. The new field definitions are:
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 isn't actually considered part of the OSPF protocol packet. It isn't included in the OSPF header's packet length, although it is included in the packet's IP header length field 🧚
Each key is identified by the combination of interface and Key ID. An interface may have multiple keys active at any one time, which enables a smooth transition from one key to another 🦋 Each key has four time constants associated with it. These can be expressed in terms of a time-of-day clock, or in terms of a router's local clock (for example, number of seconds since last reboot) ⏰
KeyStartAccept : The time the router will start accepting packets that have been created with the given key.
KeyStartGenerate : The time the router will start using the key for packet generation.
KeyStopGenerate : The time the router will stop using the key for packet generation.
KeyStopAccept : The time the router will stop accepting packets that have been created with the given key.
For 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, to avoid operational issues. If the last key associated with an interface expires, it's unacceptable to revert 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 is called before the packet is sent. The authentication procedure modifies the OSPF packet as follows.
D.4.1 Generating Null authentication ✨
okay so when you're using Null authentication, the packet gets modified like this 💅
- The Autype field in the standard OSPF header is set to
0. - 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 🎀
bestie, Simple password authentication is giving the same vibe, just with a password glow-up 🔐
- The Autype field in the standard OSPF header is set to
1. - 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 🔥
okay this one is the main character 👑 When you're 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), you choose the one with the most recent KeyStartGenerate time. Using that key, you modify the packet like so:
- The Autype field in the standard OSPF header is set to
2. - 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 Len field 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 Len will be
16. - 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 🔍
okay the receiving side has to be just as iconic 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 set to the described network's IP address. However, if 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 having the same address, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see [Ref10]). 🌈
This appendix gives one possible algorithm for setting the host bits in Link State IDs. Choosing such 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 used is that the network's IP address should be used as the Link State ID whenever possible. This maximizes interoperability with OSPF implementations predating RFC 1583. ✨
The algorithm below is stated for AS-external-LSAs. This is only for clarity; the exact same algorithm can be used for summary-LSAs. Suppose that the router wishes to originate an AS-external-LSA for a network having address NA and mask NM1. The following steps are then used to determine the LSA's Link State ID:
- Determine whether the router is already originating an AS-external-LSA with Link State ID equal to
NA(in such an LSA the router itself will be listed as the LSA's Advertising Router). If not, the Link State ID is set equal toNAand the algorithm terminates. Otherwise, - Obtain the network mask from the body of the already existing AS-external-LSA. Call this mask
NM2. There are then two cases:NM1is longer (i.e., more specific) thanNM2. In this case, set the Link State ID in the new LSA to be the network[NA,NM1]with all the host bits set (i.e.,NAor'ed together with all the bits that are not set inNM1, which is network[NA,NM1]'s broadcast address).NM2is longer thanNM1. In this case, change the existing LSA (having Link State ID ofNA) to reference the new network[NA,NM1]by incrementing the sequence number, changing the mask in the body toNM1and 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 are not set inNM2(i.e., network[NA,NM2]'s broadcast address).
The above algorithm assumes that all masks are contiguous. This ensures that when two networks have the same address, one mask is more specific than the other. The algorithm also assumes that no network exists having an address equal to another network's broadcast address. Given these two assumptions, the above algorithm always produces unique Link State IDs. The above algorithm can also be reworded as follows: When originating an AS-external-LSA, try to use the network number as the Link State ID. If that produces a conflict, examine the two networks in conflict. One will be a subset of the other. For the less specific network, use the network number as the Link State ID, and for the more specific use the network's broadcast address instead (i.e., flip all the "host" bits to 1). If the most specific network was originated first, this will cause you to originate two LSAs at once. 🔄
As an example of the algorithm, consider its operation when the following sequence of events occurs in a single router (Router A).
- 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 ✨
okay so bestie, there are at least two ways to support multiple physical interfaces on the same IP subnet 🦋 Both methods will interoperate with implementations of RFC 1583 (and of course this memo) 💖 The two methods are sketched briefly below. We're assuming 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 different vibe entirely 🙈)
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, because on broadcast and NBMA networks, neighbors are identified by their IP address.
Method 1 has the following 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. ✨ Simple, clean, iconic.
Method 2 has the following 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 1583 🎀
this section is where we spill all the tea on how this memo differs from RFC 1583 🫶 The good news is that every single difference is backward-compatible, so implementations of this memo and of RFC 1583 will interoperate. no drama 💜
G.1 Enhancements to OSPF authentication
an extra OSPF authentication type got added: the Cryptographic authentication type 🔐 It's defined so that any arbitrary "Keyed Message Digest" algorithm can be used for packet authentication. The MD5 algorithm is fully specified (see Appendix D), so that one is the main character 👑
A bunch of other changes were also made to OSPF packet authentication, affecting the following Sections:
- The authentication type is now specified per-interface, rather than per-area (Sections 6, 9, C.2 and C.3). 🌸
- The OSPF packet header checksum is now considered part of the authentication procedure. So it has been moved out of the packet send and receive logic (Sections 8.1 and 8.2) and into the description of authentication types (Appendix D). It's giving organization 🧚
- In Appendix D, sections detailing message generation and message verification have been added. ✨
- For the OSPF Cryptographic authentication type, there's now a discussion of key management added to Appendix D. This includes the requirement for simultaneous support of multiple keys, key lifetimes and smooth key transition. obsessed 😭
G.2 Addition of Point-to-MultiPoint interface
this memo adds another way to run OSPF over non-broadcast networks: the Point-to-Multipoint network 🦋 To make that work, the language of RFC 1583 got tweaked a little. References to "multi-access" networks have been deleted. Now "non-broadcast networks" is the term used for networks that can connect many routers but don't natively support broadcast/multicast (like a public Frame relay network) 🌈
Over non-broadcast networks, you've got two options for running OSPF: modelling them as "NBMA networks" or as "Point-to-MultiPoint networks". NBMA networks require full mesh connectivity between routers. If you're using NBMA networks with partial mesh connectivity, you have to configure multiple NBMA networks, as described in [Ref15]. Point-to-Multipoint networks, on the other hand, were designed to work simply and naturally when there's partial mesh connectivity. 💅
The addition of Point-to-MultiPoint networks impacted the text in a lot of places. Here's the quick summary:
- Section 2, which describes the OSPF link-state database, got split into additional subsections. One of them (Section 2.1.1) describes the differing map representations of the two non-broadcast network options. It also contrasts NBMA and Point-to-MultiPoint networks and describes when one is preferable to the other. 🍓
- Compared to NBMA networks, Point-to-MultiPoint networks have these properties:
- Adjacencies are established between all neighboring routers (Sections 4, 7.1, 7.5, 9.5 and 10.4).
- There is no Designated Router or Backup Designated Router for a Point-to-MultiPoint network (Sections 7.3 and 7.4). 🙈
- No network-LSA is originated for Point-to-MultiPoint networks (Sections 12.4.2 and A.4.3).
- Router Priority is not configured for Point-to-MultiPoint interfaces, nor for neighbors on Point-to-MultiPoint networks (Sections C.3 and C.6).
- The Interface FSM for a Point-to-MultiPoint interface is identical to the one used for point-to-point interfaces. Two states are possible: "Down" and "Point-to-Point" (Section 9.3). so simple, I'm obsessed 🫶
- When originating a router-LSA, a Point-to-MultiPoint interface is reported as a collection of "point-to-point links" to all of the interface's adjacent neighbors. It also comes with a single stub link advertising the interface's IP address with a cost of 0 (Section 12.4.1.4). ✨
- When flooding out a non-broadcast interface (whether it's in NBMA or Point-to-MultiPoint mode), the Link State Update or Link State Acknowledgment packet must be replicated so it gets sent to each of the interface's neighbors (see Sections 13.3 and 13.5). This one is a must-do, bestie 🔥
G.3 Support for overlapping area ranges
RFC 1583 requires that all networks falling into a given area range actually belong to a single area. This memo relaxes that restriction 🌸 Here's a good example of why that's useful. Suppose [10.0.0.0, 255.0.0.0] is carved up into subnets. Most of those subnets are assigned to a single OSPF area (call it Area X), and a few are assigned to other areas.
To get this setup working with RFC 1583, you can't summarize the Area X subnets with the single range [10.0.0.0, 255.0.0.0]. If you did, the subnets of 10.0.0.0 that belong to other areas would become unreachable 😭 But with this memo, you can summarize the subnets in Area X, as long as the subnets belonging to other areas are not summarized. the way that makes sense 🧚
Implementation details for this change can be found in Sections 11.1 and 16.2.
G.4 A modification to the flooding algorithm
the OSPF flooding algorithm got a glow-up 💖 When a Link State Update Packet arrives containing an LSA instance that's actually less recent than the router's current database copy, the router will now, in most cases, respond by flooding back its database copy. In RFC 1583, the router just threw the received LSA away. Hard pass, now 🙅♀️
The detailed description of the change is in Step 8 of Section 13.
This change improves MaxAge processing, and honestly it was needed 😭 Sometimes MaxAge LSAs hang around in a router's database for ages. This happens 1) when they're stuck in a retransmission queue on a slow link, or 2) when a router isn't properly flushing them from its database because of software bugs. Those lingering MaxAge LSAs can block the flooding of new instances of the LSA. New instances usually start with an LS sequence number equal to InitialSequenceNumber. Routers still holding MaxAge instances treat them as less recent, so under RFC 1583 they were discarded. 💀
With the flooding change above, a router holding a MaxAge instance floods the MaxAge instance back. When that flood reaches the LSA's originator, the originator picks the next highest LS sequence number and reflloods, overwriting the MaxAge instance. Main character energy from the originator, no cap 👑
G.5 Introduction of the MinLSArrival constant
OSPF limits how often new instances of any particular LSA can be accepted during flooding 🫶 This is extra protection, just in case a neighboring router is violating the mandated limit on LSA (re)originations. That limit is one per LSA in any MinLSInterval.
In RFC 1583, the frequency at which new LSA instances were accepted was also set equal to once every MinLSInterval seconds. But in some circumstances, this led to unwanted link state retransmissions, even when the LSA originator was obeying the MinLSInterval limit on originations. The cause was either 1) the choice of clock granularity in some OSPF implementations, or 2) differing clock speeds in neighboring routers. 🙈
To fix this, the frequency at which new LSA instances are accepted during flooding has been increased to once every MinLSArrival seconds, and MinLSArrival is set to 1 🌈 This change is reflected in Steps 5a and 5d of Section 13, and in Appendix B. ✨
G.6 Optionally advertising point-to-point links as subnets
When describing a point-to-point interface in its router-LSA, a router may now advertise a stub link to the point-to-point network's subnet 🦋 This is an alternative to the RFC 1583 behavior, which was to advertise a stub link to the neighbor's IP address. See Sections 12.4.1 and 12.4.1.1 for details. It's your call, bestie 💅
G.7 Advertising same external route from multiple areas
Okay bestie, this one is a fix for routing loops 🌀 that could happen in RFC 1583 when the same external destination gets advertised by AS boundary routers sitting in separate areas. There are two different ways this went wrong 😭
The first one was spotted by Dennis Ferguson 👀. It happens when an aggregated forwarding address is in use. The desirability of that forwarding address can get worse as a packet crosses an area aggregation boundary on its way there. That can change the preference of the AS-external-LSAs, and boom, routing loop 💀
The second one was found by Richard Woundy 🧠. It comes from OSPF only applying its preference for intra-area routes over inter-area routes halfway. Paths to one specific ASBR/forwarding address get picked by intra-area preference first, but when you compare different ASBRs/forwarding addresses, only cost matters and the intra-area preference gets ignored. Richard's example is shown in Figure 19 🦋. Router A3 and router B3 are both originating an AS-external-LSA for 10.0.0.0/8, with the same type 2 metric. Router A1 picks B1 as its next hop toward 10.0.0.0/8 because the route to ASBR B3 through B1->B2->B3 is cheaper. But B1 can't actually use that shorter route, since it prefers its (more expensive) intra-area route to B3 through Area A. So B1 turns around and picks A1 as its next hop to 10.0.0.0/8, and now you have a routing loop 🔁😱
To stop these loops, two changes were made 💖:
- When originating a type 3 summary-LSA for a configured area address range, the cost of the summary-LSA is now set to the maximum cost of the range's component networks. Before, the algorithm used the minimum component cost instead. This change affects Sections 3.5 and 12.4.3, Figures 7 and 8, and Tables 6 and 13.
- The preference rules for choosing among multiple AS-external-LSAs got a glow-up ✨. Before, cost was the only thing that mattered. Now the preference is driven first by the type of path to the ASBR/forwarding address (intra-area or inter-area, and through a non-backbone area or through the backbone), and cost is only used to break ties. This change affects Sections 16.4 and 16.4.1.
Once this change is in, the Figure 19 example works out differently. Router A1 now chooses A3 as its next hop to 10.0.0.0/8, and B1 chooses B3 🎉. The reason is that ASBRs/forwarding addresses are chosen based on intra-area preference first, and then by cost.
10.0.0.0/8
----------
|
+----+
| XX |
+----+
RIP / \ RIP
--------------------- --------------------
! !
! !
+----+ +----+ 1 +----+......+----+....
| A3 |------| A1 |---------------| B1 |------| B3 | .
+----+ 6 +----+ +----+ 8 +----+ .
1| . / .
OSPF backbone | . / .
+----+ 2 / .
| B2 |------- Area A.
+----+................
Figure 19: Example routing loop when the
same external route is advertised from multiple
areasNow here's the tea ☕. This change is not backward compatible 😬. It stops the loops when every router runs the new preference rules, but if some routers use the new rules and others still run RFC 1583, it can actually create routing loops 🙃. Because of that, there's a new configuration parameter called RFC1583Compatibility. The new preference rules only kick in when RFC1583Compatibility is set to "disabled" 🫶. See Appendix C for more details.
G.8 Retransmission of initial Database Description packets
This memo lets you retransmit initial Database Description packets without resetting the state of the adjacency 🌸. Honestly, in some environments retransmitting the initial Database Description packet is just unavoidable 😩. For example, the link delay on a satellite link might be longer than the RxmtInterval you configured for an interface 🛰️. In RFC 1583, that kind of environment means a full adjacency can never form at all, which is so sad 💔.
To fix this, changes were made to how Database Description packets get received, so retransmitted initial ones are treated exactly the same as any other retransmitted Database Description packets ✨. See Section 10.6 for details.
G.9 Detecting interface MTU mismatches
When two neighboring routers have different interface MTUs on their shared network segment, things get messy fast 🙈. Big packets can't make it from one router to the other, which hurts OSPF's flooding algorithm and can create "black holes" 🕳️ where user data traffic just disappears.
This memo fixes the MTU mismatch problem by advertising the interface MTU inside Database Description packets 📦. When a router gets a Database Description packet advertising an MTU bigger than the router can receive, it drops that packet. That stops the adjacency from forming, which tells OSPF flooding and user data traffic to steer clear of that connection between the two routers 🙅♀️. For more information, see Sections 10.6, 10.8, and A.3.3.
G.10 Deleting the TOS routing option
The TOS routing option is gone from OSPF 👋. The Internet standards process ([Ref24]) required this, because there just wasn't enough implementation experience with OSPF's TOS routing 😔. But for backward compatibility, the formats of OSPF's various LSAs stayed the same 🎀. So you can still specify TOS metrics in router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-LSAs (see Sections 12.3, A.4.2, A.4.4, and A.4.5).
If you want to nerd out on OSPF's original TOS routing design, check out [Ref9] 🤓📚.
Security Considerations
Okay, this part is SERIOUS 🚨, so read it carefully bestie 🫶. All OSPF protocol exchanges are authenticated 🔐. OSPF supports multiple types of authentication, and you can configure which type is in use on a per network segment basis. One of them, the Cryptographic authentication option, is believed to be secure against passive attacks and to give significant protection against active attacks 🛡️. When you use the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and the received digest to verify that each OSPF packet is authentic ✅.
The quality of the security from the Cryptographic authentication option depends completely on three things 😤: the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and whether the security mechanism is implemented correctly in all communicating OSPF implementations. It also requires that every party keeps the shared secret key secret 🤫.
None of the OSPF authentication types provide confidentiality 🙅♀️. They also don't protect against traffic analysis. Key management is not addressed by this memo either 💀.
For more information, see Sections 8.1, 8.2, and Appendix D 📖.
Author's Address
John Moy 🦋 Cascade Communications Corp. 5 Carlisle Road Westford, MA 01886
Phone: 508-952-1367 Fax: 508-692-9214 Email: jmoy@casc.com
📦 where this page comes from
- ietf: rfc2178 1997-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms