OSPF Message Types

Today I am going to talk about the types of messages that can be sent when OSPF is enabled. Every message type is unique in its own way and allows OSPF to function as smoothly as it does. These message types each serve their purpose in their own way from discovering neighbors to providing reliability. There are 5 types of messages which are hello packets, DBD packets, LSU packets, LSR packets, and LSAck packets. I’ve put a chart below matching them to their message type number identifier.

Hello- The first message I am going to talk about is a type 1 message which are hello packets. Hello packets are responsible for discovering neighbors, DR and BDR elections, establishing bidirectional communication with neighbors, and used as “keep alives” to maintain neighbor adjacencies. When OSPF is configured, the OSPF neighbors start in a down state and in order for them to leave a down state, they must receive a hello packet from a neighbor. Receiving a hello packet from a neighbor allows routers to “discover” who they are directly connected to. They also “establish” bidirectional communication with neighbors because there is a neighbor list inside an hello packet. When a local router receives a hello packet with its own RID in the neighbor list, that means the sending router has received a hello packet from the local router. Because the local router is also receiving a hello packet, that proves that a bidirectional communication exists. Hello packets also include priority numbers and sending routers RID. This means that hello packets are also a key factor in DR and BDR elections as those two parameters are how they are chosen. The last but not least is that hello packets are still sent when neighbors are in full adjacent according to a hello interval timer which is usually 10 seconds. These messages are still sent in a “full” state because they allow OSPF routers to be certain that their directly connected links are still alive and reachable regardless of the router’s role (DR, BDR, DRother). 

DBD- The next type of message is a DBD (Database Description) packet which is a type 2 message. These messages include sending RIDs and LSA headers. The sending RID (Interface IP as a tie breaker) in DBD packets is to elect a master and slave during the OSPF adjacency formation process. The highest RID becomes the master of the neighbor relationship. DBD packets also include LSA headers which include summaries of the information in a LSDB. LSA headers are usually described as a “table of contents” for a LSDB. The DBD provides enough information so that the receiving router can know which LSAs are missing or outdated. It is not a full LSA but provides enough context clues to identify the LSAs. 

LSR- Type 3 messages are LSR packets which stand for Link State Requests. These packets are sent out during the OSPF adjacency formation process to request from internal routers any LSAs that they do not have or have been outdated. LSRs can request multiple LSAs at once and are a crucial part of having an identical LSBD when the topology has fully converged.

LSU- The next message after LSR is a LSU which stands for Link State Updates and is a type 4 message. These packets are the actual full LSAs that were requested in the LSR packets. These LSU packets will contain missing, outdated, or updated LSAs. When an LSU is received, the receiving router will install the LSAs inside the LSU into the LSDB and flood the LSU out of all OSPF enabled interfaces except the one it came from (DR others are exempt as they only flood to DR and BDR). LSUs can also be flooded outside the OSPF adjacency formation process. When the OSPF topology is fully converged, if there is any change like a router being added, a cost of a link changing, or a link going down, LSUs will be flooded with the updated LSAs. Just like LSRs, LSUs can carry multiple LSAs at once. LSU packets only carry LSAs; they are not LSAs themselves, think of LSU as the envelope and LSAs as the letters inside.

LSAck- The last message type in OSPF is LSAck (Link State Acknowledgement) which is a type 5 message. This is usually sent whenever an OSPF router receives a LSU packet. This provides a reliability mechanism within OSPF allowing for the sending router to know if the message reached the destination or not. If a router sends an LSU to fulfill an LSR and it doesn’t receive an LSAck within the retransmission timer interval it will send that LSU again until it receives an LSAck. This allows for reliable transmission of LSUs and ensures that all routers have an identical LSDB when fully converged. 

Leave a Reply

Your email address will not be published. Required fields are marked *