OSPF Part 1 : Message Types

 Introduction

 
In this post we are going to get to know the packets used in the OSPF process and then build on this in future blogs to gain a good understanding of the topic.

Ospf is a link state protocol , it in essence sets up neighbour relationships with other router in the ospf domain in order to exchange routing information. The messages used in the creation and maintenance of these relationships will be the focus of the blog post.

When the ospf process is turned on on a router and the  interface falls within the ip network range that has been specified with the network command then that interface will actively try to start the party : ie find some neighbours and try to from some adjacencies. So, for example if the following commands were entered in priv level mode and we had interfaces with ip addresses of 10.10.15.1 and 10.10.10.5 then these interfaces would start trying to setup relationships with other routers in area 0
 
router ospf

network 10.10.0.0 0.0.255.255 area 0
 

 Type of Packets Used in the Process

 
OSPF runs directly over IP using protocol number 89. OSPF packets should always be sent with the IP TOS field set to 0. If at all possible, OSPF packets should be given preference over regular IP traffic, both when being sent and received. (As an aid, OSPF packets should have their IP precedence field set to Internetwork Control). All OSPF packets share a common protocol header. Every OSPF packet starts with a standard 24 byte header. This header contains all the information necessary to determine whether the packet should be accepted for further processing.

The following shows the ospf packet header , the various different packet types that we will discuss in the next  section put their various fields and values into the message body part of the packet.
 

 

  Ospf Messages.

 
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 24 byte header as shown above. All OSPF packet types (other than the OSPF Hello packets) deal with lists of link state advertisements. For example, Link State Update packets implement the flooding of advertisements throughout the OSPF routing domain.

• The Hello Packet
• The Database Description Packet.
• The Link state Request Packet
• The Link State Update Packet
• The Link State Acknowledgement Packet

 

  Hello Messages.

 

 

Hello packets are OSPF packet type 1. They serve two functions , one is to setup relationships with neighbours ,the second is to maintain these relationships by sending packets at a given interval to ensure the neighbouring devices is still alive.

These packets are sent periodically on all interfaces in order to establish and maintain neighbor relationships. In addition, Hello Packets are multicast on those physical networks having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers and unicast on other link types but more on that on following posts. Hello Packets are closely tied to Dead Timer Values, as mentioned  routers will use the hello packet to maintain state with other devices if a device does not respond to these hello packets then the sending device deems the other device to be down . So for example on an ethernet network  if router A  sends 4 hello packets without response it will deem router B to be down.Default Values for Dead Timer = Hello Timer *4   The default timers are listed below.
 
Default Timers for hello/Dead Timer Packets

Broadcast Networks: 10 Secs  40 Secs

Non Broadcast Multiaccess Networks: 30 Secs  120 Secs
 
During the setup phase of OSPF neighbours will exchange hello Packets . In order for the relations to move on to a fully adjacent state certain parameters must match in the hello packets exchanged between devices.

These are:

• Must Pass the authentication process , ie they must agree that authentication is turned on and if so then they must agree on the method and password variables.
• They must be in the same primary subnet including the same subnet mask.
• They must be in the same area.
• They must be of the same area type. (stub NSSA and so on)
• They re must not be duplicate RIDS (router ids)
• The ospf hello and dead timers must match.

 

  Database Description Packets.

 

 

Remember that although we have not delved too deeply into OSPF too deeply yet we do know that the main objective is the exchange of routes between the devices. This is where the DD packets come into to play.

The DD packets are OSPF packet Type 2. The OSPF router summarizes the local database and the DD packets carry a set of LSAs belonging to the database. When a neighbor sees an LSA that is more recent than its own database copy, it requests this newer LSA from the neighbor.

It is important to note here that in OSPF the database of learned routes that a devices know is held in various ospf databases.LSA or Link State Advertisements are just the state of a link that attach to the device.

When two devices are starting to exchange this information it  must be done on a organinsed and acknowledged manner. To achieve this during the exchange of information one of the devices becomes the master and one becomes the slave this allows for tagging and tracking all packets .The first DD packet is used to elect the master and slave relationship and to set the initial sequence number elected by the master. The router with the highest router ID becomes the master and initiates the database synchronization. The master sends the sequence number, and the slave acknowledges it. After the master and the slave are elected, the database synchronization starts; in this process, the headers of all the LSAs are exchanged with neighbors. Remember that the LSA’s are attached link to any given device for example is router A has two interfaces that are in up state , that are both 100 Mbps , and have ips of 10.10.0.1/2 then the LSA that is announced is a reflection of that information and a DD is summary of this information.
 

  Link State Request Messages.

 

 

Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its topological database are out of date. These packets consist of the OSPF header (as usual) plus fields that uniquely identify the database information that the router is seeking.

A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting, defined by LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request Packet itself. The router may receive even more recent instances in response.
 

  Link State Update Messages.

 

 

Link-State Update messages are OSPF packet with Type 4. These packets implement the flooding of LSAs. The Link-State Update message are acknowledged using Link-State Acknowledgement messages. These messages are sent to ALL SPF Routers multicast address. However, if re-sending is required, then they are unicast.

This message will fill in the gaps and provide as all the details that were not included in the DD message. LSA themselves can take up a varirty of formats an will be covered in a later post , for now understanding that the update packet contains details about the LSA (or a number of LSA’s) is the key goal here.
 

  Link State Acknowlegment  Messages.

 

 

These messages have a Type value of 5 in the header. They then contain a list of LSA headers corresponding to the LSAs being acknowledged. Simply put they acknowledge the LSA’s they received by responding with the corresponding LSA headers.
 

  Goodbye

 
Thats it for the OSPF message types , this blog has been a high level overview of the message that are used by OSPF , in the next post we will put their application to use and see how devices become neighbours and start exchanging LSA’s
 
Kevin 🙂