Your perception of how a routing protocol should operate may be heavily influenced by the first protocol you support in a production environment. For example I was first exposed to BGP when I settled into my entry level NOC position some years ago. As a result I referred to the communication of prefix and NLRI as “advertisements” regardless of the routing protocol in play, which is incorrect. It is correct when dealing with BGP because routes or prefixes are “advertised” between BGP speakers, so that classification makes sense. When you’re dealing with OSPF that’s not quite an accurate description. If I (Router A) need to reach a prefix connected to Router C, I don’t receive an advertisement for that prefix, I solve the SPT (Shortest Path Tree) to Router C which has the data link to that network. Since the SPT is derived from the Link State Database, it is important that you be able to observe the database on a given router and be able to understand how you are routing to a given prefix based on the contents of the database. I wanted to outline a few noteworthy aspects of the output seen when running the ‘sh ip ospf database’ command, and hopefully this will get you started on a path to understanding the database better. In the output below we’ll first focus on the “Router Link States” section.
R1#sh ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 94 0x80000003 0x001E4A 2
2.2.2.2 2.2.2.2 92 0x80000003 0x001573 4
3.3.3.3 3.3.3.3 90 0x80000003 0x000786 3
5.5.5.5 5.5.5.5 89 0x80000003 0x00B90D 4
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.2.1 1.1.1.1 94 0x80000001 0x005666
The top of the ‘ip ospf database’ output shows the OSPF Router ID and OSPF Process ID you’re working with locally. Next to “Router LInk States” you’ll see the Area listed. This is important because there is a separate database for each Area on the router, and you’ll need to be cognizant of which database you are observing. Each entry in this section represents a Type 1 Router LSA that is advertised by each OSPF router in an area. To the left you will see the “Link ID”, which can be a bit confusing as it has a different meaning depending on the LSA type you’re observing. For the Type 1 router LSA the Link ID represents the Router ID. In my example Router ID 1.1.1.1 = Router 1 in my topology. I would recommend manually setting the Router ID so that you can easily identify the associated router. The “ADV Router” field to the right also displays the Router ID so this should always match the Link ID field. We’ll skip the next three fields and discuss the “Link Count” field to the far right. This is important because it identifies the number of data links participating in the OSPF process on each router. We’ll look and an individual Type 1 LSA next so we can observe the link information a bit closer.
R1#sh ip ospf database router 3.3.3.3
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 0)
LS age: 119
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x786
Length: 60
Number of Links: 3
Link connected to: a Transit Network
(Link ID) Designated Router address: 192.168.2.1
(Link Data) Router Interface address: 192.168.2.2
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 5.5.5.5
(Link Data) Router Interface address: 172.16.3.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.16.3.0
(Link Data) Network Mask: 255.255.255.252
Number of MTID metrics: 0
TOS 0 Metrics: 1
If you noticed in the first output of the database, Link ID 3.3.3.3 listed a Link Count of 3, and you can see above that three links are listed. We’re going to focus on the first line of the link description which has the label “Link connected to:”. This identifies the type of data-link as understood by the OSPF process. The first entry is for a “Transit Network” which correlates to an OSPF network type of Broadcast. You’ll see the Designated Router listed here confirming that there is a DR/BDR election for this type of of network. For each Link identified as a “Transit Network” you will also see a Type 2 Network LSA in the Database, which is a manifestation of the network type Broadcast. The next link description is for an OSPF network type of point-to-point which indicates a datalink connecting two OSPF routers. You’ll see the Router ID of the neighbor router listed here, but there is no Designated Router listed since no DR/BDR election occurs on point-to-point links. Last but not least you can see a third link which connects to a stub network. What’s notable here for this discussion is that the Network and Subnet Mask is listed here, but it’s not present in the other link descriptions.
The Type 1 Router LSA is important because collectively these LSA’s paint a picture of the topology for each OSPF router and allows the SPF algorithm to calculate the shortest path to each “Link” present on the network. Understanding the how to identify and examine each LSA type will be crucial to you understanding why traffic routes the way it does in any given topology, and this journey begins with Type 1. We’ll dive into the other LSA types in future posts, but I hope the information provided here gives you a starting point for examining the Link State Database. I would encourage you to utilize a lab environment to create ospf relationships between three routers, and utilize different OSPF network types on the datalinks with the intent to observe how they translate to link information within the Database and specifically the Type 1 LSA.
Thanks for taking time to read this post, feel free to leave a comment with any questions!
-Eric