OSPF neighbors will not form: the checklist that finds it

OSPF neighbor adjacency failures are among the most common routing issues in enterprise networks. Unlike static routes or BGP, OSPF requires bidirectional communication and precise parameter alignment. When neighbors refuse to form, the root cause is almost always one of a small set of configuration mismatches or interface problems. This checklist walks you through the systematic troubleshooting process used by network engineers to isolate and fix OSPF adjacency failures in production environments.

Step 1: Verify Interface Status and OSPF Enablement

Before diving into OSPF-specific parameters, confirm that the physical and logical interfaces are up and that OSPF is actually running on them. A common mistake is enabling OSPF on the wrong interface or forgetting to enable it entirely.

! Cisco IOS
show interface GigabitEthernet0/0 | include line protocol
show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0

! Junos
show interfaces ge-0/0/0
show ospf interface

Look for the interface to be in UP/UP state. If it shows DOWN/DOWN or UP/DOWN, the physical or data-link layer has a problem. If OSPF is not listed in the output, verify the network statement in the OSPF process or the interface configuration.

Step 2: Check Hello and Dead Timers

OSPF neighbors must agree on hello and dead interval timers. The hello interval is how often OSPF sends keepalive packets; the dead interval is how long to wait before declaring a neighbor dead. If these do not match, neighbors will never reach the FULL state.

! Cisco IOS
show ip ospf interface GigabitEthernet0/0 | include Timer

! Junos
show ospf interface detail

• →Default hello interval: 10 seconds on point-to-point and broadcast networks
• →Default dead interval: 40 seconds (4 times the hello interval)
• →Point-to-multipoint networks use 30 second hello and 120 second dead by default
• →Both routers must use identical timers on the same segment

If timers differ, manually set them to match. Mismatches often occur when mixing vendor equipment or when one side was manually configured and the other was left at defaults.

Step 3: Validate Network Type and Area

OSPF network type determines how neighbors are discovered and elected. Mismatches prevent adjacency formation. Additionally, both interfaces must be in the same OSPF area.

! Cisco IOS
show ip ospf interface GigabitEthernet0/0 | include Network Type
show ip ospf interface GigabitEthernet0/0 | include Area

! Junos
show ospf interface detail | match "Network type|Area"

• →Broadcast: expects a DR/BDR election; common on Ethernet
• →Point-to-Point: no DR/BDR; used on serial links and some tunnels
• →Point-to-Multipoint: no DR/BDR; used for hub-and-spoke topologies
• →Non-Broadcast: requires static neighbor configuration; rare in modern networks

If one side is set to broadcast and the other to point-to-point, neighbors will not form. Verify both routers agree on network type and that both interfaces belong to the same area (e.g., area 0 for the backbone).

Step 4: Check MTU and Authentication

Path MTU mismatches cause OSPF packets to be dropped or fragmented. OSPF authentication failures silently reject neighbor packets. Both are silent killers of adjacency.

! Cisco IOS - check MTU
show interface GigabitEthernet0/0 | include MTU

! Cisco IOS - check authentication
show ip ospf interface GigabitEthernet0/0 | include Authentication

! Junos
show interfaces ge-0/0/0 | match mtu
show ospf interface detail | match "Authentication"

• →Standard Ethernet MTU is 1500 bytes; OSPF adds 20-byte IP header and 8-byte OSPF header
• →If one interface has ip mtu 1500 and the other has ip mtu 1400, larger packets will fail
• →Authentication type (none, simple password, MD5, SHA) must match on both sides
• →Authentication key IDs and passwords must be identical

Enable debug logging to see authentication rejections: 'debug ip ospf adj' on Cisco or 'set protocols ospf traceoptions' on Junos. MTU issues often appear as intermittent neighbor flaps rather than complete failure.

Step 5: Verify Subnet Mask and IP Addressing

Neighbors must be able to reach each other on the same subnet. Mismatched subnet masks or addressing errors prevent OSPF from even seeing the neighbor.

! Cisco IOS
show ip ospf neighbor detail
show ip interface GigabitEthernet0/0

! Junos
show ospf neighbor detail
show interfaces ge-0/0/0

• →Both interfaces must be in the same IP subnet (same network address and mask length)
• →If one is 10.0.0.1/24 and the other is 10.0.0.1/25, they cannot communicate
• →Verify no interface is in a DOWN or UNASSIGNED state

Putting It All Together

Use this checklist in order: interface status, timers, network type and area, MTU and authentication, then subnet and addressing. Most OSPF neighbor failures resolve at step 2 or 3. When you have verified all five areas and neighbors still do not form, enable packet captures and debug logs to see what packets are being sent and rejected. Understanding OSPF cost calculation is also valuable when neighbors do form but traffic does not take the path you expect. Use the Elematron OSPF Cost Calculator to validate your interface costs and ensure the best path is selected.