OSPF Packet Types

OSPF sends packets to neighbors to establish and maintain adjacencies, send and receive requests, ensure reliable delivery of Link-state advertisements (LSAs) between neighbors, and to describe link-state databases. Link-state databases are generated from all the LSAs that an area router sends and receives. The link-state database is then used to calculate the shortest-path spanning tree, using the Shortest Path First (SPF) algorithm.

There are 5 different types of OSPF packets. (1-byte)

1- Hello packet
2- Database Descriptor packet
3- Link State Request packet
4- Link State Update packet
5- Link State Acknowledgment packet

 

Before we discuss different packet types in detail, let’s understand the OSPF packet header.

All OSPF packets share a common OSPF Header of 24-bytes. This header allows the receiving router to validate and process the packets. The format of the standard OSPF header is-

OSPF-Common-Header

Version- 2 (1-byte)
Type It specifies the type of OSPF packet.

Packet Length- Total length of the OSPF packet (2-bytes)

Router ID- The Router ID of the advertising router
Area ID- 32-bit Area ID assigned to the interface sending the OSPF packet (4-bytes)
Checksum- Standard IP Checksum of OSPF packet excluding Authentication field (2-bytes)
AuType- Authentication Type (2-bytes)

0- No Password
1- Plain-text password
2- MD5 authentication

Authentication- Authentication data to verify the packet’s integrity (8-bytes)

Hello Packet

Hello packets are OSPF packet type 1. These packets are multicast periodically to 224.0.0.5 multicast address on all interfaces (unicast on virtual-links) enabling dynamic discovery of neighbors and maintain neighbor relationships. On broadcast and NBMA networks, Hello packets are used to elect DR and BDR.

On NBMA networks, Hello packets are unicast to the neighbor address configured on the router; manual neighbor configuration is required for NBMA networks.
OSPF Hello packet

 

Network Mask- Subnet mask of the advertising OSPF interface. For unnumbered point-to-point interfaces and virtual-links, it is set to 0.0.0.0 (4-bytes)
HelloInterval- Interval at which Hello packets are advertised. By default, 10 seconds for the point-to-point link and 30 seconds for NBMA/Broadcast links (2-bytes)
Options- The local router advertises its capabilities in this field. (1-byte)
Rtr Pri- The Priority of the local router. It is used for DR/BDR election. If set to 0, the router is ineligible for the election. (1-byte)
RouterDeadInterval- The Dead Interval as requested by the advertising router. By default, 40 seconds for the point-to-point link and 120 seconds for NBMA/Broadcast links (4-bytes)
Designated Router- The IP address of the current DR. Set to 0.0.0.0 if no DR is elected yet. (4-bytes)
Backup Designated Router- The IP address of the current BDR. Set to 0.0.0.0 if no BDR is elected yet. (4-bytes)
Neighbor- The Router IDs of all OSPF routers from whom a valid Hello packet has been seen on the network.

The following is a sample packet capture of an OSPF Hello packet.

 

OSPF Hello packet capture

The fields Area IDHelloIntervalRouterDeadInterval, and Authentication information (AuType & Authentication) should match on neighbors to form an adjacency. For example, when the Hello interval is changed on a router, the receiving router does not accept the Hello packet due to a mismatch of Hello timer. The following message is displayed.

Hello parameters mismatch
R1 router:
interface Serial 1/0

 ip address 10.1.1.2 255.255.255.0
 ip ospf 1 area 0
 ip ospf hello-interval 5

!R0 router:

interface Serial 1/0
ip address 10.1.1.1 255.255.255.0
ip ospf 1 area 0
!

R0# debug ip ospf hello
00:18:02.491: OSPF: Rcv hello from 10.1.1.2 area 0 from Serial1/0 10.1.1.2
00:18:02.491: OSPF: Mismatched hello parameters from 10.1.1.2
00:18:02.491: OSPF: Dead R 20 C 40, Hello R 5 C 10


Database Descriptor packet

For the link-state routing protocol, it is required that the link-state databases for all routers remain synchronized. The synchronization starts as soon as the adjacency is formed between neighbors. OSPF uses Database Descriptor (DBD) packets for this purpose.

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

OSPF DBD Header format

Interface MTU- Contains the MTU value of the outgoing interface. For virtual-links, this field is set to 0x0000. (2-bytes)
Options- Same as Options field in a Hello packet (1-byte)
I- Initial Bit. This indicates this is the first in the series of DBD packets (1-bit)
M- More bit. Indicates whether the DBD packet is the last in the series of packets. The last packet has a value of 0, while all previous packets have a value of 1. (1-bit)
MS- Master/ Slave bit. Master=1, Slave=0 (1-bit)
DD Sequence Number- Used to sequence the collection of DBD packets. The initial value should be unique. The sequence number then increments by 1 until the complete database description has been sent. (4-bytes)
LSA Header- This field contains the LSA headers describing the local router’s database. (variable length)

During the DBD packet exchange, a Master/ Slave relationship is established between the neighbors. The router with the highest Router ID becomes the Master and initiates DBD packet exchange. The Interface MTU should match on neighbors otherwise FULL adjacency is not reached.

Interface MTU Mismatch

19:24:22.879: OSPF: Rcv DBD from 10.1.1.2 on Serial1/0 seq 0xA9A opt 0x52 flag 0x7 len 32  mtu 1400 state EXCHANGE
19:24:22.883: OSPF: Nbr 10.1.1.2 has smaller interface MTU19:26:01.591: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on Serial1/0 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions
19:27:01.591: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on Serial1/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired

The following packet capture shows a sample OSPF database. The DBD packets contain the LSA header which contains the summary of this database i.e the Type of LSA, Link State ID, Advertising Router, etc. The neighbors then request further information about these LSAs using Link State Request packets.

OSPF Database

R1# show ip ospf database

            OSPF Router with ID (10.1.1.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.1.1.1        10.1.1.1        1706        0x8000002E 0x00C174 2
10.1.1.2        10.1.1.2        755         0x80000036 0x0031E5 3

OSPF DBD Header format OSPF DBD packet capture

 

Link State Request packet

The Link State Request (LSR) packet is an OSPF packet Type 3. After the DBD packets exchange process, the router may find it does not have an up-to-date database. The LSR packet is used to request pieces of the neighbor database that is more up-to-date.

OSPF LSR header format
LS Type- Type of LSA requested (4-bytes)
Link State ID- Depends upon the type of LSA (4-bytes)
Advertising Router- Router ID of the requesting router (4-bytes)The following packet capture shows the LSR sent for Router-LSA (Type-1) to an OSPF neighbor after the DBD packet exchange process is over.

 

OSPF LSR packet capture

 

Link State Update packet

Link State Update (LSU) packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each LSA contains routing, metric, and topology information to describe a portion of the OSPF network. The local router advertises LSA within an LSU packet to its neighboring routers. Also, the local router advertises the LSU packet with information in response to an LSR packet.

OSPF LSU Header format

# LSAs- Number of LSAs within an LSU packet (4-bytes)
LSAs- The complete LSA is encoded within this field. The LSU may contain single or multiple LSAs.

The following output shows what the router responds to LSR.

Router LSA advertised in response to an LSR

R1# show ip ospf database router 10.1.1.2 adv-router 10.1.1.2

            OSPF Router with ID (10.1.1.2) (Process ID 1)

                Router Link States (Area 0)

  LS age: 748
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 10.1.1.2
  Advertising Router: 10.1.1.2
  LS Seq Number: 80000036

  Checksum: 0x31E5
  Length: 60
  Number of Links: 3

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 10.1.1.1
     (Link Data) Router Interface address: 10.1.1.2
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.1.1.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0

OSPF LSU Packet Capture

 

Link State Acknowledgment packet

Link State Acknowledgment (LSAck) packets are OSPF packet type 5. OSPF requires acknowledgment for the receipt of each LSA. Multiple LSAs can be acknowledged in a single LSAck packet.

OSPF LSAck Header Format

LSA Header- List of LSA Headers being acknowledged.

The following packet capture shows an LSAck packet acknowledging the above LSU packet.

OSPF LSAck Packet Capture