OSPF: Database Exchange Process including messages, neighbor states, and all things neighbor forming related!

OSPF_Base_Topology

Sticking with this Topology in case I need to lab something for demonstration, it is clear what routers are where.

To begin, every router within any given Area should have an identical copy of the LSDB, and that only Type 1 and Type 2 LSA’s are flooded only within the Area they originated.

The Database exchange uses several messages and process to build a neighbor relationship, and only after it has made it through the correct amount of processes, are then LSA’s flooded to that neighbor.

There are 5 types of OSPF messages that will come from an OSPF enabled router:

  • Hello
  • DBD (Database Descriptor)
  • Link-State Request
  • Link-State Update
  • Link-State Acknowledgement

Hello packets are what begin to form the neighbor relationship, it “triggers” the formation, and the exchange of DBD’s is what is crucial because it contains all of the parameters that must be agreed upon and met to actually form a neighbor relationship.

Once a neighbor relationship can be formed, Link-State Request / Updates / Acks are exchanged by neighbors to make sure they have accurate matching LSDB’s.

Now to go through the stages of forming a neighbor relationship, starting from the beginning:

Down – This is technically a state, but you will never see a neighbor as “Down” in “sh ip ospf nei”, but you will see it in console messages and logs

Attempt – This state is seen when “static” OSPF neighbors are configured on a Non-Broadcast Multi-Access network type, Attempt means “I statically configured you and am trying to say Hello to you, but have not heard anything back yet”

**To note the ATTEMPT / DROTHER state is always present on my OSPF NBMA because it is Hub and Spoke, and there is no need for a DR / BDR election across it, so I configure the routers with Priority 0 to suppress their attempts to participate in said election**

Init – This means the local router has received a Hello packet from it’s potential neighbor, that contains the links of the other neighbors it knows about, except for you. This indicates that you share common neighbors but are not yet formally acquainted!

2way – The opposite of an “Init” is a Hello packet the DOES include the local routers link, like an acknowledgement to the Init sent, like a receipt that it got the initial Hello. This state also determines who the DR and BDR will be if a neighborship is formed in their segment, if that type of segment allows for DR’s and BDR’s.

Unless you are a DR, or a BDR, routers do not get past this 2way state (which explains the behavior of 4 OSPF routers on a segment where the DROTHERS saw each other as 2way/DROTHER). Only the DR or BDR will see these neighbors as FULL, but any DROTHER router will see another DROTHER router in 2way and their neighborship only forms to the point of knowing each other but not flooding LSA’s to each other.

ExStart – This is the state that comes after a DR / BDR is agreed upon, or agreed that no DR / BDR can exist in this type of connection, and attempt to exchange what are called either DBD’s or DD’s (Database Descriptors) – I have seen the same thing used with both acronyms.

This state exchanges an empty (of Data) DBD with your IP and RID, and exchanges those with the neighbor to come up with who will be the Slave and Master of the neighborship. Once this is determined, the Master will set the sequence number of exchanging information, and begin the exchange (much alike TCP).

Exchange – The state after a Slave / Master is elected, the neighbors now multicast DBD’s that are now populated with LSA Headers, and finding out what LSA’s are missing from each others LSDB.

Loading – This is the state where all those missing LSA’s are requesting by the neighbor in the form of a Link-State Request packet, to which the neighbor response with s Link-State Update (LSU) packet, and finally the original neighbor sends back a Link-State Acknowledgement packet.

Full – When you and your neighbor are fully synchronized and all Link State packets have been exchanged and received.

Now that the Database is fully populated from our new Neighbors, SPF steps in to calculate the best paths it has to each network in the LSDB, both and all OSPF routers do this.

The DR and BDR’s Perspective

Communication to these is multicast to the 224.0.0.6 address, and the full range of states is gone through with both the DR and BDR, but not to any other DROTHER’s if you are a DROTHER router type.

DROTHERS stay in a state of 2way, and are only “FULL” from the DR / BDR’s perspective because those are the only routers it has gotten to the Full OSPF State with.

DR and BDR’s multicast updates back to DROTHERS on 224.0.0.5, the same address they communicate to each other on.

LSA Flooding information

OSPF re-floods each LSA every 30 minutes based on it’s variable age in the LSDB, which counts up from 0 (starting when it was created), and if no changes occur to the LSA when it hits the age of 30 minutes the originating router increments the sequence number / re-floods the LSA / changes the timer back to 0.

This is the Periodic Flooding OSPF does.

To verify, use the “sh ip ospf database” command and you can see these timers and sequence numbers in action:

R1#sh ip ospf data

            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         398         0x8000000A 0x00CCAA 1
2.2.2.2         2.2.2.2         745         0x8000000E 0x0086E3 1
3.3.3.3         3.3.3.3         492         0x8000000A 0x005015 1

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
172.12.123.1    1.1.1.1         398         0x8000000A 0x0017C4

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         1.1.1.1         657         0x80000009 0x0037F4
2.2.2.2         2.2.2.2         257         0x8000000C 0x00E43C
3.3.3.3         3.3.3.3         492         0x80000009 0x009E7D
172.12.15.0     1.1.1.1         1888        0x8000000A 0x0068FE
172.12.34.0     3.3.3.3         492         0x8000000D 0x0054F4
 –More–

I had actually wondered what on Earth those were, so that is good new OSPF material that I will forget in precisely 2 weeks (after passing the exam).

When the router needs to remove an LSA from the LSDB or “Poison” it, it sets the MaxAge to 3600.

That will complete this section of OSPF with LSA types and all of that sort, I’ve spent my time digging through these, if you are reading this to learn more I highly recommend reading the sticky post with my collection of links of the 3 Part deep dive into LSA types and OSPF Router types!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s