Guide

OSPF Neighbor Not Forming: Troubleshooting Stuck States

An OSPF neighbor that never reaches FULL stops at a specific point, and that point tells you which check failed. A neighbor missing from show ip ospf neighbor is usually having its hellos rejected, or OSPF is not running on the interface. INIT means hellos work in one direction only. EXSTART or EXCHANGE means the hellos match but the database exchange fails. This guide breaks a working adjacency on IOS XE 17.16 in each of those ways, and every output block below is what the routers printed. For what the states mean when everything works, see OSPF neighbor states explained.

By Alec Gauldin, Principal Network Engineer · Published September 2026

Part of the OSPF learning hub. Practice on hands-on CCNA labs.

A backbone area and one area beside it — the reference wiring for OSPF, not a specific lab.

Read the state before you touch the config

Run show ip ospf neighbor on both routers first. The state, or the missing line, narrows the search before you open any config.

Timing matters too. A change to how OSPF runs on an interface acts at once on the router you make it on: making an interface passive tore down the adjacency in the lab below a tenth of a second after the command. A fault that only stops hellos from being accepted, such as a timer, a key or an inbound ACL, takes up to the dead interval, 40 seconds with the defaults, and each router waits out its own. Give a change that long before you judge it.

What you see	What it means	Check first
No line for the neighbor	No hello from the neighbor is being accepted, or OSPF is not running on this interface	`show ip ospf interface brief`, passive interfaces, an inbound ACL, then the hello values
INIT	This router hears the neighbor, but the neighbor's hellos do not list this router	ACLs and hello checks on the neighbor's side
2WAY	Normal between two DROTHERs on a shared segment	Nothing, unless the two routers should be adjacent
EXSTART or EXCHANGE	Hellos match, but the database exchange fails	The MTU on both interfaces
FULL, but routes are missing	The adjacency is up, but SPF does not use the link	The network type on both interfaces

The lab behind the examples

Four routers run OSPF process 1 in area 0. R1 through R4 share one Ethernet segment, 10.1.1.0/24, through a switch. R1 and R2 also have a direct link, 10.0.12.0/30 on Ethernet0/1, with the network type set to point-to-point. Router IDs are 1.1.1.1 through 4.4.4.4, and each router advertises Loopback0 as 10.255.0.n/32. Every fault below is on the R1-R2 link, so the segment keeps working.

R1 and R2 are neighbors twice, so R2's router ID appears twice in R1's table. Read the Interface column: a fault on Ethernet0/1 removes one line and leaves the other. The 2WAY/DROTHER line is normal, because routers on a shared segment that are neither DR nor BDR stop at 2WAY (DR and BDR election explains why).

The segment also keeps R1 and R2 reachable while their direct adjacency is down. Dead Time counts down between reads: treat it as a snapshot, not a constant.

R1(config)# interface Ethernet0/1
R1(config-if)# ip address 10.0.12.1 255.255.255.252
R1(config-if)# ip ospf network point-to-point
R1(config-if)# exit
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 10.255.0.1 0.0.0.0 area 0
R1(config-router)# network 10.1.1.0 0.0.0.255 area 0
R1(config-router)# network 10.0.12.0 0.0.0.3 area 0

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:38    10.0.12.2       Ethernet0/1
2.2.2.2           1   2WAY/DROTHER    00:00:38    10.1.1.2        Ethernet0/0
3.3.3.3           1   FULL/BDR        00:00:33    10.1.1.3        Ethernet0/0
4.4.4.4           1   FULL/DR         00:00:35    10.1.1.4        Ethernet0/0

R1's side of the direct link, and its neighbor table with every adjacency up. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 1 — Check that OSPF runs on both interfaces

show ip ospf interface brief lists every interface running OSPF with its area, cost, state and neighbor counts, where Nbrs F/C is full adjacencies over total. If the link is missing from that list, nothing enables OSPF on it: no network statement matches the interface address, and no area is set on the interface itself. network 10.0.12.0 0.0.0.3 area 0 matches 10.0.12.0 through 10.0.12.3 only, so check the wildcard against the address (single-area OSPF shows both ways to enable OSPF). Confirm the interface is up/up while you are there.

Next, look for a passive interface. passive-interface Ethernet0/1 keeps the subnet in OSPF but stops hellos on that interface, and the router ignores hellos arriving there, so the adjacency drops immediately rather than at the dead timer. The tell is that Et0/1 is still listed, still in area 0, still at cost 10, with Nbrs F/C at 0/0: the interface is in the process and simply is not speaking. show ip ospf interface says No Hellos (Passive interface) outright, and show ip protocols lists it under Passive Interface(s). Removing the line brought the neighbor back to FULL with no dead-timer wait.

R1(config)# router ospf 1
R1(config-router)# passive-interface Ethernet0/1

R1# show ip ospf interface Ethernet0/1 | include Hello|Neighbor Count
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    No Hellos (Passive interface) 
  Neighbor Count is 0, Adjacent neighbor count is 0 

R1# show ip protocols | include Passive|Ethernet0/1
  Passive Interface(s):
    Ethernet0/1

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               10.255.0.1/32      1     LOOP  0/0
Et0/1        1     0               10.0.12.1/30       10    P2P   0/0
Et0/0        1     0               10.1.1.1/24        10    DROTH 2/3

! Fix: remove the passive line
R1(config)# router ospf 1
R1(config-router)# no passive-interface Ethernet0/1

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:38    10.0.12.2       Ethernet0/1

Passive on Ethernet0/1: OSPF still runs on the link, but R1 sends no hellos and has no neighbor there. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 2 — Compare the hello values

If OSPF runs on both interfaces and neither is passive, either the hellos are not arriving at all — an inbound ACL on this router does that — or they arrive and are rejected. Compare show ip ospf interface Ethernet0/1 on both routers line by line. Two commands name the failed check: show ip ospf traffic Ethernet0/1 keeps a counter per discard reason and debug ip ospf hello prints mismatched values as they arrive. Every counter below was read after a clear ip ospf traffic, and each counter name covers one check, so the number belongs to the fault being shown; they are live counters, and yours will differ.

A router accepts a hello only when these values match its own settings for the interface (RFC 2328, sections 8.2 and 10.5). Some of these faults are logged, but often on one router only, so read both logs before you conclude that nothing happened.

Area ID
Hello interval and dead interval
Authentication type and key
Subnet mask, on broadcast and non-broadcast networks only; point-to-point links skip this check
Stub area flag: both routers must agree on whether the area is a stub
Router ID: IOS also drops a hello that carries its own router ID

Area mismatch

Both ends of a link must be in the same area. Here R1's network statement for the link moved to area 1 while R2 stayed in area 0. R1 shows the link in area 1 with no neighbors, and now calls itself an area border router, because it has interfaces in two areas, one of them the backbone. It logs %OSPF-4-ERRRCV for each hello it rejects, roughly every five to ten seconds. The message is written from R1's point of view: R1 is the one in area 1, so it reports a mismatched area ID from backbone area, naming R2's address and the interface.

R2 logs nothing at all: its only evidence is a neighbor count of zero plus the Area Mismatch counter in show ip ospf traffic. See multi-area OSPF for how areas should be assigned.

R1(config)# router ospf 1
R1(config-router)# no network 10.0.12.0 0.0.0.3 area 0
R1(config-router)# network 10.0.12.0 0.0.0.3 area 1

R1# show logging | include ERRRCV
*Sep 17 19:58:26.340: %OSPF-4-ERRRCV: Received invalid packet: mismatched area ID from backbone area from 10.0.12.2, Ethernet0/1
*Sep 17 19:58:32.201: %OSPF-4-ERRRCV: Received invalid packet: mismatched area ID from backbone area from 10.0.12.2, Ethernet0/1
...

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               10.255.0.1/32      1     LOOP  0/0
Et0/0        1     0               10.1.1.1/24        10    DROTH 2/3
Et0/1        1     1               10.0.12.1/30       10    P2P   0/0

R1# show ip ospf | include border
 It is an area border router

R2# show ip ospf interface Ethernet0/1 | include Neighbor Count
  Neighbor Count is 0, Adjacent neighbor count is 0 

R2# show ip ospf traffic Ethernet0/1 | include Area Mismatch
  Area Mismatch 7, No Sham Link 0, Self Originated 0,

! Fix: put the link back in area 0
R1(config)# router ospf 1
R1(config-router)# no network 10.0.12.0 0.0.0.3 area 1
R1(config-router)# network 10.0.12.0 0.0.0.3 area 0

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:37    10.0.12.2       Ethernet0/1

R1 logs the mismatch; R2 only counts it. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Hello and dead timers

Hello and dead intervals must match exactly. IOS keeps the dead interval at four times the hello unless you set it, so ip ospf hello-interval 5 on R1 turned its Timer intervals line into Hello 5, Dead 20, Wait 20 while R2 kept Hello 10, Dead 40, Wait 40. Both routers then showed a neighbor count of zero, so the two Timer intervals lines side by side are the whole diagnosis.

Read the traffic counter carefully: in Duplicate ID 0, Hello 5, MTU Mismatch 0, the Hello figure counts hellos discarded for bad parameters, not an interval. To see the values themselves, run debug ip ospf hello. Each rejected hello prints a Mismatched hello parameters line and a line of R and C pairs, where R is what the neighbor sent and C is what this interface has configured; here that read Dead R 40 C 20, Hello R 10 C 5. Stop it with undebug all.

R1(config)# interface Ethernet0/1
R1(config-if)# ip ospf hello-interval 5

R1# show ip ospf interface Ethernet0/1 | include Timer|Neighbor Count
  Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
  Neighbor Count is 0, Adjacent neighbor count is 0 

R1# show ip ospf traffic Ethernet0/1 | include Duplicate ID
  Duplicate ID 0, Hello 5, MTU Mismatch 0,

R2# show ip ospf interface Ethernet0/1 | include Timer|Neighbor Count
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Neighbor Count is 0, Adjacent neighbor count is 0 

R1# debug ip ospf hello
OSPF hello debugging is on
R1# show logging | include Mismatched|Dead R
*Sep 17 20:04:23.336: OSPF-1 HELLO Et0/1: Mismatched hello parameters from 10.0.12.2
*Sep 17 20:04:23.336: OSPF-1 HELLO Et0/1: Dead R 40 C 20, Hello R 10 C 5
...
R1# undebug all
All possible debugging has been turned off

! Fix: return to the default intervals
R1(config)# interface Ethernet0/1
R1(config-if)# no ip ospf hello-interval

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:38    10.0.12.2       Ethernet0/1
R1# show ip ospf interface Ethernet0/1 | include Timer
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

The new hello interval on R1 also changed its dead interval; R2 still runs the defaults. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Authentication

Authentication must match in type and key; configuring OSPF authentication covers the setup. Here R1 has MD5 on Ethernet0/1 and R2 has none, and R1 simply loses the neighbor. Two lines in show ip ospf interface say what R1 is expecting: this release prints Cryptographic authentication enabled and Youngest key id is 1, not the older wording about message digests. The Authentication counter in show ip ospf traffic rises with every discarded packet. Use the same key ID and key on both ends, or none on either.

R1(config)# interface Ethernet0/1
R1(config-if)# ip ospf authentication message-digest
R1(config-if)# ip ospf message-digest-key 1 md5 LAB-KEY-1

R1# show ip ospf interface Ethernet0/1 | include Neighbor Count|authentication|key id
  Neighbor Count is 0, Adjacent neighbor count is 0 
  Cryptographic authentication enabled
    Youngest key id is 1

R1# show ip ospf traffic Ethernet0/1 | include Authentication
  Authentication 6, TTL Check Fail 0, Adjacency Throttle 0,

! Fix: match the other end (here, no authentication on either side)
R1(config)# interface Ethernet0/1
R1(config-if)# no ip ospf authentication
R1(config-if)# no ip ospf message-digest-key 1

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:31    10.0.12.2       Ethernet0/1

MD5 on one end only: R1 keeps rejecting R2, and the Authentication counter carries the evidence. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Duplicate router ID

Router IDs must be unique, and a config copied from another router is the usual way that breaks. On this release the change took effect the moment it was entered: R1 logged %OSPF-6-NEW_RTRID: New router-id will take effect immediately and reset its adjacencies, with no clear ip ospf process and no reload, so the common advice that a router-id change waits for a process clear did not hold here. A tenth of a second later R1 logged %OSPF-4-DUP_RTRID_NBR with the duplicate ID, the address it came from and the interface, its Duplicate ID counter climbed, and show ip ospf confirmed R1 was running with R2's ID. Restoring a unique ID was equally immediate.

R1(config)# router ospf 1
R1(config-router)# router-id 2.2.2.2

R1# show logging | include RTRID
*Sep 17 20:22:26.204: %OSPF-6-NEW_RTRID: New router-id will take effect immediately. If OSPF adjacencies are UP for OSPF-1 they will be reset.
*Sep 17 20:22:26.322: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 2.2.2.2 from 10.0.12.2 on interface Ethernet0/1

R1# show ip ospf | include with ID
 Routing Process "ospf 1" with ID 2.2.2.2

R1# show ip ospf traffic Ethernet0/1 | include Duplicate ID
  Duplicate ID 14, Hello 0, MTU Mismatch 0,

! Fix: restore a unique router ID
R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:36    10.0.12.2       Ethernet0/1
R1# show ip ospf | include with ID
 Routing Process "ospf 1" with ID 1.1.1.1

R1 using R2's router ID: the new ID applies at once, and the duplicate is logged a tenth of a second later. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 3 — INIT: hellos arrive in one direction only

INIT means this router receives the neighbor's hellos, but those hellos do not list this router's ID: the neighbor is not receiving, or not accepting, what this router sends. The cause is on the far side or on the path between, so the router showing INIT often has a clean config.

Here R2 has an inbound ACL on Ethernet0/1 that permits ICMP and denies everything else, including OSPF, which is IP protocol 89. R2's hellos still go out, so R1 keeps hearing R2 and drops to INIT once R2 stops listing it. R1's interface reports Neighbor Count is 1, Adjacent neighbor count is 0: one neighbor heard, none adjacent. R2, hearing nothing, reports zero of both. The match counter on R2's deny entry points straight at the cause, and the ping across the link still succeeds 5/5, which is why this fault is easy to miss.

An inbound ACL on an OSPF interface needs a permit for OSPF above any deny. Adding one as sequence 15 fixed the link without rewriting the list, and the counter on that new line proves it is being hit.

R2(config)# ip access-list extended LINK-IN
R2(config-ext-nacl)# permit icmp any any
R2(config-ext-nacl)# deny ip any any
R2(config-ext-nacl)# exit
R2(config)# interface Ethernet0/1
R2(config-if)# ip access-group LINK-IN in

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   INIT/  -        00:00:30    10.0.12.2       Ethernet0/1
2.2.2.2           1   2WAY/DROTHER    00:00:39    10.1.1.2        Ethernet0/0
3.3.3.3           1   FULL/BDR        00:00:34    10.1.1.3        Ethernet0/0
4.4.4.4           1   FULL/DR         00:00:33    10.1.1.4        Ethernet0/0

R1# show ip ospf interface Ethernet0/1 | include Neighbor Count
  Neighbor Count is 1, Adjacent neighbor count is 0 

R1# ping 10.0.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R2# show ip ospf interface Ethernet0/1 | include Neighbor Count
  Neighbor Count is 0, Adjacent neighbor count is 0 

R2# show ip access-lists LINK-IN
Extended IP access list LINK-IN
    10 permit icmp any any
    20 deny ip any any (10 matches)

! Fix: permit OSPF ahead of the deny
R2(config)# ip access-list extended LINK-IN
R2(config-ext-nacl)# 15 permit ospf any any

R2# show ip access-lists LINK-IN
Extended IP access list LINK-IN
    10 permit icmp any any (10 matches)
    15 permit ospf any any (8 matches)
    20 deny ip any any (12 matches)

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:34    10.0.12.2       Ethernet0/1

The ACL is on R2, but R1 is the router that shows INIT. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Step 4 — EXSTART or EXCHANGE: check the MTU

A neighbor that passes 2WAY and then stalls has matching hellos and a failing database exchange. Each database description packet carries the sender's interface MTU, and a router rejects one that advertises a larger MTU than its own interface accepts (RFC 2328, section 10.6). Hellos carry no MTU, so the pair gets this far before it stops.

The check runs only while the databases are exchanged, so the fault was injected by lowering R1's IP MTU to 1400 and bouncing the interface to force a rebuild. Both ends then sat in EXSTART, not just the one doing the rejecting, and R1's MTU Mismatch counter climbed. The two show ip interface readings are the diagnosis: 1400 bytes on R1, 1500 on R2.

One quirk in that output: show ip ospf traffic Ethernet0/1 prints an interface block and a summary block, so the counter line appears twice. Set the same MTU on both ends; removing the override brought the adjacency back to FULL with no second bounce, because the pair was still retrying the exchange.

R1(config)# interface Ethernet0/1
R1(config-if)# ip mtu 1400
R1(config-if)# shutdown
R1(config-if)# no shutdown

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   EXSTART/  -     00:00:37    10.0.12.2       Ethernet0/1
...

R1# show ip interface Ethernet0/1 | include MTU
  MTU is 1400 bytes
R1# show ip ospf traffic Ethernet0/1 | include MTU Mismatch
  Duplicate ID 0, Hello 0, MTU Mismatch 10,
  Duplicate ID 0, Hello 0, MTU Mismatch 10,

R2# show ip ospf neighbor | include Ethernet0/1
1.1.1.1           0   EXSTART/  -     00:00:38    10.0.12.1       Ethernet0/1
R2# show ip interface Ethernet0/1 | include MTU
  MTU is 1500 bytes

! Fix: match the MTU (here, back to the 1500-byte default)
R1(config)# interface Ethernet0/1
R1(config-if)# no ip mtu

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:32    10.0.12.2       Ethernet0/1
R1# show ip interface Ethernet0/1 | include MTU
  MTU is 1500 bytes

R1 at 1400 bytes and R2 at 1500: both ends stay in EXSTART. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

The mtu-ignore workaround

ip ospf mtu-ignore skips the check on the interface where it is set. On R1, the router that was rejecting the packets, it brought the adjacency to FULL with R1 still at 1400 and R2 still at 1500. It suppresses the check, not the mismatch: R2 can still send a packet larger than R1 accepts, so keep it for links whose MTU genuinely cannot change.

R1(config)# interface Ethernet0/1
R1(config-if)# ip mtu 1400
R1(config-if)# ip ospf mtu-ignore
R1(config-if)# shutdown
R1(config-if)# no shutdown

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           0   FULL/  -        00:00:36    10.0.12.2       Ethernet0/1
R1# show ip interface Ethernet0/1 | include MTU
  MTU is 1400 bytes

FULL with the MTUs still different: the check is suppressed, not satisfied. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

FULL, but no routes over the link: network type mismatch

One mismatch still reaches FULL. Network type is not a hello check, so a point-to-point interface and a broadcast interface become neighbors anyway. The damage is in SPF: the point-to-point end describes the link as a direct connection, the broadcast end as a multi-access network with a DR, and SPF uses a link only when both ends describe it the same way.

Here no ip ospf network point-to-point was applied on R1 only. R1 now runs the interface as Network Type BROADCAST in State DROTHER and lists R2 as FULL/DR, while R2 still lists R1 as FULL with a dash. Both entries look healthy. The routing table is where it shows: each router's route to the other's loopback keeps only the Ethernet0/0 path across the shared segment. Restoring the network type put the Ethernet0/1 path back, and its age against the other entry's shows which one was just relearned.

R2 does log this one, as %OSPF-4-NET_TYPE_MISMATCH, and the captured line below stops mid-sentence: the message wraps onto a second line that | include NET_TYPE does not match, so run show logging unfiltered to read the rest. The reliable check is the Network Type line of show ip ospf interface on both ends.

R1(config)# interface Ethernet0/1
R1(config-if)# no ip ospf network point-to-point

R1# show ip ospf neighbor | include Ethernet0/1
2.2.2.2           1   FULL/DR         00:00:38    10.0.12.2       Ethernet0/1
R1# show ip ospf interface Ethernet0/1 | include Network Type|State
  Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DROTHER, Priority 1
R1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 10.1.1.2 on Ethernet0/0, 00:02:45 ago
  Routing Descriptor Blocks:
  * 10.1.1.2, from 2.2.2.2, 00:20:50 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1

R2# show logging | include NET_TYPE
*Sep 17 20:20:12.942: %OSPF-4-NET_TYPE_MISMATCH: Received Hello from 1.1.1.1 on Ethernet0/1 indicating a  potential 
R2# show ip ospf neighbor | include Ethernet0/1
1.1.1.1           0   FULL/  -        00:00:39    10.0.12.1       Ethernet0/1
R2# show ip route 10.255.0.1
Routing entry for 10.255.0.1/32
...
  Routing Descriptor Blocks:
  * 10.1.1.1, from 1.1.1.1, 00:26:27 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1

! Fix: the same network type on both ends
R1(config)# interface Ethernet0/1
R1(config-if)# ip ospf network point-to-point

R1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 10.0.12.2 on Ethernet0/1, 00:00:59 ago
  Routing Descriptor Blocks:
  * 10.1.1.2, from 2.2.2.2, 00:21:59 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1
    10.0.12.2, from 2.2.2.2, 00:00:59 ago, via Ethernet0/1
      Route metric is 11, traffic share count is 1

Both routers list the neighbor as FULL, but neither routes over Ethernet0/1 until the types match. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Verify the repair

After any fix, check both routers: the neighbor is FULL, or 2WAY where that is expected, show ip ospf interface brief shows the adjacency count you expect on each interface, and routes use the link again. Here that means Et0/1 back at 1/1 and two equal-cost paths to R2's loopback.

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               10.255.0.1/32      1     LOOP  0/0
Et0/1        1     0               10.0.12.1/30       10    P2P   1/1
Et0/0        1     0               10.1.1.1/24        10    DROTH 2/3

R1# show ip route 10.255.0.2
Routing entry for 10.255.0.2/32
  Known via "ospf 1", distance 110, metric 11, type intra area
  Last update from 10.1.1.2 on Ethernet0/0, 00:01:31 ago
  Routing Descriptor Blocks:
    10.1.1.2, from 2.2.2.2, 00:01:31 ago, via Ethernet0/0
      Route metric is 11, traffic share count is 1
  * 10.0.12.2, from 2.2.2.2, 00:02:11 ago, via Ethernet0/1
      Route metric is 11, traffic share count is 1

R1 with every adjacency repaired. Output captured on Cisco IOL (IOS XE 17.16) in Cisco Modeling Labs.

Frequently asked questions

Is an OSPF neighbor stuck in 2WAY a problem?

Not on a shared Ethernet segment. Routers that are neither DR nor BDR stay in 2WAY with each other and form full adjacencies only with the DR and BDR. 2WAY is a problem only where no DR can be elected, for example when every router on the segment has priority 0.

Why does an OSPF neighbor take up to 40 seconds to disappear after a mismatch?

A router removes a neighbor when its dead timer expires, and the default dead interval on Ethernet is 40 seconds. Changing how OSPF runs on an interface, such as making it passive, drops the adjacency at once on the router you changed, but the other router still waits for its dead timer. Timer, authentication and ACL faults only stop hellos from being accepted, so both routers take up to the full dead interval.

Does the OSPF process ID have to match on both routers?

No. The process ID is local to each router and is not carried in OSPF packets, so one router can run process 1 while its neighbor runs process 10. The area ID, the timers, authentication and the other hello values are what must match.

Can I use ip ospf mtu-ignore instead of fixing the MTU?

As a stopgap, yes. On IOS XE 17.16 it brought the adjacency to FULL with one end at 1400 bytes and the other at 1500. It only skips the check during the database exchange, and the MTUs still differ, so set them to match when you can.

Why does the same neighbor ID appear twice in show ip ospf neighbor?

Each line is one adjacency on one interface. Two routers joined by two links, such as a direct link and a shared segment, are neighbors twice under the same router ID. The Address and Interface columns tell the two apart.

Fix an adjacency on a graded lab

Repair a broken adjacency on real Cisco IOS in CML, then upload the config for a grade.

All CCNA troubleshooting labs →

What grading looks like

This is what grading your config looks like

A sample result — 4 of 5 requirements met. This is exactly what you see the moment you submit.

ospf-lab-export.yaml — read 3 device configs

Passed: OSPF process 1 enabled on R1
Passed: Area 0 configured on Gi0/0
Passed: R2 advertises 10.0.12.0/30
Passed: Adjacency R1 to R2 reaches FULL
Failed: default-information originate — missing on R3

Solution revealed

The full node-by-node answer key unlocks the moment you submit — so you see exactly what you missed.

Don't just read it — configure it

Reading is step one. Build OSPF on real Cisco IOS and have your own config graded.

Create a free account OSPF: Adjacency to Multi-Area Mastery labs