OSPF Training Course – Module 1

Recently I’ve been working on a Practical OSPF deep dive training course on Youtube. The content of the first module is available for free on Youtube:

For those of you who prefer learning by reading, I thought I also provide the training series in article form.

OSPF is an IGP, Link State, Dynamic Routing Protocol. As a pre-requisite to this article, it would be wise to understand each of those three terms:

• Interior Gateway Protocols (IGP) vs Exterior Gateway Protocols (EGP)
• Link State vs Distance Vector
• Dynamic Routing, Static Routing, and Directly Connected

With that as the starting point, we can begin our deep dive into the Open Shortest Path First (OSPF) protocol.

OSPF Tables & OSPF Packets

To understand OSPF, it’s important to understand the framework OSPF utilizes: OSPF Tables and OSPF Packets.

OSPF makes use of three different tables:

• Neighbor Table
• Topology Table
• Routing Table

OSPF also makes use of five different types of packets:

• Hello Packets
• Database Descriptor (DBD)
• Link State Request (LSR)
• Link State Update (LSU)
• Link State Acknowledgement (LSAck)

Apart from defining the eight terms above, there are two other critical components of OSPF that must be understood in any discussion of OSPF:

• Link State Database (LSDB)
• Link State Advertisement (LSA)

All ten of the concepts above are discussed in the first lesson.

OSPF Tables

An OSPF router holds the information related to OSPF in three distinct tables. Each table serves a particle role in the OSPF process. We’ll use this topology to discuss the OSPF tables:

OSPF Neighbor Table

Each OSPF router will try to find and form a neighbor relationship with other OSPF routers. The information related to each Neighbor is stored in the OSPF Neighbor Table.

In the topology above, R5 would be neighbors with R4, and R5’s Neighbor Table would look like this:

There are a few pieces of information in the neighbor table:

• Neighbor’s Router-ID
• Neighbor’s Interface Priority
• Neighbor’s Adjacency State and DR/BDR status
• Remaining Dead Interval on the neighbor adjacency
• Neighbor’s interface IP Address
• Local Router’s Interface

A lot of the concepts in this table will be expanded on later in this series. For now, the most important piece of the Neighbor Table is the state of the Adjacency.

We can see that R5 considers the adjacency with R4 (Router-ID 4.4.4.4) in the Full state. The Full state is the “happy state”, meaning a completed neighbor adjacency sequence (which will also be expanded on later in this series).

Notice R5 is only neighbors with R4. R5 will end up knowing about all the other Routers in the topology (you’ll see that shortly). But a neighbor adjacency will only exist for any Routers connected via a single L3 hop.

Router 4, however, happens to be connected all the other Routers in the topology, and Router 4’s Neighbor Table will look like this:

OSPF Topology Table

Throughout the course of normal OSPF operation, each OSPF router will learn about the various IP networks in a particular topology. All that information is stored in the OSPF Topology Table.

Every Routing Protocol has some form of a Topology table, which contains everything a Routing Protocol knows.

OSPF calls its topology table a Link State Database (LSDB).  Each entry within the LSDB is called a Link State Advertisement (LSA). Both the LSDB and LSA are very important concepts of the OSPF protocol, and many additional lessons in this series will unpack these ideas further.

The Link State Database can be viewed using the command show ip ospf database, and below is an example of the Link State Database for Router 5:

There is a lot going on with the output above, but rest assured the rest of the course will be spent unpacking and understanding the content of the Link State Database.

For now, just understand the entire table is known as the Link State Database (LSDB), and each line in the output above is a Link State Advertisement (LSA).

The goal of OSPF will be for each Router to share these LSAs with each other, and from that each Router can reconstruct the network topology.

OSPF Routing table

The final table that OSPF uses is the Routing Table.

This table isn’t strictly an OSPF construct, it’s merely the Router’s innate Routing Table (also called the RIB, Routing Information Base). The concept of a Routing Table is explained in our Networking Fundamentals video discussing Everything Routers Do.

Each OSPF Router will run a “shortest path first” calculation on all the IP networks it has acquired in its Link State Database (LSDB) and will then try to install the best routes it knows about into the Router’s Routing Table.

On a Cisco Router, to view the Routing Table you would use the command show ip route. The output will display all the routes a Router knows about, to include any that might have been learned from OSPF.

This is an (abridged) output of Router 5’s Routing Table:

Notice R5 learned of the 10.0.1.0/24 and 10.0.2.0/24 networks via OSPF and learned of the 10.0.3.0/24 network via EIGRP.

OSPF Packets

Every OSPF conversation is composed of five different packets. Each packet serves a specific role in the OSPF process.

Hello Packets

Hello packets are sent to discover other OSPF routers.

They include information about the sending Router. Adjacency OSPF routers will receive each other’s Hello Packets and use the included information to determine whether a neighbor adjacency will form.

The details of Hello Packets will be explored later in this series.

Database Descriptor Packets (DBDs)

DBD packets serve two functions:  The first is the Master and Slave election, and the second is the exchange of LSDB summaries.

As a Router adjacency is forming, the routers will elect one router to be the Master and the other to be the Slave. The purpose of these roles is to govern the reliable exchange of ensuing DBD packets. The reliability mechanism involves a one-by-one packet exchange, always initiated by the Master and responded to by the Slave.

There is no use for the Master/Slave roles outside of this reliable exchange of ensuing DBDs.

The second, and more significant function of the DBD packets is for a Router to send a summary of the entries in their LSDB.

LSDBs can grow to 1000s and 1000s of LSAs, and when two Routers form a new adjacency, it’s very possible that the routers already know some of each other’s LSA (perhaps via a third router they are both already neighbors with).

In those cases, it would be redundant to send the full Link State Database, therefore a summary of the Link State Database is sent instead.

The neighboring Router will then read through the Link State Database Summary and identify the specific LSAs it needs, and then ask for them using the next packet we’re going to discuss:  a Link State Request.

Link State Requests (LSRs)

A Link State Request packet is sent when one Router is requesting specific LSAs from a neighboring Router. A single LSR can contain multiple LSA requests.

Link State Updates (LSUs)

A Link State Update packet contains one or more full Link State Advertisement (LSA).

LSUs are sent in response to LSRs, or when a Router learns of a new Route and needs to update it’s peers.

Link State Acknowledgements (LSAcks)

Finally, to confirm reception of an LSU, a Router will send a Link State Acknowledgement (LSAck).

If a Router has sent an LSU and has not received an LSAck after a certain duration, the Router will resend the LSU.

---

OSPF Areas & OSPF Types of Routers

The concept of OSPF Areas is integral to OSPF.

OSPF allows you to isolate portions of your network into different Areas. LSA propagation is then limited to each specific area.

This spares the Routers on one side of your network from having to recalculate their OSPF topology every time something changes in another, unrelated part of your network.

To discuss Areas, we will use this topology:

In the topology above, imagine that something was to happen to the path between R3 and R5, and R3 now must use the path through R6 to get to R5.  If that occurred, notice the path to R5 for every other router in the topology would remain unchanged – they all must still use R3.

By placing R3, R5, and R6 in Area 88, it prevents the little changes that occur within that area from being propagated to and bothering the other routers in the topology. Limiting the number of recalculations necessary after topology changes.

OSPF Area Design

Every OSPF area is identified by an Area ID, which is a 32-bit value (range: 0 – 4,294,967,295).

OSPF areas create a two-tier hierarchy:

The top of the hierarchy is Area 0, known as the Backbone area.  Every other OSPF area must connect back to Area 0.

The “bottom” of the hierarchy is every other area (1 – 4,294,967,295).  This creates a “hub and spoke” design, where Area 0 is the Hub and every other area acts as a Spoke.

Communication from spoke to spoke must traverse the Backbone area. The purpose of this rule is to prevent Routing Loops. If the area design adheres to strict hub and spoke topology, then there can be no routing loops with spoke to spoke communication.

In our topology above, communication from Area 88 and Area 99 must traverse a router inside Area 0.

OSPF Types of Routers

Each Router within an OSPF domain serves a specific role, based upon where it sits in the Area design.

There are four types of Routers in OSPF:  Internal Routers, Backbone Routers, Area Border Routers (ABRs), and Autonomous System Border Routers (ASBRs).

Internal Router

An Internal Router is a Router with all its interfaces in a single area.

The Internal Routers of the topology above are:  R1, R2, R5, R6.

Backbone Router

A Backbone Router is a Router with at least one interface in Area 0.

The Backbone Routers of the topology above are:  R1, R2, R3, and R4.

Notice that R1 and R2 are both Internal Routers and Backbone Routers – Routers can be multiple types.

Area Border Router (ABR)

An Area Border Router, or ABR, is a Router which sits on the border between two areas.

Officially, the definition of an ABR is a Router with one or more interface in Area 0, and one or more interface in another area.

ABRs are possibly the most important type of Router in OSPF, as they serve a very crucial purpose:  They summarize LSAs from one area and send them into another.

This requires an ABR to maintain a separate LSDB for each area they are connected to.

The ABRs of our topology above are R3 and R4.

Autonomous System Border Router (ASBR)

An Autonomous System Border Router, or ASBR, is a Router which is redistributing routes from a foreign routing protocol into the OSPF domain.

In our topology, R7 is the ASBR because it is redistributing routes from EIGRP into the OSPF topology.

In our illustration, we used EIGRP, but any form of redistribution would cause a Router to become an ASBR. 

• Redistribution from another Routing Protocol (EIGRP, RIP, BGP, etc…)
• Redistribution from one OSPF domain into another
• Redistribution of Static Routes or Directly Connected Routes

Any type of redistribution whatsoever creates an Autonomous System Border Router.

---

OSPF Hello Packets

Every OSPF Router sends OSPF Hello Packets out all it’s OSPF enabled interfaces. These Hello packets are  used to discover other OSPF Routers to share routes with.

Specifically, within the OSPF Hello packets are various pieces of information that are used and compared with other OSPF routers to determine if a full neighbor adjacency will form.

Beyond that, after the neighbor adjacency is formed, the Hello packets serve as an ongoing keep alive used to verify whether a peer is still healthy.

Neighbor Discovery with Hello Packets

When you enable OSPF on a Router Interface, that router starts sending out Hello Packets to a special multicast address:  224.0.0.5.

This multicast address is specially reserved for all OSPF Routers – which means any router which is running OSPF will be listening for packets sent to this address.

The interval for these hello packets depends on the type of connection being used. In OSPF, Ethernet connections are considered “Broadcast” networks and send a Hello every 10 seconds. And Serial connections are considered “Point-to-Point” networks and send a Hello every 30 seconds.

In either case, the Hello Interval can be configured manually.

NOTE:  There are also other network types that exist — and some of them do not support Multicast packets. In such cases, a Neighbor’s IP address must be manually configured, and Hello packets are sent Unicast

The various OSPF network types will be explored in more detail later in this course.

Since all OSPF routers are sending these Hello packets to 224.0.0.5, and all OSPF routers are listening to incoming requests sent to 224.0.0.5, it’s only a matter of time for OSPF peers to receive each other’s Hello packet. This is the mechanism by which OSPF routers discover other Neighbors.

OSPF Immediate Hellos

In the original OSPF RFC (RFC 2328), Hello packets are sent only on a consistent interval.

Which means if two adjacent routers are using 30 second hello packets, it might take up to 60 seconds for both Routers to have sent and received each other’s Hello packets. And another 60 seconds for them to have acknowledged to each other that they see their peers Hello packets.

To alleviate this, an optimization for OSPF was created called Immediate Hellos. This feature reduces the time it takes for two Routers to discover each other by allowing a Router to respond instantly with a Hello packet when it receives a Hello packet from a peer.

This immediate Hello is typically sent Unicast, directly to the neighbor’s interface IP address. And the general effect of this feature is OSPF neighbor adjacencies will form quicker.

OSPF immediate hellos are widely adopted and supported by most vendor’s OSPF implementations.

Information Contained inside Hello Packets

As mentioned above, the three primary purposes of Hello packets are:

• Discover other OSPF Routers
• Determine if a full Neighbor Adjacency will form
• Serve as an ongoing keepalive / health check

With the three primary purposes in mind, we can now explore the various pieces of information included in each Hello Packet.

Router ID

Every Router in OSPF is identified by what’s known as a Router ID.

A common theme in the rest of this series, is the Router ID will simply be the Router Number repeated for all four octets.  Meaning Router 7 (R7) would have a Router ID of 7.7.7.7.

The Router ID is a 32-bit value, which is often represented in dotted decimal notation. Which means even though it might look like an IP address, it isn’t actually an IP address that you can send IP traffic to.

To set the Router ID on a Cisco Router, you would use the router-id command within the OSPF process:

Router(config)# router ospf 110
Router(config-router)# router-id #.#.#.#

If a Router-ID is not explicitly set, OSPF can select a Router-ID automatically.  The order of precedence by which a Router selects it’s Router ID is as follows:

1. Router ID set manually using the router-id command
2. Highest active Loopback IP address
3. Highest active Interface IP address

If there are no active interface IP addresses configured, then OSPF and the Router-ID is the least of your concerns =).

Hello Interval and Dead Interval

The Hello Interval is the period of time between sending Hello Packets.

This is an important value because the Hello packets end up serving as a periodic health check. Therefore, the Hello Interval directly correlates to how quickly a topology will reconverge after a failure event.

The Dead Interval is the period of time a Router will remember information about a neighbor, if it no longer hears from that neighbor.

Typically, the Dead Interval is set to 4x the Hello Timer, but of course can be changed. Four times the hello interval requires that at minimum 3 Hello packets in a row can be missed before a Router considers its peer to be no longer functioning.

Hello and Dead intervals can be set on a per-interface basis:

Router(config)# interface FastEthernet0/1
Router(config-if)# ip ospf hello-interval 10
Router(config-if)# ip ospf dead-interval 40

Active Neighbors

Inside each Hello Packet, a Router will identify the Router-IDs of other Routers seen on the link.

This is crucial, as it provides positive confirmation of two-way reachability on a particular link.

Consider, if I am an OSPF Router, and I receive a Hello Packet from a potential peer. If within that Hello packet I can see my own Router-ID, this tells me the other peer has definitely received my Hello Packets.

This field is the primary field responsible for the 2-WAY neighbor adjacency state (more on that later).

Area ID

As discussed in the prior section, OSPF allows portions of your network to be grouped into various Areas. Each Area is identified by an Area ID – a 32-bit value.

Inside each Hello Packet, the sending router includes the Area ID the sending interface belongs to.

Remember, the Area ID is assigned to an interface, not a Router. Otherwise, the concept of an Area Border Router couldn’t exist.  By definition, an ABR is a Router with some interfaces in one Area, and other interfaces in another Area.

Authentication Data

Commonly when doing Dynamic Routing, you wish to limit the Routers which can form a neighbor adjacency with you to those within your administrative control. Typically, this is done by setting some sort of password on the OSPF process ID, and only forming a Neighbor Adjacency with other Routers which have the same password.

That authentication data is carried in the Authentication Data portion of the Hello Packet.

Network Mask

Each Router includes in the Hello packet, the Subnet Mask of the sending interface. 

This is used to ensure the peers have agreement upon the size of the network they are connected to. If they don’t have agreement here, then they may have trouble aggreging on Network information in the rest of the OSPF domain.

Area Type

There are three types of areas that exist in OSPF: 

• Normal Areas
• Stub Areas
• Not-So-Stubby Areas (NSSA)

All areas, by default are “Normal Areas” unless designated as a Stub Area or NSSA. Stub and NSSA areas are optimizations that exist in OSPF to limit how many LSAs need to exist in each area.

There are also two additional sub-types:  Totally Stub Areas, and Totally Not-So-Stubby Areas.  These are Cisco proprietary concepts that we will discuss later in this series.

There will be a dedicated section discussing Area Types in detail. For now, if you want a quick overview, I’d recommend watching the correlating part of the video on OSPF Hello Packets.

At this point, however, I simply want to identify that Area Types are optimizations in OSPF, and each Router will indicate the Area Type they believe to be in within the Hello Packets.

Designated Router, Backup Designated Router, and Priority

One key feature of any modern Routing Protocol (including OSPF) is called Triggered Updates – which means if a Router learns of a new network, it will instantly share it with its neighbors.

This is a quicker convergence strategy than doing only periodic updates, as network events can be accommodated instantly.

However, this creates an undesirable consequence:  On links where multiple routers are all Neighbors with each other, each Router can resend the same update it just received to it’s neighbors (who have also just received the original update).

OSPF avoids this problem by electing a Designated Router (DR) on each multi-access segment. If a neighbor has an update to send, it only sends it to the DR, and the DR in turn sends it to the remaining routers on the link.

In addition to a Designated Router, a Backup Designated Router (BDR) is also elected. The BDR’s role is to take over as the DR should the original DR fail.

Both the DR and BDR are elected based upon a Priority Number assigned to each OSPF Router interface. The default priority number is 1, and the full range is 0-100.

All three of these pieces of information (DR IP address, BDR IP address, and Priority Number) are included in each Router’s hello packet. There will be a dedicated lesson on the actual OSPF DR/BDR election process.

What must match for a Neighbor Adjacency to form?

As mentioned earlier, the content of the Hello packet will determine if a Neighbor Adjacency will form. Specifically, there are six items which must match:

• Hello Interval
• Dead Interval
• Area ID
• Authentication Data
• Network Mask
• Area Type

---

OSPF Adjacency Process

Two OSPF Peers will go through various adjacency states as they form a Neighbor Adjacency. In this section we’ll be exploring each of these states.

Keep in mind, each of these states are a state of the adjacency with another individual Neighbor (not the State of the Router itself). These states are visible in the show ip ospf neighbor command.

Down State

The DOWN state is the initial state for each Neighbor Adjacency. Although, in some ways, it’s a non state. Let me explain…

The adjacency state is the state of a relationship with a specific neighbor. In the DOWN state, a router hasn’t received anything from a potential neighbor. Which means there isn’t an entry in the Neighbor Table that the Down state can be associated with.

The Down state, in effect, is the state of each neighborship before the neighborship actually exists.

In any case, in the Down state, a Router is sending periodic Hello Packets to the multicast address 224.0.0.5. Essentially searching for a neighbor to create an adjacency with.

Attempt State

The Attempt state only exists on Non-Broadcast Multi-Access (NBMA) links. This type of network does not support Multicast packets, and therefore neighbors can not be automatically discovered. 

Instead, a Neighbor IP address is manually configured on the Router, and Unicast Hello packets are sent directly to the Neighbor. In those cases, since a Neighbor IP address has been manually provided, an entry will exist in the Neighbor Table indicating that neighbor is in the Attempt state.

In the Attempt state, Hello packets are being periodically sent to the Unicast address of the neighbor.

Init State

The Init state reflects that a Hello packet has just been received by a potential Neighbor.

More importantly, the Neighbors field of the received Hello packets is empty. Which means the local Router does not see its own Router-ID in the Neighbor’s Hello packet.

If Immediate Hellos are implemented, this will trigger sending an immediate hello packet, unicast to the Neighbor.

2-WAY State

The 2-WAY state reflects that a Hello packet has just been received, and the Neighbors field includes the local Router’s Router-ID. 

This confirms two-way reachability, as the Neighbor only knows the local Router’s Router-ID, if the neighbor received one of the local Router’s Hello packets.

The graphic below illustrates the DOWN, INIT, and 2-WAY states:

Notice R1 went from DOWN to INIT to 2-WAY, and R2 went from DOWN to 2-WAY. This is typically and is merely an effect of the order in which OSPF was enabled on these Routers.

The period of time before R2 was in the DOWN state reflects OSPF not yet being configured on R2.

ExStart State

In the ExStart state, the Master and Slave election occur.  The Master/Slave roles are the mechanism OSPF uses to govern the reliable exchange of the ensuing DBD messages.

The way it works, is both peers initially send a DBD packet, indicating they are the Master. The Router with the highest numerical Router-ID becomes the Master. The other Router becomes the Slave and sends a DBD confirming the Slave status.

The Master/Slave reliability works by forcing a one by one, packet sending & receiving sequence for DBDs. Every DBD from this point forward will always involve one packet from the Master, followed by one packet from the Slave.

We discussed DBD packets earlier, and we identified that the primary purpose of DBDs is to exchange LSDB Summaries. Occasionally, these summaries may require many packets, and therefore a reliability mechanism is important to avoid unnecessary retransmissions or the missed packets.  OSPF chose to use the Master/Slave process above as it’s DBD reliability mechanism.

After the Slave sends it’s confirmation DBD, it drops into ExChange state. When the Master receives the Slave’s confirmation DBD, the Master drops into ExChange state.

ExChange State

The ExChange state signifies the end of the Master/Slave election in the previous state, and the beginning of the exchanging of the LSDB summaries.

These summaries contain a snapshot of each router’s LSDB, allowing each Router to see which entries they are missing.

Once the complete LSDB summary has been exchanged, both peers will transition into LOADING state and request the specific entries they need.

The graphic below illustrates the ExStart and ExChange state:

Loading State

In the Loading state, both routers know the LSA entries they need from their peer, and begin requesting specific LSAs using the Link State Requests (LSRs), Link State Updates (LSUs), Link State Acknowledgements (LSAcks) described earlier. 

After receiving the requested LSAs from the peer, the Router performs the Shortest Path First calculation (Dijkstra Algorithm) to calculate the best path to get to each Network.

The best paths are then loaded into the Router’s Routing Table. At which point, the neighbor adjacency is complete and both peers have synchronized their LSDB. This then triggers the next and final state in the Neighbor Adjacency process: the Full state.

Full State

The Full State indicates the neighbor adjacency process has completed, and both peers have synchronized Link State Databases.  Both parties know each other’s full LSDB.

If a new piece of routing information is learned by one router, that Router instantly knows whether its peer needs to know the new information and will send it using a LSU (which will be confirmed with an LSAck).

---

OSPF Configuration and Show Commands

Finally, the last lesson of the OSPF series (at this point, at least) involved a live configuration demonstration.

This video effectively proved all the concepts explained in prior lessons by walking through the OSPF configuration of two OSPF routers, and seeing the behavior when adding and removing networks to the OSPF domain.

It would be hard to summarize this lesson in text, so I’ll simply list the commands we explored and the show commands we used to verify OSPF’s operation. 

• Router OSPF & Process ID
• Router ID
• Add Interfaces to OSPF:
  • network command
  • ip ospf command
• Show  Commands
  • show ip protocols
  • show ip ospf interface
  • show ip ospf interface brief
  • show ip ospf neighbor
  • show ip ospf database
  • show ip ospf rib
  • show ip ospf rib detail
  • show ip ospf route
  • show ip ospf route ospf

If you’re learning OSPF, I’d highly recommend giving the video a watch, as it will tie together everything discussed above.

---

Practical OSPF – What’s next?

The lessons above essentially serve as Module 1 of the Practical OSPF series.  Module 2 of the OSPF series will include lessons covering the following topics:

• DR / BDR Election Process
• Cost Calculation & SPF algorithm
• Reference Bandwidth
• LSA Types 1 & 2
• LSA Type 3
• LSA Types 4 & 5

Following those lessons, we’ll do a fun LSA challenge proving you can rebuild an entire topology using only OSPF LSAs. =). 

Have something else OSPF related you want to learn about?  Mention it in the comments below.