OSPF Packet Types and Header Format

OSPF uses five kinds of packets, from discovering neighbors through synchronizing the LSDB (see What Is OSPF for the overall flow). Every one of them starts with the same 24-byte common header, followed by a body specific to the packet type. This article covers OSPFv2 (for IPv4, RFC 2328): the addresses and protocol number OSPF packets use, the role of each of the five packet types, and the fields of the common header, checking each of them against packet captures taken on real devices (Cisco IOS XR).

Addresses and Protocol Number Used by OSPF Packets

OSPF does not use TCP or UDP; its packets are carried directly as the payload of an IP packet. The protocol number field of the IPv4 header is set to 89.

Depending on the purpose, the destination IP address is one of the following multicast addresses or a unicast address.

Destination address	Name	Purpose
`224.0.0.5`	AllSPFRouters	To every router running OSPF on the link. Used for Hello packets and for flooding from the DR to the other routers.
`224.0.0.6`	AllDRouters	To the DR and the BDR. Used when a DROther router sends LSAs.
Unicast	—	Used for packets addressed to a specific neighbor, such as the DBDs, LSRs and LSUs exchanged while an adjacency is being established.

For packets sent to a multicast address, the destination MAC address of the Ethernet frame is a multicast address too: 224.0.0.5 maps to 01:00:5E:00:00:05 and 224.0.0.6 to 01:00:5E:00:00:06. These multicast packets are sent with TTL 1 and are never forwarded off the link.

OSPF Packet Types

OSPF uses the following five packet types, distinguished by the Type field of the common header.

Type	Packet name	Role
1	Hello	Discovers OSPF routers on the link and maintains neighbor relationships. Also used to check that parameters such as the Hello interval, Dead interval, area ID and authentication match.
2	DBD (Database Description)	Tells the neighbor which LSAs are in the sender’s LSDB by listing their headers (an index). Exchanged while the adjacency is being established.
3	LSR (Link State Request)	Requests the LSAs that the sender is missing, or has an older copy of, after looking at the DBDs.
4	LSU (Link State Update)	Carries the LSAs themselves. Sent in reply to an LSR and also when flooding after a topology change. One LSU can carry several LSAs.
5	LSAck (Link State Acknowledgment)	Acknowledges the LSAs received in an LSU. Because OSPF does not use TCP, reliable delivery of LSAs relies on these acknowledgments.

The detailed format of each packet and how it maps to the neighbor state machine will be covered in OSPF Neighbor States.

OSPFv2 Common Header Format

This 24-byte header is common to all five packet types.

Field	Size	Description
Version #	8 bits	OSPF version. `2` for OSPFv2 used with IPv4 and `3` for OSPFv3 used with IPv6.
Type	8 bits	Packet type. `1`=Hello, `2`=DBD, `3`=LSR, `4`=LSU, `5`=LSAck.
Packet length	16 bits	Length in bytes of the whole OSPF packet including the OSPF header.
Router ID	32 bits	Router ID of the router that sent the packet. See OSPF Router ID for details.
Area ID	32 bits	Area ID of the interface the packet was sent out of. `0.0.0.0` is the backbone area.
Checksum	16 bits	Checksum of the whole OSPF packet excluding the Authentication field. It is not computed and is set to `0` when AuType is 2 (cryptographic authentication).
AuType	16 bits	Authentication type. `0`=none, `1`=simple password, `2`=cryptographic.
Authentication	64 bits	Authentication field whose content depends on AuType (see below).

The area is a per-interface property, so the same router puts a different Area ID in packets sent out of different interfaces. If the Area ID does not match between neighbors, no neighbor relationship forms even though the Hellos arrive.

AuType and the Authentication Field

The value of AuType changes how the 8-byte Authentication field is used.

AuType	Authentication type	Content of the Authentication field
`0`	Null authentication	Not used. Anything may be sent and the receiver ignores it.
`1`	Simple password	The configured password is carried as-is. Because it can be read from a packet capture, its security value is limited.
`2`	Cryptographic authentication	Holds a key identifier and a sequence number, and a message digest is appended to the end of the packet (see below).

When AuType is 2, the Authentication field has the following format.

Field	Size	Description
0	16 bits	Unused. Set to `0`.
Key ID	8 bits	Identifier of the key used for authentication. It must match between neighbors.
Auth Data Len	8 bits	Length in bytes of the message digest appended to the end of the packet. `16` for MD5.
Cryptographic sequence number	32 bits	A monotonically increasing sequence number used to prevent replay attacks.

The message digest itself (Cryptographic data) is appended after the OSPF packet. How to configure authentication and how it behaves will be covered in OSPF Authentication.

RFC 5709 extends cryptographic authentication (AuType 2) so that the HMAC-SHA algorithms can be used in addition to MD5. The header format stays the same; only the value of Auth Data Len changes to the digest length of the algorithm (32 for SHA-256).

Verification on Real Devices

Test Environment

The tests use the same single-area topology as What Is OSPF: three Cisco IOS XR (XRd) routers connected in a line.

clear ospf 1 process was run on R1 to restart the OSPF process, and the re-establishment of the adjacency between R1 and R2 was captured on the link between them (ospf-packet-types.pcap). In the sections that follow, each of the five packet types is taken from this capture and examined.

No.	Time	Source	Destination	Type	What is happening
1-5	0.0-14.8	both ways	224.0.0.5	1 (Hello)	Steady-state Hellos (every 10 seconds)
6-8	19.3-21.3	R1, R2	224.0.0.5	4, 5 (LSU, LSAck)	R1’s LSA is flushed because of the process restart
10-12	24.2	R1, R2	unicast	2 (DBD)	Deciding which router is the master
13, 15	24.2	R2, R1	unicast	2 (DBD)	Exchanging the LSDB index (LSA headers)
14, 17	24.2	R1, R2	unicast	3 (LSR)	Requesting the missing LSAs
16, 18	24.2	R2, R1	unicast	4 (LSU)	Sending the requested LSAs
19-21	24.2-24.3	R1, R2	224.0.0.5	4 (LSU)	Flooding the updated LSAs
22, 23	26.2	R1, R2	224.0.0.5	5 (LSAck)	Acknowledging the received LSAs

The routers themselves also count the packets of each type, which can be seen with show ospf statistics interface.

R1 packet counters per type
RP/0/RP0/CPU0:R1#show ospf statistics interface GigabitEthernet0/0/0/0
Sat Sep  5 06:10:53.827 UTC

	Interface GigabitEthernet0/0/0/0 Process ID 1 Area 0

OSPF packet and LSA statistics
          RX(hello) RX(router)        TX     LSA RX     LSA TX
Hello           14          -         15          -          -
DB Des           2          2          3          3          1
LS Req           1          1          1          1          0
LS Upd           3          3          2          5          2
LS Ack           2          2          1          1          4
TOTAL           22          8         22         10          7

Hello (Type 1)

After the common header come the parameters needed to form a neighbor relationship on the link.

Here is the Hello sent by R1 (No.1) from the capture.

Hello from R1 to 224.0.0.5 (No.1)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xce8f [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x12, (L) LLS Data block, (E) External Routing
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 10.1.2.2
        Backup Designated Router: 10.1.2.1
        Active Neighbor: 2.2.2.2

Matching the fields against the test topology makes their meaning clear.

Field	Value	What it corresponds to in the topology
Source OSPF Router	`1.1.1.1`	Router ID of R1, the sender.
Area ID	`0.0.0.0`	Gi0/0/0/0 belongs to area 0.
Network Mask	`255.255.255.0`	The mask of 10.1.2.0/24, the segment R1’s Gi0/0/0/0 belongs to.
Hello Interval / Router Dead Interval	`10` / `40`	The defaults for Ethernet (broadcast).
Router Priority	`1`	The default. Used for the DR/BDR election.
Designated Router	`10.1.2.2`	R2 is the DR on this link (given as an interface address).
Backup Designated Router	`10.1.2.1`	R1 itself is the BDR.
Active Neighbor	`2.2.2.2`	R2’s router ID is known. Seeing your own router ID listed here by the peer is what proves the link is bidirectional.

Note when reading this packet that the DR and BDR are given as interface addresses (10.1.2.2) while neighbors are given as router IDs (2.2.2.2).

DBD (Type 2)

The packet that tells the neighbor the “index” of the LSAs in the sender’s LSDB while an adjacency is being established.

The first DBDs exchanged do not carry any LSA header yet.

First DBD from R2 to R1 (No.11)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: DB Description (2)
        Packet Length: 32
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xcb84 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF DB Description
        Interface MTU: 1500
        Options: 0x52, (O) Opaque, (L) LLS Data block, (E) External Routing
        DB Description: 0x07, (I) Init, (M) More, (MS) Master
        DD Sequence: 1838377182

DB Description: 0x07 has the I (Init), M (More) and MS (Master) bits all set, meaning “this is the first DBD, more will follow, and I claim to be the master”. R1 sends a DBD making the same claim (No.10), and R2, whose router ID (2.2.2.2) is higher, becomes the master while R1 (1.1.1.1) becomes the slave. The Interface MTU has to match the neighbor’s, otherwise the adjacency cannot move on to the Exchange state.

Once the master is decided, DBDs carrying LSA headers are exchanged.

DBD from R2 to R1 (No.13)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: DB Description (2)
        Packet Length: 92
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x0cf5 [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    OSPF DB Description
        Interface MTU: 1500
        Options: 0x52, (O) Opaque, (L) LLS Data block, (E) External Routing
        DB Description: 0x01, (MS) Master
        DD Sequence: 1838377183
    LSA-type 1 (Router-LSA), len 60
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000005
        Length: 60
    LSA-type 1 (Router-LSA), len 48
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000003
        Length: 48
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000001
        Length: 32

The I bit is now clear, leaving 0x01 (MS only), and the headers of the three LSAs in R2’s LSDB are listed: R2’s own Router-LSA (2.2.2.2), R3’s Router-LSA (3.3.3.3) and the Network-LSA of the segment between R2 and R3 (10.2.3.3, generated by R3 as the DR). The fact that R2 is adjacent to R3 shows up directly in the contents of its LSDB. The LSAs themselves are not included here: only their identifiers (LS Type / Link State ID / Advertising Router) and sequence numbers.

LSR (Type 3)

The packet that requests the LSAs found to be missing after comparing the index received in the DBDs with the sender’s own LSDB.

LSR from R1 to R2 (No.14)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Request (3)
        Packet Length: 60
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0xd49b [correct]
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    Link State Request
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
    Link State Request
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
    Link State Request
        LS Type: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3

R1’s LSDB is empty right after the process restart, so it requests all three of the LSAs announced in the DBD. One LSA is identified by the triple of LS Type, Link State ID and Advertising Router, and that triple repeats for as many LSAs as are requested.

LSU (Type 4)

The packet that carries the requested LSAs. It is also used for flooding when the topology changes.

LSU from R2 to R1 (No.16)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Update (4)
        Packet Length: 168
        Source OSPF Router: 2.2.2.2
        Area ID: 0.0.0.0 (Backbone)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LS Update Packet
        Number of LSAs: 3
        LSA-type 1 (Router-LSA), len 60
            LS Type: Router-LSA (1)
            Link State ID: 2.2.2.2
            Advertising Router: 2.2.2.2
            Sequence Number: 0x80000005
            Number of Links: 3
            Type: Stub     ID: 2.2.2.2         Data: 255.255.255.255 Metric: 1
            Type: Stub     ID: 10.1.2.0        Data: 255.255.255.0   Metric: 1
            Type: Transit  ID: 10.2.3.3        Data: 10.2.3.2        Metric: 1
        LSA-type 1 (Router-LSA), len 48
            LS Type: Router-LSA (1)
            Link State ID: 3.3.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000003
            Number of Links: 2
            Type: Stub     ID: 3.3.3.3         Data: 255.255.255.255 Metric: 1
            Type: Transit  ID: 10.2.3.3        Data: 10.2.3.3        Metric: 1
        LSA-type 2 (Network-LSA), len 32
            LS Type: Network-LSA (2)
            Link State ID: 10.2.3.3
            Advertising Router: 3.3.3.3
            Sequence Number: 0x80000001
            Attached Router: 2.2.2.2
            Attached Router: 3.3.3.3

As Number of LSAs: 3 says, the three LSAs requested by the LSR are carried together. Looking at the first one, R2’s Router-LSA, Number of Links: 3 describes the three links R2 has, which is exactly what R2 looks like in the test topology.

Link in the Router-LSA	Type	Meaning
ID `2.2.2.2` / Data `255.255.255.255`	Stub	R2’s Loopback0 (2.2.2.2/32).
ID `10.1.2.0` / Data `255.255.255.0`	Stub	The segment connecting to R1. At this point the adjacency with R1 is not yet established, so it is advertised as a stub network.
ID `10.2.3.3` / Data `10.2.3.2`	Transit	The segment connecting to R3. A transit network reached through the DR (`10.2.3.3` = R3).

The second LSA, R3’s Router-LSA, has Number of Links: 2 for R3’s Loopback0 and the segment to R2. The third, a Network-LSA, lists 2.2.2.2 and 3.3.3.3 as the routers attached to the segment between R2 and R3. The format of the LSA bodies differs per LSA type and will be covered in LSA Overview.

LSAck (Type 5)

The acknowledgment for the LSAs received.

LSAck from R1 to 224.0.0.5 (No.22)
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: LS Acknowledge (5)
        Packet Length: 104
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Auth Type: Null (0)
        Auth Data (none): 0000000000000000
    LSA-type 1 (Router-LSA), len 60
        LS Type: Router-LSA (1)
        Link State ID: 2.2.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000006
    LSA-type 1 (Router-LSA), len 48
        LS Type: Router-LSA (1)
        Link State ID: 3.3.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000003
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.2.3.3
        Advertising Router: 3.3.3.3
        Sequence Number: 0x80000001
    LSA-type 2 (Network-LSA), len 32
        LS Type: Network-LSA (2)
        Link State ID: 10.1.2.2
        Advertising Router: 2.2.2.2
        Sequence Number: 0x80000001

For each of the four LSAs it received, R1 returns only the contents of the header (LS Type / Link State ID / Advertising Router / Sequence Number). The LSA bodies are not included. Because OSPF does not use TCP, the sender retransmits any LSA for which this acknowledgment does not come back.

With Authentication Configured (AuType = 2)

MD5 authentication was configured on Gi0/0/0/0 of R1 and R2 to see how AuType and the Authentication field of the common header change.

Configuration applied to R1 and R2
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0
   authentication message-digest
   message-digest-key 1 md5 clear kazulog
  !
 !
!

After the configuration, show ospf interface reports that authentication is enabled and which key ID is in use.

R1 checking authentication
RP/0/RP0/CPU0:R1#show ospf interface GigabitEthernet0/0/0/0
(omitted)
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1
  Multi-area interface Count is 0

Here is the common header of a Hello captured with authentication enabled (ospf-packet-auth-md5.pcap).

Hello with authentication
Open Shortest Path First
    OSPF Header
        Version: 2
        Message Type: Hello Packet (1)
        Packet Length: 48
        Source OSPF Router: 1.1.1.1
        Area ID: 0.0.0.0 (Backbone)
        Checksum: 0x0000 (None)
        Instance ID: Base IPv4 Unicast Instance (0)
        Auth Type: Cryptographic (2)
        Auth Crypt Key id: 1
        Auth Crypt Data Length: 16
        Auth Crypt Sequence Number: 1788588490
        Auth Crypt Data: 357df694ff8e5472f82e6268f72c80e5
    OSPF Hello Packet
        Network Mask: 255.255.255.0
        Hello Interval [sec]: 10
        Options: 0x12, (L) LLS Data block, (E) External Routing
        Router Priority: 1
        Router Dead Interval [sec]: 40
        Designated Router: 10.1.2.2
        Backup Designated Router: 10.1.2.1
        Active Neighbor: 2.2.2.2

Auth Type is now Cryptographic (2), and the 8 bytes of the Authentication field are split into Key ID (1), Auth Data Length (16, the digest length of MD5) and the Cryptographic Sequence Number.
Auth Crypt Data is the 16-byte message digest appended to the end of the packet.
The Checksum is 0x0000 (None), because with AuType 2 the checksum is not computed and integrity is guaranteed by the authentication digest instead.
The body of the Hello (Network Mask, DR/BDR and so on) is unchanged. Authentication only changes AuType and Authentication in the common header.

The Cryptographic Sequence Number increases every time a packet is sent, which is what prevents an attacker from replaying a captured packet.

Frame	Time	Cryptographic Sequence Number
No.1	0.000	1788588490
No.3	9.204	1788588499
No.6	16.316	1788588506
No.23	25.445	1788588515
No.25	35.365	1788588524

If authentication is configured on only one of the two routers, the packets that fail authentication are discarded by the receiver. In these tests too, a mismatch existed between configuring R1 and configuring R2, and the Auth RX counter under OSPF Header Errors in R2’s show ospf statistics interface went to 2. The same key must be configured on both ends of the adjacency.

Verification Config

The running-config of each router at the time of the tests (with MD5 authentication configured), and the output of show ospf neighbor, show ospf interface GigabitEthernet0/0/0/0 and show ospf statistics interface GigabitEthernet0/0/0/0. Loopback1 (11.11.11.11) on R1 was added for the OSPF Router ID tests and is not part of OSPF. The vrf Mgmt on MgmtEth0/RP0/CPU0/0 is for management access to the test lab.

Download R1 config (r1_ospf-packet-format.cfg)

Download R2 config (r2_ospf-packet-format.cfg)

Download R3 config (r3_ospf-packet-format.cfg)

Download R1 show output (r1_ospf-packet-format_show.txt)

Download R2 show output (r2_ospf-packet-format_show.txt)

Download R3 show output (r3_ospf-packet-format_show.txt)

The files captured on the link between R1 and R2. ospf-packet-types.pcap was taken without authentication and ospf-packet-auth-md5.pcap with MD5 authentication configured; both contain all five packet types.

Download ospf-packet-types.pcap

Download ospf-packet-auth-md5.pcap

References

RFC	Title	Summary
RFC 2328	OSPF Version 2	The OSPFv2 specification. The common header format is defined in Appendix A.3.1 and the packet types in Section 4.3.
RFC 5709	OSPFv2 HMAC-SHA Cryptographic Authentication	The extension that adds HMAC-SHA to cryptographic authentication (AuType 2).

IANA - Open Shortest Path First (OSPF) Parameters (the registry of packet types and AuType values)