OSPF packet types
The OSPF stands for an open shortest path first. It is one among the 2 link state routing protocols. Perhaps it is the widely used interior gateway protocol in a large enterprise. It supports the IPv4, IPv6 networks, CIDR and VLSM addressing models. The OSPF detects the topology changes such as converges and link features on the new loop free routing structure in a fraction of a second. All OSPF packets will share the common OSPF header of the 24 bytes. That header allows receiving the router to validate as well as process the packets. The below chapter will cover about the OSPF and its packet types.
Unlike other routing protocols, the OSPF will not carry the data through the transport protocol such as TCP and UDP. Rather than, the OSPF forms the IP datagram directly, packaging t using the protocol number of 89 for an IP protocol field. In the OSPF, there are 5 different types of packets. The format of the common OSPF header is shown below.
- Type specifies the OSPF packet type.
- Packet length is the total length of an OSPF packet
- Area ID is the 32 bit area ID assigned to an interface sending an OSPF packet.
- Au type is the authentication type
0 implies no password, 1 implies the plain text password and 2 implies the MD5 authentication.
- Checksum is the standard IP checksum of the OSPF packet, excluding the authentication field.
- Router ID is the router ID of an advertising router.
It is the type 1 packet. The hello message will perform 4 major functions such as:
- It discovers the other OSPF speaking routers on the common subnets.
- Verify the bidirectional visibility between the routers
- Check for the agreement on a particular configuration parameter
- Monitor the neighbor's health to react suppose the neighbor fails.
To discover the neighbors, the OSPF routers will listen for the multicast hello message. The hello is the source of the router primary address on an interface and in other hand, it is not the source of the secondary IP address. Furthermore, the OSPF neighbors can become adjacent fully if 1 or both neighbors are using the unnumbered interfaces for a connection between that. After the 2 routers discover one another by receiving the Hello from other router, then the router will do the below parameter checks depends on the received hello:
- The dead timers and OSPF hello must be equal
- No duplicate for the RID
- Important to pass an authentication process
- Important to be in a same OSPF area.
- Important to be in a same primary subnet as well as same subnet mask.
- Important to be a same area types such as stub, regular, not-so-stubby area.
If any above items do not match, then the 2 routers do not form the neighbor relationship. The hello messages are the most important packet, which is the form of greeting to permit the router to discover other adjacent router on its networks and local links. The main function of the hello packet is to verify the bidirectional visibility in between the routers on a same segment. Every hello packet comprises the list of neighbors from where the sending router gets valid and also acceptable hello. This variable size list is located mainly in a trailing part of the each hello as well as containing the RID of the router whom hello is seen and get accepted by a router originating from this hello. If the routers found that their own RID in a seen routers list in the Hello received from the neighbor, that can be heard by each other. The other important function of the Hello is to maintain the heartbeat function in between the neighbors. Then the neighbors send Hello to every specific hello interval and the failure to receive the hello within a longer dead interval may cause the router to trust that the neighbor has failed. This hello interval; default is 10 seconds for the interface with point to point or OSPF broadcast network type, but 30 seconds on the interfaces with point to multipoint network type or OSPF non broadcast type and a dead interval default to 4 times that of the hello interval.
Neighbor: a Router ID of all the OSPF routers from whom the valid hello packet must seen on a network.
Backup designated router: the current BDR IP address. Set it to 0.0.0.0 suppose no DR is elected.
Designated router: The Current DR IP address. Set it to 0.0.0.0 suppose no DR is elected.
Router dead interval: a dead interval as requested by an advertising router.
Rte pri: it is the priority of a local router which is used for the BDR/DR election. Suppose set to 0, a router is ineligible for the election.
Network mask: the subnet mask of an advertising OSPF interface. For the unnumbered virtual links and point to point interfaces, it has to set to 0.0.0.0.
Options: a local router advertises the capability in this specific field.
Hello interval: it is the interval at where the hello packet is advertised.
Given below is the sample packet of the OSPF hello packet:
Database descriptor packet:
For the link state routing protocols, it is essential that the link state database for all the routers remain synchronized. This synchronization will begin as soon as an adjacency formed between the neighbors. The OSPF uses the DBD - database descriptor packets for that purpose. The database can be described by using the multiple packets. The poll response procedure is mainly used for the multiple packet description usage. Among the routers, one is designated to be a slave and other as a master. A database description packets are mainly sent by a slave after sending a database description packet by the master.
The OSPF router summarizes the DBD packets and local database carry the set of LSA belongs to the database. When the neighbor sees the LSA, which is more recent than the own database copy, then it request the newer LSA from a neighbor. When 2 routers hear Hello and parameter check passes, it will not send packets immediately which holds the LSA. Rather, each router will create and send the database description packets, that contain the header of the each LSA. This header includes the needed information to uniquely identify the LSA and the revision without transmitting the body. The DD message use the OSPF defined very simple error recovery process. Every DD packet that contains several LSA headers, has the assigned sequence number. Then the receiver acknowledges the received DD packets by sending the DD packet with an identical sequence number again back to the sender. Here, the sender will use the window size of 1 packet and waits for the acknowledgements before sending a next DD packet. As the neighbor forms relationship between the 2 routers, the neighbor determines that the router is to be master and that has to be slave during the database exchange. The roles of slave and master define the responsibility of the routers during the DD packet exchange.
LSA header: It contains an LSA header which describes the local router database.
DD sequence number: It is used to sequence the DBD packet collection. The initial value must be very unique. The sequence number will increase by 1 until the overall database description has sent.
Options: It is similar with the options in the hello packet.
Interface MTU: it contains an MTU value of an outgoing interface. For the virtual links, this field has to set to 0x0000.
Link state request packet:
After all the LSA header exchanged using the DD packets, each neighboring router has the list of the LSA known by a neighbor. Using this knowledge, the router need to request the full copy of the each LSA, which is missing from the own LSDB. To determine whether the neighbor has the most recent copy of the certain LSA, the router looks at a sequence number of an LSA in the LSDB and also compares with the sequence number of that of the same LSA learned from a DD packet. Each LSA sequence number is increased each time the LSA re-originated or changes. If the router gets the LSA header with the later sequence number for the specific LSA, that router knows that a neighbor has the most recent LSA. The Routers will use the link state packets to request 1 or more LSA from the neighbor.
The LSR packet is one of the OSPf packets. After the DBD packet exchange process, a router can find that it has not any up-to-date database. An LSR packet is mainly used to request the pieces of a neighbors database which is more up-to-date.
Link state ID: It depends on the LSA type
LS type: Type of the LSA requested
Advertising router: The router of a requesting router
The below packet capture displays the LSR sent for the router to the OSPF neighbor after the DBD packet exchange processes are over. This packet is utilized for the requesting the neighbor database piece which is more up-to-date. It may require to utilize the multiple link state request packet. The OSPF adjacency states are Init, Attempt, Exstart, loading, full, exchange, down and 2- way.
Link state update packet:
This packet implements the LSA flooding. Every LSA comprises the metric, topology information and routing to describe the OSPF network portion. A local router will advertise the LSA within the LSU packet to the neighboring router. Additionally, a local router advertises an LSU packet with the information in response to the LSR packet.
The primary router sends the database description, one at a time and a secondary router acknowledges the everyone and includes in the own database descriptions. The record is compared with the type, link state ID and advertising router. The sequence number in a record will determines whether the record is older or newer. The flooding of the link state advertisement is mainly implemented by these packets. The collection of the lick state advertisements is mostly carried by the each link state update packet, one hop further from the origin. The packet can be included by the several link state advertisements. Both the routers will sit in the loading state when the LSR and LSA process continues. After the process gets over, it will settle into the full state that means the 2 routers must have fully exchanged their database, results in the identical copies of a LSDB entry.
LSA : It is the complete LSA encoded within the field. An LSU can contain multiple or single LSA.
#LSA: it is the number of the LSA within the LSU packets
Link state acknowledgement packet:
The OSPF needs acknowledgement for a receipt of the each LSA. The multiple LSA may be acknowledged in the single LSAck packet. The LSR/LSA process will use the reliable protocol, which has 2 options, in that link state acknowledgement is among them. The LSU can be acknowledged by a receiver of an LSU simply repeating a same LSU back to the sender. Alternatively, the router will send back the LSAck packet to acknowledge the packets that contain the acknowledged LSA header list. As s result, the LSDB must be identical. At this point, it can independently run a Dikkstra shortest path first algorithm to calculate the best path from own perspective. The reliability of the flooding link state advertisements is made by explicitly acknowledging the flooded advertisements.
LSA header: it is the list of the LSA header being acknowledged
The OSPF sends the packets to neighbors to accomplish as well as maintain the adjacencies, sends and also receive requests, ensure the reliable delivery of the link state advertisement between the neighbors and also to describe the link state database. The link database is generated from all link state advertisements that the area router sends and receives. Then the link state database is used to calculate a shortest path spanning tree with the help of the SPF algorithm.