DebugPrivileged EXEC

debug ip ospf adj

Use this command to debug OSPF adjacency events in real-time, helping to troubleshoot why OSPF neighbors are not forming or are flapping.

Syntax·Privileged EXEC
debug ip ospf adj

When to Use This Command

  • Troubleshooting OSPF neighbors stuck in INIT or EXSTART state
  • Diagnosing MTU mismatch causing adjacency to fail
  • Investigating OSPF hello/dead timer mismatches between routers
  • Verifying OSPF adjacency establishment after configuration changes

Command Examples

Successful OSPF adjacency formation

debug ip ospf adj
OSPF: 2 Way Communication to 192.168.1.2 on GigabitEthernet0/0, state 2WAY
OSPF: Send DBD to 192.168.1.2 on GigabitEthernet0/0 seq 0x1E opt 0x52 flag 0x7 len 32
OSPF: Rcv DBD from 192.168.1.2 on GigabitEthernet0/0 seq 0x1E opt 0x52 flag 0x2 len 32  mtu 1500 state EXSTART
OSPF: NBR 192.168.1.2 goes from EXSTART to EXCHANGE
OSPF: Send DBD to 192.168.1.2 on GigabitEthernet0/0 seq 0x1F opt 0x52 flag 0x1 len 32
OSPF: Rcv DBD from 192.168.1.2 on GigabitEthernet0/0 seq 0x1F opt 0x52 flag 0x0 len 32  mtu 1500 state EXCHANGE
OSPF: Exchange Done with 192.168.1.2 on GigabitEthernet0/0
OSPF: Synchronized with 192.168.1.2 on GigabitEthernet0/0, state FULL

The output shows the OSPF adjacency progressing through states: 2WAY (bidirectional communication), EXSTART (master/slave election), EXCHANGE (database description packets), and finally FULL (adjacency established). Each line indicates a step in the process.

OSPF adjacency stuck due to MTU mismatch

debug ip ospf adj
OSPF: Rcv DBD from 192.168.1.2 on GigabitEthernet0/0 seq 0x1E opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART
OSPF: Send DBD to 192.168.1.2 on GigabitEthernet0/0 seq 0x1E opt 0x52 flag 0x2 len 32  mtu 1400 state EXSTART
OSPF: NBR 192.168.1.2 goes from EXSTART to DOWN, due to DBD retransmission timeout
OSPF: NBR 192.168.1.2 goes from DOWN to INIT
OSPF: NBR 192.168.1.2 goes from INIT to 2WAY
OSPF: NBR 192.168.1.2 goes from 2WAY to EXSTART
... (repeats)

The output shows the adjacency repeatedly cycling through states and eventually going DOWN due to DBD retransmission timeout. The MTU values differ (1500 vs 1400), indicating an MTU mismatch that prevents the exchange of database description packets.

Understanding the Output

The debug ip ospf adj output displays real-time OSPF adjacency events. Key fields include: neighbor IP address, interface, state transitions (e.g., from EXSTART to EXCHANGE), and DBD packet details (seq, opt, flag, len, mtu). A successful adjacency will show progression to FULL. Common issues: repeated state transitions or DOWN events indicate problems like MTU mismatch, timer mismatch, or authentication failure. Watch for 'mtu' values in DBD lines; mismatched MTU causes adjacency to fail. Also look for 'retransmission timeout' which indicates packet loss or misconfiguration.

CCNA Exam Tips

1.

CCNA exam expects you to know that OSPF adjacency states are DOWN, INIT, 2WAY, EXSTART, EXCHANGE, LOADING, FULL.

2.

A common exam scenario: OSPF neighbors stuck in EXSTART often due to MTU mismatch or router ID conflict.

3.

Remember that debug ip ospf adj is a privileged EXEC command and can generate heavy output; use with caution in production.

4.

The exam may ask which debug command to use to see OSPF hello packets; that is debug ip ospf hello, not adj.

Common Mistakes

Leaving debug enabled after troubleshooting, causing CPU overload and potential router crash.

Misinterpreting '2WAY' as a problem; it is actually a normal state before EXSTART.

Forgetting to check MTU consistency on both sides when adjacency fails in EXSTART.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions