Technical guide

OSPF Neighbors Not Forming? A Step-by-Step Troubleshooting Guide

By Subnetica · Published August 24, 2026 · Updated August 24, 2026

Two routers can have IP addresses on the same link and still fail to become OSPF neighbors. The useful question is not simply ‘is OSPF enabled?’ but ‘at which part of hello exchange or database synchronization did the relationship stop?’

Start with the state, not a random configuration change

Imagine R1 and R2 share 10.0.12.0/30, but the expected neighbor never reaches FULL. OSPF uses hellos to discover neighbors and then exchanges link-state database information. The state narrows the search:

DOWN→INIT→2-WAY→EXSTART→EXCHANGE→LOADING→FULL

A neighbor moves from hello exchange to database synchronization before it becomes Full.

DOWN: no usable hello has been received recently.
INIT: a hello arrived, but the local router is not listed in the hello’s neighbor list.
2-WAY: bidirectional hello communication works. On broadcast networks, routers not meant to form full adjacencies can remain here.
EXSTART/EXCHANGE: database descriptions are being negotiated or exchanged; MTU, duplicate IDs, and loss are common suspects.
LOADING: missing LSAs are being requested.
FULL: the adjacency is synchronized; this does not prove the desired route is installed.

The first pass: link, address, and OSPF participation

Check the physical or virtual interface on both routers. A link can be administratively up while a VLAN, cable, namespace veth, or firewall path is wrong. Then verify that the addresses and prefixes describe the same link. For example, 10.0.12.1/30 and 10.0.12.2/30 agree; a different prefix can create a misleading partial design.

# Cisco-style CLI
show ip interface brief
show running-config interface GigabitEthernet0/0
show ip ospf interface GigabitEthernet0/0
show ip ospf neighbor

# FRRouting/Linux
show ip ospf interface eth0
show ip ospf neighbor
ip addr show dev eth0
ip route

Confirm OSPF is enabled on the link. On Cisco IOS this may come from a network statement or interface-level OSPF configuration; in FRR it is commonly an ip ospf AREA interface command or a matching network statement. A passive interface advertises a connected network but does not send hellos, so remove passivity on a router-to-router interface when an adjacency is required.

Compare parameters that must match

Compare area ID, hello and dead intervals, authentication type/key, network type, interface MTU, and router ID. Each router needs a stable unique ID; duplicate IDs can create confusing neighbor and LSA behavior. ACLs, firewalls, and security filters must allow OSPF protocol 89—it is not TCP or UDP port 89.

For a suspected packet-path problem, capture on the actual interface. On Linux, tcpdump -ni eth0 proto 89 shows OSPF packets. Inspect whether hellos arrive from the expected source and whether the neighbor list contains the other router. Cisco capture and debug commands vary by platform.

Use the failure state to choose the next test

No neighbor→ connectivity/configuration·INIT/2-WAY→ hello/network type·EXSTART/EXCHANGE→ MTU/IDs/database exchange·FULL, routes missing→ LSAs/filtering/selection

A compact OSPF troubleshooting decision tree.

DOWN or no neighbor

Check interface state, cabling or veth wiring, addresses, masks, OSPF activation, area, passive status, and protocol-89 filtering. A hello seen in only one direction points to a return-path filter or one-sided configuration.

INIT or 2-WAY

INIT means the received hello does not show this router as a neighbor. Investigate one-way delivery, duplicate addressing, and filtering. On a broadcast network, 2-WAY can be normal for non-DR/BDR pairs; on point-to-point links, compare network type when Full is expected.

EXSTART or EXCHANGE

Compare interface MTUs first. Small hellos can work despite an MTU mismatch, then database-description packets can fail. Also check duplicate router IDs, network type, retransmissions, and filtering. Correct the intended MTU rather than treating a random reduction as the fix.

FULL, but routes are absent

Inspect LSAs, area boundaries, advertisements, filters, summarization, and route selection. Use the companion route-selection guide and FRRouting/Linux routing-table guide when protocol and kernel views disagree.

# Cisco-style
show ip ospf
show ip ospf neighbor
show ip ospf interface
show ip route ospf
show ip route 10.44.8.0

# FRR
show ip ospf
show ip ospf neighbor
show ip ospf interface eth0
show ip route ospf
ip route

After FULL: prove the route and return path

Verify the advertised prefix in the OSPF route view, the selected next hop, and the installed forwarding table. Test a destination in the prefix and inspect the reverse route. A healthy adjacency is a control-plane milestone, not an end-to-end packet guarantee.

Subnetica’s OSPF curriculum and OSPF MTU-mismatch EXSTART lab provide a focused place to practice the state transition. The single-area OSPF lab is useful for comparing a healthy adjacency with a broken one.