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.
Definition: debug ip ospf adj is a Cisco IOS privileged exec command. Use this command to debug OSPF adjacency events in real-time, helping to troubleshoot why OSPF neighbors are not forming or are flapping.
Overview
The `debug ip ospf adj` command is a powerful diagnostic tool used in Cisco IOS to monitor OSPF adjacency events in real-time. OSPF (Open Shortest Path First) is a link-state routing protocol that establishes neighbor relationships, or adjacencies, to exchange routing information. Adjacency formation is critical for OSPF operation; without it, routers cannot share routes.
This debug command provides granular visibility into the state machine transitions, hello packet exchanges, and error conditions that occur during adjacency establishment or maintenance. Network engineers reach for this command when neighbors fail to form, flap repeatedly, or when there are mismatched parameters (like area IDs, network types, or authentication). Unlike `show ip ospf neighbor`, which gives a static snapshot, `debug ip ospf adj` shows the dynamic process, revealing why a neighbor is stuck in INIT, EXSTART, or EXCHANGE state.
It is often used after verifying basic connectivity (ping) and OSPF configuration (network statements). The command outputs to the console or logging buffer; it can impact router performance under heavy load, so it should be used selectively and disabled with `undebug all` or `no debug ip ospf adj`. Privilege level 15 (privileged EXEC) is required.
The debug output does not affect the running configuration but may fill the log buffer, potentially causing high CPU if excessive. This command is indispensable for troubleshooting OSPF adjacency issues, especially in complex topologies with multiple areas, virtual links, or MPLS environments.
debug ip ospf adjWhen 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
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| interface | interface-type interface-number | Optional parameter to limit debugging to a specific interface (e.g., GigabitEthernet0/0). Without it, debugging applies to all OSPF-enabled interfaces. Common mistake: forgetting to specify the interface when troubleshooting a specific link, leading to excessive output. |
| neighbor | A.B.C.D | Optional parameter to filter debugging for a specific neighbor IP address. Useful when multiple neighbors exist. Common mistake: using the router ID instead of the neighbor's interface IP address; the command expects the IP address of the neighbor's interface. |
Command Examples
Successful OSPF adjacency formation
debug ip ospf adjOSPF: 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 adjOSPF: 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.
Configuration Scenarios
Troubleshooting OSPF adjacency stuck in INIT state
Two routers are directly connected but the OSPF neighbor state remains INIT. This scenario demonstrates using debug to identify a mismatch in hello/dead intervals or area ID.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2Steps
- 1.Step 1: On R1, enter privileged EXEC mode: enable
- 2.Step 2: Start debugging OSPF adjacency events: debug ip ospf adj
- 3.Step 3: Observe the debug output as R1 attempts to form adjacency with R2. Look for messages like 'Mismatched hello parameters' or 'No route to neighbor'.
- 4.Step 4: If mismatch is detected, check OSPF configuration on both routers: show running-config | section router ospf
- 5.Step 5: Correct the mismatch (e.g., change hello interval to match) and re-verify adjacency: show ip ospf neighbor
! On R1 interface GigabitEthernet0/0 ip address 10.0.12.1 255.255.255.252 ip ospf hello-interval 10 ! router ospf 1 network 10.0.12.0 0.0.0.3 area 0 ! On R2 interface GigabitEthernet0/0 ip address 10.0.12.2 255.255.255.252 ip ospf hello-interval 30 ! router ospf 1 network 10.0.12.0 0.0.0.3 area 0
Verify: After correction, use 'show ip ospf neighbor' to see FULL state. Expected output: Neighbor 10.0.12.2, interface GigabitEthernet0/0, state FULL
Watch out: A common mistake is forgetting that the hello interval must match on both sides; also, the dead interval is automatically set to 4 times the hello interval unless explicitly configured.
Debugging OSPF adjacency flapping due to MTU mismatch
OSPF adjacency forms but repeatedly flaps between EXCHANGE and DOWN. This scenario uses debug to identify an MTU mismatch causing DBD packet rejection.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2Steps
- 1.Step 1: On R1, enable debugging: debug ip ospf adj
- 2.Step 2: Watch for messages like 'Database Descriptor (DBD) has mismatched MTU' or 'Too large DBD packet'.
- 3.Step 3: Check MTU on both interfaces: show interfaces GigabitEthernet0/0 | include MTU
- 4.Step 4: Adjust MTU on the interface with the larger MTU to match the smaller one: interface GigabitEthernet0/0, ip mtu 1400
- 5.Step 5: Clear OSPF process to force re-adjacency: clear ip ospf process
! On R1 interface GigabitEthernet0/0 ip address 10.0.12.1 255.255.255.252 ip mtu 1400 ! router ospf 1 network 10.0.12.0 0.0.0.3 area 0 ! On R2 interface GigabitEthernet0/0 ip address 10.0.12.2 255.255.255.252 ip mtu 1500 ! router ospf 1 network 10.0.12.0 0.0.0.3 area 0
Verify: After MTU alignment, adjacency should stabilize. Use 'show ip ospf neighbor' to confirm FULL state and 'show ip route' to verify OSPF routes.
Watch out: MTU mismatch is often overlooked because ping with large packets may still succeed. The OSPF DBD packets are typically 1500 bytes, so a mismatch causes rejection. Also, the 'ip mtu' command must be used, not 'mtu' (which affects Layer 2).
Troubleshooting with This Command
When using `debug ip ospf adj`, a healthy adjacency formation typically shows a sequence like: 'Hello received from 10.0.12.2', '2-Way Communication', 'ExStart', 'Exchange', 'Loading', 'Full'. If you see only 'Hello received' and then nothing, the neighbor may be stuck in INIT due to mismatched parameters. Key fields to focus on include: 'Mismatched hello parameters' (area ID, hello/dead intervals, authentication), 'No route to neighbor' (missing network statement or passive interface), 'DBD mismatch' (MTU or options field), and 'Retransmit timeout' (packet loss).
Common symptoms: adjacency stuck in INIT indicates hello issues; stuck in EXSTART/EXCHANGE suggests DBD problems; flapping between states often points to MTU or authentication mismatches. A step-by-step diagnostic flow: 1) Verify Layer 3 connectivity with ping. 2) Check OSPF configuration with `show ip ospf interface`. 3) Enable `debug ip ospf adj` and observe the state transitions. 4) If errors appear, compare configurations on both ends. 5) Use `show ip ospf neighbor` to confirm final state. Correlate with `debug ip ospf packet` for detailed packet inspection, or `show ip ospf database` to verify LSDB synchronization.
Remember to disable debugging immediately after troubleshooting to avoid CPU impact. The command is best used during maintenance windows or on low-traffic links.
CCNA Exam Tips
CCNA exam expects you to know that OSPF adjacency states are DOWN, INIT, 2WAY, EXSTART, EXCHANGE, LOADING, FULL.
A common exam scenario: OSPF neighbors stuck in EXSTART often due to MTU mismatch or router ID conflict.
Remember that debug ip ospf adj is a privileged EXEC command and can generate heavy output; use with caution in production.
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.
debug ip ospf adj vs show ip ospf neighbor
Both 'debug ip ospf adj' and 'show ip ospf neighbor' are used to troubleshoot OSPF adjacency issues, but they serve different purposes. The debug command provides real-time, verbose event logs during neighbor formation, while the show command gives a static snapshot of the current neighbor state. They are often confused because both relate to OSPF neighbors, but one is intrusive and the other is not.
| Aspect | debug ip ospf adj | show ip ospf neighbor |
|---|---|---|
| Real-time vs Static | Live event stream | Snapshot at moment of command |
| System Impact | High CPU, may disrupt production | Minimal, safe for production |
| Output Type | Verbose prose describing events | Structured table with key fields |
| Persistence | Runs until disabled or reload | Single execution, no persistence |
| Configuration Required | Requires 'terminal monitor' for remote | None beyond enable mode |
| Typical Use | Diagnosing neighbor flap or stuck states | Routine check of neighbor status |
Use debug ip ospf adj when you need to observe real-time OSPF adjacency events, such as why a neighbor is failing to reach Full state or is flapping.
Use show ip ospf neighbor when you quickly need a current view of all OSPF neighbors and their adjacency states without impacting router performance.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches), the syntax and output are identical to classic IOS, but the command may be hidden under 'debug ip ospf adjacency' (same). On NX-OS (Nexus switches), the equivalent is `debug ip ospf adjacency` (note spelling difference: 'adjacency' instead of 'adj'). NX-OS also supports `debug ip ospf events` for broader debugging.
On ASA firewalls, OSPF debugging is done via `debug ospf adjacency` in the system context. In IOS-XR, the command is `debug ospf adjacency` (no 'ip') and requires the 'c' (console) option to see output. Behavior differences: In IOS 12.x, the output is less verbose; in 15.x and 16.x, additional fields like 'Options mismatch' are included.
The command is available in all IOS versions but may be deprecated in newer releases in favor of conditional debugging (e.g., `debug condition`). Always check the specific platform documentation for exact syntax.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions