200-301 · IP Connectivity · Updated August 3, 2026

Why OSPF Neighbors Will Not Form

An OSPF adjacency fails for a small, closed set of reasons. Either the hello packets are not reaching the other router, or they are arriving and being rejected because a value inside them does not agree with the local configuration, or the hellos agree and the database exchange that follows breaks down. The neighbor state tells you which of the three is happening, and the state plus one show ip ospf interface almost always identifies the exact field.

Parameters that must match

Two routers compare these values before either will accept the other as a neighbor. A disagreement in any one of them means the hello is discarded and no neighbor entry ever appears.

Area ID. Both interfaces have to be in the same area. A link with one end in area 0 and the other in area 1 produces silence, not an area border router.
Hello and dead intervals. Both timers must be identical. They are carried inside the hello packet and checked on receipt. Changing one end with ip ospf hello-interval 5 without changing the other breaks a working adjacency in seconds.
Subnet and mask. The two interfaces must be in the same IP subnet with the same prefix length. A /30 facing a /29, or 10.1.1.1 facing 10.1.2.1, fails the check even though the cable is fine. This test is skipped on point-to-point network types, which is why a serial link can survive a mask mismatch that a Gigabit Ethernet link will not.
Authentication. The type (none, plain text, or MD5) and the key, including the key ID for MD5, must match. A key configured on one side only is a common cause of an adjacency that dropped immediately after a change window.
Stub area flags. Both routers must have the same view of whether the area is a stub or a totally stubby area. The flag rides in the hello’s options field.
Network type. Broadcast on one side and point-to-point on the other leaves the two ends disagreeing about whether a designated router should be elected. Mismatching either against non-broadcast or point-to-multipoint also breaks the timers, because those types default to a 30-second hello and a 120-second dead interval instead of 10 and 40.
Unique router IDs. Two routers sharing a router ID will not form an adjacency with each other, and IOS logs a duplicate router ID message.

The MTU (maximum transmission unit) is deliberately absent from that list. It is not checked during hello exchange, which is why an MTU mismatch produces a different and more confusing symptom.

Causes of missing hellos

Before comparing fields, confirm the hellos are being generated and delivered.

The interface is administratively down or the line protocol is down.
OSPF was never enabled on the interface, because the network statement’s wildcard does not actually cover that interface’s address.
The interface is configured as passive. A passive interface advertises its subnet and sends no hellos, so it can never form a neighbor. This is the single most common self-inflicted cause, usually from passive-interface default without a matching no passive-interface on the transit link.
An access list on the interface is blocking IP protocol 89 or the multicast destinations 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all designated routers).
The two routers are in different VLANs, or a trunk’s allowed VLAN list has pruned the segment, so the frames never meet. The allowed list and the rest of the trunk configuration are covered in 802.1Q trunking on Cisco switches.

Neighbor states

State the adjacency sticks in	What it means	Where to look
No entry at all	Hellos are not arriving, or a hello field mismatched	Interface status, passive-interface, area, timers, subnet and mask, authentication
INIT	This router hears the neighbor, but the neighbor does not list this router’s ID in its hello	One-way communication: a filter or ACL in one direction, or unicast reaching one way only
2-WAY	Bidirectional hellos succeeded, DR election finished	Normal and permanent between two DROTHER routers on a broadcast segment; a fault only if one of the pair should be DR or BDR
EXSTART or EXCHANGE	Hellos agreed, database description exchange is failing	MTU mismatch on the two interfaces
LOADING	Link-state requests are not being satisfied	Rare; usually a corrupted or unreachable LSA, or heavy packet loss
FULL	Adjacency is complete	No action

INIT deserves attention because it looks like a partial success and is actually a one-way path. The receiving router puts a neighbor into INIT the moment it sees a hello from it. It only moves to 2-WAY once it sees its own router ID listed in that neighbor’s hello, which proves the neighbor is receiving too.

MTU mismatch

After hellos agree, the routers exchange database description packets to compare their link-state databases. Each DBD packet carries the sending interface’s MTU. If the receiver’s own MTU is smaller than the value in the packet, it refuses to process it, and the adjacency cycles between EXSTART and EXCHANGE without ever reaching FULL. The hello parameters all match, show ip ospf neighbor shows the neighbor present, and nothing looks broken until you read the state column.

R1# show ip ospf neighbor
Neighbor ID     Pri   State     Dead Time   Address         Interface
2.2.2.2           1   EXSTART/DR 00:00:33   10.1.1.2        GigabitEthernet0/1

Compare the two interfaces:

R1# show interfaces GigabitEthernet0/1 | include MTU
  MTU 1500 bytes, BW 1000000 Kbit/sec
R2# show interfaces GigabitEthernet0/2 | include MTU
  MTU 9216 bytes, BW 1000000 Kbit/sec

The correct fix is to make the MTUs equal with ip mtu 1500 under the interface. ip ospf mtu-ignore suppresses the check and lets the adjacency complete, but it leaves a real MTU difference in place that will drop large packets later, so it belongs in a lab or as a temporary measure.

Diagnostic sequence

show ip ospf neighbor for the state, or its absence.
show ip ospf interface GigabitEthernet0/1 on both routers. One screen gives you the area, the process ID, the network type, the cost, the hello and dead intervals, the DR and BDR, and the neighbor count, which covers most of the match list at once.
show ip protocols to confirm which networks the process is matching and which interfaces are passive.
show interfaces for line status and MTU when the state is EXSTART. The same output carries the error counters that expose a marginal cable or transceiver behind an unstable adjacency, which are read in show interfaces counters.
debug ip ospf adj when the static output has not explained it. The debug names the mismatched parameter directly, including authentication failures and area ID conflicts.

If OSPF was never running on the interface at all, the configuration side of this is covered in single-area OSPFv2 configuration.

How the 200-301 exam tests this

The match list as a multi-select. A stem asks which values must agree between neighbors. Area, hello and dead timers, subnet mask, authentication, and stub flags are in. MTU, process ID, router ID, priority, and interface cost are out. Process ID and router ID appear as distractors constantly.
State-to-cause mapping. Output shows a neighbor parked in EXSTART with every hello parameter identical. The answer is MTU, and the distractors offer timers, authentication, and area, all of which would have prevented the neighbor entry from existing.
Passive interface trap. A configuration includes passive-interface default and the stem asks why one link has no neighbor while the subnet is still visible in the routing table of other devices. The subnet being advertised is the clue that OSPF is enabled and hellos are suppressed.
2-WAY as a non-problem. Four routers share a broadcast segment and two of them show 2-WAY/DROTHER. You are asked what is wrong. Nothing is: DROTHER routers form full adjacencies only with the DR and BDR.
Subnet mask mismatch. Two Ethernet interfaces are given addresses that look adjacent but sit under different prefix lengths. No neighbor forms, and the pingable-but-not-peering detail is the giveaway.

Adjacency faults sit inside the biggest block on the blueprint, so let how the 200-301 allocates its 25 percent to IP connectivity decide how many study hours OSPF earns against static routing and first hop redundancy. Then drill the match list with a run of practice questions until process ID stops looking like a plausible answer.

Quick reference

Must match: area ID, hello interval, dead interval, subnet and mask, authentication type and key, stub flags, network type.
Need not match: process ID, router ID (must be unique), OSPF priority, interface cost, bandwidth.
MTU is not checked in hellos; it is checked during database description exchange.
EXSTART or EXCHANGE that never advances points at MTU; fix the MTU rather than using ip ospf mtu-ignore.
INIT means one-way hello delivery.
2-WAY between two DROTHERs on a broadcast segment is the expected steady state.
No neighbor entry at all means hellos are absent or a hello field disagrees.
A passive interface advertises its subnet and never forms an adjacency.
OSPF uses IP protocol 89 with destinations 224.0.0.5 and 224.0.0.6; an ACL that drops either kills adjacency.
Start with show ip ospf interface on both ends; it displays most of the match list on one screen.