OSPF Packets: Types, Roles, and Exchanges

Open Shortest Path First (OSPF) is a link-state routing protocol that uses five distinct packet types to establish neighbor relationships, synchronize topology databases, and propagate routing updates. Understanding these packets is critical for network troubleshooting, security hardening, and efficient OSPF deployment.

The Five OSPF Packet Types

Hello Packets (Type 1)

Primary Function: Discover and maintain neighbor relationships

Key Characteristics:

• Sent periodically (default: every 10 seconds on broadcast networks)
• Do not require acknowledgments
• Multicast to 224.0.0.5 on broadcast networks
• Elect Designated Routers (DR) and Backup Designated Routers (BDR)

Security Risk: Unauthenticated Hello packets enable rogue router insertion attacks. Always implement OSPF authentication.

Database Description Packets (Type 2)

Primary Function: Exchange topology database summaries between neighbors

Key Characteristics:

• Contains LSA headers only (not full LSA contents)
• Establishes master-slave relationships during synchronization
• Requires acknowledgment
• Sent via unicast

Data Structure:

[LSA Header 1] [LSA Header 2] ... [LSA Header N]

This packet type allows routers to compare their link-state databases efficiently and identify missing or outdated information.

Link-State Request Packets (Type 3)

Primary Function: Request specific LSAs from neighbors

Triggered When:

• DBD exchange reveals missing LSAs
• LSA age exceeds refresh threshold (30 minutes)
• Topology change detected but update not received

Request Format:

[LSA Type] [Link State ID] [Advertising Router]

Link-State Update Packets (Type 4)

Primary Function: Transport actual topology updates

Key Characteristics:

• Contains one or more complete LSAs
• Flooded to all OSPF neighbors (except the originating router)
• Requires acknowledgment via LSAck
• Can be sent via multicast or unicast

Update Triggers:

• Interface state changes (up/down)
• Network topology modifications
• LSA refresh timers (every 30 minutes)

Link-State Acknowledgment Packets (Type 5)

Primary Function: Confirm LSA reception

Reliability Mechanism: LSAck packets ensure reliable flooding by requiring confirmation for all DBD, LSR, and LSU packets.

Acknowledgment Scope:

• Database Description packets
• Link-State Update packets
• Individual LSAs when sent via unicast

---

OSPF Packet Comparison

Packet Type	Type Code	Requires Ack	Primary Function	Transport Method
Hello	1	No	Neighbor discovery	Multicast (224.0.0.5)
DBD	2	Yes	Database summary	Unicast
LSR	3	Yes	Request LSAs	Unicast
LSU	4	Yes	Send updates	Multicast/Unicast
LSAck	5	N/A	Acknowledge	Unicast

---

OSPF Neighbor Establishment Sequence

Understanding the packet exchange workflow is essential for troubleshooting adjacency issues:

sequenceDiagram
    participant A as Router A
    participant B as Router B
    A->>B: Hello (Multicast)
    B->>A: Hello (Unicast)
    A->>B: DBD (Master/Slave Negotiation)
    B->>A: DBD (Database Summary)
    A->>B: LSR (Request Missing LSAs)
    B->>A: LSU (Containing LSAs)
    A->>B: LSAck (Acknowledgment)

Process Breakdown:

1. Discovery: Routers exchange Hello packets to discover neighbors
2. Negotiation: DBD packets establish master-slave relationship
3. Summary Exchange: Routers exchange database summaries
4. Request: Missing LSAs are requested via LSR packets
5. Update: Complete LSAs are sent via LSU packets
6. Confirmation: LSAck packets confirm receipt

---

OSPF Packet Encapsulation

Protocol Stack Structure

┌───────────────────────┐
│   Ethernet Header     │ (Layer 2)
├───────────────────────┤
│   IP Header           │ (Protocol ID: 89)
├───────────────────────┤
│   OSPF Header         │ (24 bytes)
├───────────────────────┤
│   OSPF Packet Data    │ (Variable length)
└───────────────────────┘

Important: OSPF uses IP protocol number 89, not TCP or UDP. This means OSPF packets are encapsulated directly in IP.

OSPF Header Fields

Field	Size (bytes)	Description
Version	1	OSPF version (2 for IPv4, 3 for IPv6)
Type	1	Packet type (1-5)
Packet Length	2	Total packet length including header
Router ID	4	Originating router identifier
Area ID	4	OSPF area identifier
Checksum	2	IP checksum for error detection
AuType	2	Authentication type (0=None, 1=Simple, 2=MD5)
Authentication	8	Authentication data

---

Security Considerations

Common OSPF Vulnerabilities

Unauthenticated Packets:

• Susceptible to spoofing and man-in-the-middle attacks
• Allows unauthorized routers to join OSPF domain

Hello Packet Flooding:

• Can cause neighbor adjacency flapping
• Leads to routing instability and CPU exhaustion

LSU Injection:

• Malicious LSAs can poison routing tables
• Creates blackholes or traffic redirection

DBD Manipulation:

• Forces unnecessary database synchronization
• Causes CPU and bandwidth exhaustion

Security Best Practices

1. Implement Authentication:

interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 SecureKey123

• Use MD5 or SHA authentication for all OSPF packets
• Configure unique keys per interface or area
• Rotate keys regularly

2. Packet Filtering:

• Restrict OSPF to trusted interfaces only
• Implement Control Plane Policing (CoPP) to rate-limit OSPF packets
• Use passive interfaces where routing updates aren't needed

3. Neighbor Validation:

• Explicitly define OSPF neighbors in point-to-point scenarios
• Monitor neighbor state changes
• Alert on unexpected adjacency formations

4. LSA Monitoring:

• Track LSA origination rates for anomalies
• Alert on unexpected LSA types or sources
• Implement LSA database size limits

---

Troubleshooting Common OSPF Issues

Scenario 1: Neighbor Adjacency Stuck in EXSTART/EXCHANGE

Symptoms:

• OSPF neighbors don't reach FULL state
• Repeated DBD packet retransmissions
• Adjacency stuck in EXSTART or EXCHANGE state

Diagnosis Steps:

1. Verify OSPF parameters match:

show ip ospf interface | include Hello|Dead|Area

Check that Hello/Dead timers, area IDs, and network types match on both sides.

2. Check MTU sizes:

ping <neighbor-ip> df-bit size 1500

MTU mismatches prevent DBD packet exchange. Both interfaces must support the same MTU.

3. Examine packet captures: Use Wireshark or tcpdump to capture OSPF packets and look for malformed DBD packets or authentication failures.

Scenario 2: LSAs Not Propagating (