OSPF Neighbor Goes Down Repeatedly After Forming
Presenting Symptom
OSPF neighbor adjacency repeatedly transitions from FULL to DOWN after forming, causing routing instability.
Network Context
A small branch office with two Cisco routers (R1 and R2) connected via a FastEthernet link. Both run IOS 15.x and are configured for OSPF in area 0. The link is stable at layer 2, but OSPF neighbors keep flapping every few minutes.
Diagnostic Steps
Check OSPF neighbor state
show ip ospf neighborNeighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 FULL/DROTHER 00:00:32 10.0.0.2 FastEthernet0/0
If neighbor state is FULL, adjacency is up. If it shows DOWN or EXSTART/EXCHANGE, there is a problem. Check if the neighbor appears at all.
Check OSPF interface parameters
show ip ospf interface FastEthernet0/0FastEthernet0/0 is up, line protocol is up Internet Address 10.0.0.1/24, Area 0 Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 10.0.0.1, Interface address 10.0.0.1 Backup Designated router (ID) 10.0.0.2, Interface address 10.0.0.2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Verify that Hello and Dead timers match on both sides. Mismatched timers cause neighbor flapping. Also check network type (should be same on both ends).
Check OSPF events with debug
debug ip ospf eventsOSPF: Rcv hello from 10.0.0.2 area 0 from FastEthernet0/0 10.0.0.2 OSPF: End of hello processing ... OSPF: Rcv DBD from 10.0.0.2 seq 0x1234 opt 0x52 flag 0x7 len 32 OSPF: Send DBD to 10.0.0.2 seq 0x1235 opt 0x52 flag 0x1 len 32 ... OSPF: Neighbor change event on interface FastEthernet0/0 OSPF: DR/BDR election on FastEthernet0/0 OSPF: Neighbor 10.0.0.2 is DOWN
Look for 'Neighbor change event' and 'is DOWN' messages. If you see frequent DR/BDR elections, it may indicate a layer 1/2 issue or OSPF timer mismatch. Also check for 'Hello from' messages to see if hellos are received consistently.
Check interface statistics for errors
show interfaces FastEthernet0/0FastEthernet0/0 is up, line protocol is up
Hardware is Fast Ethernet, address is aaaa.bbbb.cccc
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 2 packets/sec
12345 packets input, 1234567 bytes
Received 12345 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
12345 packets output, 1234567 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped outLook for input errors, CRC, collisions, or interface resets. High error rates indicate layer 1/2 issues causing OSPF packet loss. Also check MTU – mismatched MTU can cause OSPF adjacency problems.
Root Cause
The OSPF Dead timer interval is mismatched between the two routers. R1 has a Dead timer of 40 seconds (default), while R2 has a Dead timer of 20 seconds (configured manually). This causes R2 to declare R1 dead after 20 seconds of not receiving a Hello, even though R1 is still sending Hellos every 10 seconds. The adjacency then rebuilds, but the cycle repeats.
Resolution
Verification
Run 'show ip ospf neighbor' on both routers. The neighbor state should remain FULL and not transition to DOWN. Also run 'show ip ospf interface FastEthernet0/0' to confirm Dead timer is 40 on both sides.
Prevention
1. Always use default OSPF timers unless there is a specific design requirement, and ensure timers match on all routers in the same network segment. 2. Use network monitoring tools to alert on OSPF neighbor state changes. 3. Document any non-default timer configurations and verify consistency during change management.
CCNA Exam Relevance
On the CCNA 200-301 exam, OSPF neighbor issues are a common troubleshooting topic. Questions may present a scenario where OSPF neighbors are flapping and ask to identify the cause (e.g., mismatched timers, MTU, or area ID). Expect multiple-choice or drag-and-drop questions where you must select the correct show command or configuration fix. Key fact: OSPF Hello and Dead timers must match for adjacency to form and stay up.
Exam Tips
Memorize default OSPF timers: Hello 10 sec, Dead 40 sec on broadcast and point-to-point networks.
Remember that 'show ip ospf neighbor' is the first command to check neighbor state; 'show ip ospf interface' reveals timer values.
Be aware that mismatched MTU can also cause OSPF adjacency problems, but it typically prevents full adjacency rather than causing flapping after FULL.
Commands Used in This Scenario
debug ip ospf events
Enables real-time debugging of OSPF event messages to troubleshoot neighbor adjacency issues, route propagation problems, or OSPF state changes.
show ip ospf interface
Displays OSPF interface parameters and status, used to verify OSPF configuration and troubleshoot neighbor relationships.
show ip ospf neighbor
Displays OSPF neighbor information to verify adjacency formation and troubleshoot OSPF neighbor relationships.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions