Troubleshooting OSPF Neighbor Adjacency

OSPF is one of the most widely deployed interior routing protocols in enterprise networks — and OSPF neighbour adjacency failures are among the most frequently encountered and most time-consuming faults to diagnose without a systematic approach. When OSPF neighbours refuse to form, routes disappear from the routing table, traffic is black-holed, and the failure is completely invisible at Layer 1 and 2 — the physical link is up, frames are forwarding, yet no routing information is exchanged. The cause is almost always one of a small set of well-defined parameter mismatches: OSPF validates five fields in every Hello packet and rejects the Hello silently if any of them do not match. An additional sixth parameter — MTU — blocks database exchange at the EXSTART state, allowing the neighbour to reach EXSTART but never FULL.

The three primary diagnostic commands are show ip ospf neighbor (neighbour state and dead timer), show ip ospf interface [name] (all per-interface OSPF parameters in one output), and debug ip ospf events (live Hello processing — shows exactly which field caused a rejection). Together these three commands diagnose every common OSPF adjacency failure without requiring packet captures or external tools.

This guide assumes Layers 1, 2, and 3 are confirmed healthy — the physical link is up/up, the interfaces have correctly configured IP addresses on the same subnet, and basic IP reachability between the two router interfaces exists. Verify those first using Troubleshooting Layer 1, Troubleshooting Layer 2, and Troubleshooting Layer 3. For OSPF configuration from scratch see OSPF Single-Area Configuration and OSPF Multi-Area Configuration.

1. OSPF Neighbour Formation — Core Concepts

The OSPF Neighbour State Machine

OSPF neighbours progress through a defined sequence of states from DOWN to FULL. The state at which a neighbour stalls immediately identifies which class of fault is responsible — making the state machine the primary diagnostic tool even before running any commands:

  DOWN ──► INIT ──► 2WAY ──► EXSTART ──► EXCHANGE ──► LOADING ──► FULL

  DOWN      No Hellos received at all
            Cause: interface not in OSPF process, wrong network statement,
                   ACL blocking multicast 224.0.0.5, passive interface

  INIT      Hellos received from peer but router's own RID not seen
            in peer's neighbour list
            Cause: unidirectional communication — ACL blocking in one
                   direction, Layer 2 asymmetric fault

  2WAY      Bidirectional Hello exchange confirmed — both see each other
            Normal FINAL state for DROTHERs on broadcast networks
            (not a fault if both are DROTHER on multi-access)

  EXSTART   Master/slave election for DBD exchange begun
  EXCHANGE  DBD packets being exchanged — full topology summary
            Stuck here: MTU mismatch — one side's DBD packets exceed
                        peer's MTU and are silently dropped

  LOADING   LSR/LSU exchange to fill in missing LSAs
            Stuck here rarely — usually a corrupted LSA or retransmit loop

  FULL      Databases synchronised — all LSAs exchanged
            Desired end state:
              Point-to-point links:   FULL/  -
              Broadcast (DR):         FULL/DR
              Broadcast (BDR):        FULL/BDR
              Broadcast (DROTHER):    2WAY/DROTHER  ← correct, not a fault

The Six OSPF Hello Validation Fields

Before forming a neighbour relationship, OSPF validates every incoming Hello against the local interface configuration. A mismatch in any of the first five fields causes the Hello to be silently dropped — no error message is generated, the neighbour simply never appears. The sixth (MTU) does not affect Hello processing but blocks DBD exchange:

#	Parameter	Must Match?	State Where Failure Shows	How to Check
1	Area ID	Yes — both interfaces on same link must be in identical area	Stuck at DOWN / never reaches INIT	`show ip ospf interface [int]` — Area field
2	Hello / Dead timers	Yes — both must be identical on each end	Neighbour forms then drops (flapping) if dead timer > 4× peer hello	`show ip ospf interface [int]` — Timer intervals line
3	Authentication	Yes — type (none/plain/MD5) and key must match	Stuck at DOWN — Hellos discarded before processing	`show ip ospf interface [int]` — Simple password / MD5
4	Stub area flag	Yes — both must agree on stub / not-stub / NSSA	Stuck at DOWN	`show ip ospf` — Area type listing
5	Network type (subnet)	Subnet must be same — /30 both sides, etc. Network type (broadcast vs P2P) mismatch causes FULL but no routes exchanged	Reaches FULL but routes missing or DR election fails	`show ip ospf interface [int]` — Network Type field
6	MTU	Yes during DBD exchange — mismatch causes DBD drops	Stuck at EXSTART / EXCHANGE	`show interfaces [int]` — MTU line; `show ip ospf interface [int]`

OSPF Network Types and DR/BDR Election

The OSPF network type configured on an interface determines whether DR/BDR election occurs and how many Hello packets are needed. A mismatch in network type between two routers on the same link is a subtle fault — the neighbour may reach FULL but route exchange is broken or unreliable:

Network Type	IOS Default On	DR/BDR Election	Hello / Dead	Multicast Used
broadcast	Ethernet (GigabitEthernet, FastEthernet)	Yes	10 / 40 sec	224.0.0.5 (all OSPF), 224.0.0.6 (DR/BDR)
point-to-point	Serial (HDLC, PPP), GRE tunnels	No	10 / 40 sec	224.0.0.5
non-broadcast (NBMA)	Frame Relay (multipoint), ATM	Yes	30 / 120 sec	Unicast only — neighbours must be manually configured
point-to-multipoint	Frame Relay (hub-and-spoke)	No	30 / 120 sec	224.0.0.5
point-to-multipoint non-broadcast	Manual override only	No	30 / 120 sec	Unicast only
loopback	Loopback interfaces	No	—	Advertised as /32 regardless of configured mask

Key diagnostic habit: Before checking any OSPF parameter, always verify basic IP connectivity first — run ping [peer-interface-ip] from the local router. If the ping fails, the OSPF issue is masking a Layer 3 problem (wrong subnet mask, no route, ACL). Check show ip route to confirm routing is in place before investigating OSPF. OSPF cannot form a neighbour relationship if basic IP reachability between the two interface addresses is broken. A successful ping confirms Layers 1–3 are healthy and the OSPF investigation can begin.

2. Lab Topology & Scenarios

This lab covers six OSPF adjacency fault scenarios across a three-router topology. All routers run OSPF process 1. Each scenario is independent and begins with the show ip ospf neighbor output showing the fault:

                    10.0.12.0/30                    10.0.23.0/30
  NetsTuts_R1 ──────────────────── NetsTuts_R2 ──────────────────── NetsTuts_R3
  Gi0/0: 10.0.12.1/30             Gi0/0: 10.0.12.2/30             Gi0/0: 10.0.23.6/30
  RID: 1.1.1.1                    Gi0/1: 10.0.23.5/30             RID: 3.3.3.3
                                  RID: 2.2.2.2

  Loopback interfaces (for stable Router IDs):
    R1 Lo0: 1.1.1.1/32      R2 Lo0: 2.2.2.2/32      R3 Lo0: 3.3.3.3/32

  Stub networks:
    R1: 192.168.10.0/24      R2: 192.168.20.0/24      R3: 192.168.30.0/24

  Design intent:
    All three routers in OSPF area 0 (backbone)
    R1–R2 link: Gi0/0 both sides (Ethernet — broadcast network type)
    R2–R3 link: Gi0/1 / Gi0/0 (Ethernet — broadcast network type)

  Fault Scenarios:
    Scenario 1 — R1–R2 neighbour absent (area mismatch: R1=area 0, R2=area 1)
    Scenario 2 — R1–R2 neighbour flapping every 40 s (hello timer mismatch)
    Scenario 3 — R2–R3 neighbour stuck at EXSTART (MTU mismatch)
    Scenario 4 — R1–R2 neighbour absent (authentication mismatch)
    Scenario 5 — R2–R3 neighbour stuck at 2WAY with no FULL (network type mismatch)
    Scenario 6 — R1 sees no neighbour at all (passive interface / wrong network statement)

Scenario	Link	show ip ospf neighbor State	Root Cause
1	R1–R2	Empty — no neighbour entry	Area ID mismatch (R1: area 0, R2: area 1 on same link)
2	R1–R2	FULL then DOWN every 40 s	Hello timer mismatch (R1: 10 s, R2: 20 s — dead timer expires)
3	R2–R3	EXSTART — never advances	MTU mismatch (R2: 1500, R3: 1476 — DBD packets dropped)
4	R1–R2	Empty — no neighbour entry	Authentication mismatch (R1: MD5, R2: no auth)
5	R2–R3	FULL/DR and FULL/BDR but routes missing	Network type mismatch (R2: broadcast, R3: point-to-point)
6	R1–R2	Empty — no neighbour entry	R1's Gi0/0 is passive-interface — OSPF Hellos suppressed

3. Scenario 1 — Area ID Mismatch

R1 and R2 are directly connected on Gi0/0 with IPs on the 10.0.12.0/30 subnet. Both routers are running OSPF process 1. show ip ospf neighbor is empty on both routers. Layer 1 and 2 are healthy — the ping between 10.0.12.1 and 10.0.12.2 succeeds.

Step 1 — Confirm No Neighbour and Verify Basic Reachability

NetsTuts_R1#show ip ospf neighbor
! ── Empty output ──────────────────────────────────────────────────

NetsTuts_R1#ping 10.0.12.2
Sending 5, 100-byte ICMP Echos to 10.0.12.2:
!!!!!
Success rate is 100 percent (5/5)

The ping succeeds — Layers 1, 2, and 3 are healthy. The fault is entirely within OSPF. An empty neighbour table with confirmed IP reachability narrows the investigation to the five Hello validation fields. The fact that the neighbour never appears at all (not even in INIT) tells us the Hello packets are being received but are failing the validation check — or Hellos are not being sent at all. The first field to check is always area ID.

Step 2 — Compare Area IDs with show ip ospf interface

NetsTuts_R1#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Neighbor Count is 0, Adjacent neighbor count is 0

NetsTuts_R2#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.2/30, Area 1, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:07
  Neighbor Count is 0, Adjacent neighbor count is 0

The area mismatch is immediately visible in the second line of output from each router — R1's Gi0/0 is in Area 0 and R2's Gi0/0 is in Area 1. When R2 sends a Hello with area ID 1, R1 receives it, checks the area field, finds it does not match its own area 0 on that interface, and silently discards the Hello. R2 similarly discards R1's Hellos. Neither router records an error — the Hello is simply dropped at the validation step, and the neighbour never appears in the table.

Step 3 — Confirm with debug ip ospf events

NetsTuts_R1#debug ip ospf events
OSPF events debugging is on

OSPF: Rcv hello from 2.2.2.2 area 1 on GigabitEthernet0/0 from 10.0.12.2
OSPF: Mismatched hello parameters from 10.0.12.2
OSPF: Dead R 40 C 40, Hello R 10 C 10  Mask R 255.255.255.252 C 255.255.255.252
OSPF:   area mismatch: my area 0 peer area 1

NetsTuts_R1#undebug all

debug ip ospf events is the definitive tool for Hello parameter failures — it shows exactly which field caused the rejection. The line

area mismatch: my area 0 peer
    area 1

pinpoints the fault without any ambiguity. The debug also shows that the Hello timer (10/10), Dead timer (40/40), and subnet mask (255.255.255.252) all match — only the area is wrong. This isolates the fix to a single parameter. Always run undebug all immediately after capturing the needed output.

Step 4 — Fix the Area Mismatch

! ── Decision: both ends of the R1–R2 link must be in the same area
! ── Design intent is area 0 — fix R2's network statement ─────────
NetsTuts_R2(config)#router ospf 1
NetsTuts_R2(config-router)#no network 10.0.12.0 0.0.0.3 area 1
NetsTuts_R2(config-router)#network 10.0.12.0 0.0.0.3 area 0
NetsTuts_R2(config-router)#exit

! ── Verify neighbour forms ────────────────────────────────────────
NetsTuts_R2#show ip ospf neighbor

Neighbor ID  Pri  State     Dead Time  Address     Interface
1.1.1.1       1  FULL/BDR  00:00:37   10.0.12.1   GigabitEthernet0/0

The neighbour forms immediately after the area is corrected — FULL/BDR on R2 (R1 won DR election as it was already in DR state from the earlier election). The Dead Time counter of 00:00:37 is healthy — it will reset to 40 seconds every time a Hello is received (every 10 seconds), confirming timers are aligned. Note that area changes take effect immediately in IOS — the OSPF process does not need to be reset or the interface bounced.

Area Mismatch — Common Causes and Prevention

Scenario	Likely Cause	Prevention
Two area 0 routers with link in area 1	Copy-paste error — wrong area number in network statement for that link	Always verify with `show ip ospf interface` after any OSPF config change
ABR with wrong area on one interface	Area boundary router misconfigured — one side area 0, other side wrong area number	Document the area topology and cross-check each interface area assignment
New router added with area 0 but existing is non-backbone	New device assumed all OSPF is area 0 — not true in multi-area deployments	Check the existing router's area before configuring the new one

4. Scenario 2 — Hello / Dead Timer Mismatch

R1 and R2 form a neighbour relationship briefly but it drops every 40 seconds and immediately re-forms. The syslog shows alternating %OSPF-5-ADJCHG: FULL to DOWN and DOWN to FULL messages at a precise 40-second interval. This is called OSPF flapping.

Step 1 — Observe the Flapping Pattern

NetsTuts_R1#show logging | include OSPF
Mar  7 20:10:00: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from LOADING to FULL
Mar  7 20:10:40: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from FULL to DOWN
Mar  7 20:10:41: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from LOADING to FULL
Mar  7 20:11:21: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Gi0/0 from FULL to DOWN

The neighbour drops to DOWN exactly 40 seconds after forming, then immediately re-forms. The 40-second interval is the OSPF dead timer — when the dead timer expires without receiving a Hello from the peer, OSPF declares the neighbour dead. The immediate re-formation means Hellos are eventually arriving — just not frequently enough to prevent the dead timer from expiring. This is the classic hello/dead timer mismatch signature: one side sends Hellos at a rate slower than the other side's dead timer can tolerate. Use Syslog and show logging to capture the ADJCHG messages persistently.

Step 2 — Compare Timers on Both Interfaces

NetsTuts_R1#show ip ospf interface GigabitEthernet0/0
  ...
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Hello due in 00:00:03

NetsTuts_R2#show ip ospf interface GigabitEthernet0/0
  ...
  Timer intervals configured, Hello 20, Dead 80, Wait 80, Retransmit 5
  Hello due in 00:00:18

The mismatch is clear — R1 sends Hello every 10 seconds with a dead timer of 40 seconds. R2 sends Hello every 20 seconds with a dead timer of 80 seconds. When R2 sends a Hello at T=0 and the next at T=20, R1's dead timer (40 s) expires at T=40 before R2's second Hello arrives — R1 declares R2 dead and tears down the adjacency. R2 then receives R1's Hello (still arriving every 10 s), sees R1 as a new peer, and begins the DORA process again. The neighbour re-forms in about one second, then drops again 40 seconds later — indefinitely.

Step 3 — Fix the Timer Mismatch

! ── Option A: Correct R2 to match R1's defaults (10/40) ──────────
NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#ip ospf hello-interval 10
NetsTuts_R2(config-if)#ip ospf dead-interval 40
NetsTuts_R2(config-if)#exit

! ── Option B: Remove custom timers and restore IOS defaults ───────
NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#no ip ospf hello-interval
NetsTuts_R2(config-if)#no ip ospf dead-interval
NetsTuts_R2(config-if)#exit

! ── Option C: Use fast OSPF timers (sub-second) on BOTH sides ─────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ip ospf dead-interval minimal hello-multiplier 5
!  ── Dead interval = 1 second, Hello every 200 ms (5 per second)

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#ip ospf dead-interval minimal hello-multiplier 5
NetsTuts_R2(config-if)#exit

! ── Verify stable adjacency ───────────────────────────────────────
NetsTuts_R1#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
2.2.2.2       1  FULL/BDR  00:00:36   10.0.12.2   GigabitEthernet0/0

! ── Dead Time should reset every 10 s (from 40 s) — never reach 0

Option B is the cleanest fix in most cases — removing the custom timers returns both interfaces to the IOS default of Hello 10, Dead 40. The dead timer in the neighbour table should now visibly reset every ~10 seconds when Hellos are received, never approaching zero. Option C (fast hellos) dramatically reduces convergence time but requires BFD (Bidirectional Forwarding Detection) awareness and should only be used where sub-second failover is required. Most importantly, whatever timer values are chosen, they must be identical on both ends of the link.

Timer Mismatch Impact at Different Hello Intervals

R1 Hello / Dead	R2 Hello / Dead	Result	Drop Interval
10 / 40	10 / 40	Stable — 4 Hellos per dead interval	Never drops
10 / 40	20 / 80	Flapping — R1's dead timer (40 s) expires before R2's Hello (20 s) arrives twice	Every 40 s
10 / 40	30 / 120	Flapping — R1's dead timer expires well before R2's second Hello	Every 40 s
30 / 120	30 / 120	Stable — NBMA defaults, 4 Hellos per dead interval	Never drops
10 / 40	10 / 60	Stable — Hellos arrive every 10 s, dead timer (40 s) never expires on either side	Never drops (but non-standard — not recommended)

5. Scenario 3 — MTU Mismatch (Stuck at EXSTART)

R2 and R3 are connected via Gi0/1 and Gi0/0 respectively. Hellos are exchanging successfully — the neighbour appears in show ip ospf neighbor — but the state is stuck at EXSTART for several minutes without progressing to EXCHANGE. No routes are being learned.

Step 1 — Observe the Stuck State

NetsTuts_R2#show ip ospf neighbor

Neighbor ID  Pri  State      Dead Time  Address     Interface
3.3.3.3       1  EXSTART/DR  00:00:37   10.0.23.6   GigabitEthernet0/1

! ── State has been EXSTART for over 3 minutes ─────────────────────
! ── Dead Time still counting down and resetting — Hellos ARE flowing
! ── But state never advances to EXCHANGE ─────────────────────────

EXSTART is the first stage of the database exchange where the two routers elect a master/slave relationship and begin exchanging Database Description (DBD) packets. The fact that the neighbour is visible (Hellos are flowing — Dead Time is resetting) but stuck at EXSTART before advancing to EXCHANGE is the classic MTU mismatch signature. The higher-MTU router sends DBD packets that exceed the peer's interface MTU — the peer silently drops them and keeps retransmitting its own DBD, creating a stalemate.

Step 2 — Check MTU on Both Interfaces

NetsTuts_R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is ISR4321-2x1GE, address is 0c1a.2b3c.0201
  Internet address is 10.0.23.5/30
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec

NetsTuts_R3#show interfaces GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Hardware is ISR4321-2x1GE, address is 0c1a.2b3c.0301
  Internet address is 10.0.23.6/30
  MTU 1476 bytes, BW 1000000 Kbit/sec, DLY 10 usec

R2's Gi0/1 has MTU 1500 (the standard Ethernet default). R3's Gi0/0 has MTU 1476 — a non-standard value, possibly set for a GRE tunnel overlay or incorrectly inherited from a template. When R2 sends a DBD packet, it may use up to 1500 bytes. R3 receives this packet and, because its interface MTU is 1476, cannot process packets larger than 1476 bytes — the oversized DBD is silently dropped. R3 never acknowledges the DBD, R2 retransmits, and the exchange never completes.

Step 3 — Confirm with debug ip ospf events

NetsTuts_R2#debug ip ospf events
OSPF events debugging is on

OSPF: Rcv DBD from 3.3.3.3 on GigabitEthernet0/1  seq 0x1A2B opt 0x52 flag 0x7 len 32
OSPF: First DBD and we are not SLAVE
OSPF: Retransmitting DBD to 3.3.3.3 on GigabitEthernet0/1
OSPF: Retransmitting DBD to 3.3.3.3 on GigabitEthernet0/1
OSPF: Retransmitting DBD to 3.3.3.3 on GigabitEthernet0/1
! ── Continuous retransmission — DBD exchange never completes ──────

NetsTuts_R2#undebug all

The continuous DBD retransmission without any acknowledgement is the EXSTART deadlock pattern caused by MTU mismatch. The master router (R2 here) keeps retransmitting its initial DBD — the slave (R3) never acknowledges because R2's DBD is oversized for R3's MTU. Both sides eventually give up, the neighbour drops, and the process restarts — creating a perpetual EXSTART loop.

Step 4 — Fix: Align MTUs or Use mtu-ignore

! ── Fix A: Align the MTU on R3 to match R2 ───────────────────────
NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#ip mtu 1500
NetsTuts_R3(config-if)#exit

! ── Fix B (workaround): Ignore MTU during DBD exchange ───────────
! ── Apply on BOTH interfaces for symmetry ─────────────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#ip ospf mtu-ignore
NetsTuts_R2(config-if)#exit
NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#ip ospf mtu-ignore
NetsTuts_R3(config-if)#exit

! ── Note: ip ospf mtu-ignore does NOT change the actual MTU ──────
! ── It only tells OSPF to skip MTU validation during DBD exchange.
! ── Packets larger than the smaller MTU may still be fragmented.
! ── Fix A (aligning actual MTU) is always preferable.

! ── Verify adjacency advances past EXSTART ───────────────────────
NetsTuts_R2#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
3.3.3.3       1  FULL/DR   00:00:38   10.0.23.6   GigabitEthernet0/1

After aligning the IP MTU, the EXSTART deadlock resolves and the adjacency advances through EXCHANGE and LOADING to FULL within seconds. Fix A (aligning actual MTU) is strongly preferred — ip ospf mtu-ignore masks the problem but does not prevent larger packets from being fragmented or dropped at Layer 2, which can cause other performance issues. Use ip ospf mtu-ignore only as a temporary workaround when you cannot immediately change the MTU (e.g., during a change freeze window) and document it for follow-up.

Common Causes of MTU Mismatch on OSPF Links

Cause	Typical MTU Values	Fix
GRE tunnel overlay changing underlay MTU	Physical: 1500 / Tunnel-facing: 1476 (1500 - 24 byte GRE header)	Set `ip mtu 1476` on both physical interfaces or `ip ospf mtu-ignore`
PPPoE WAN link reducing MTU	LAN: 1500 / PPPoE WAN: 1492 (1500 - 8 byte PPPoE header)	Set `ip mtu 1492` on the WAN-facing interface
Jumbo frames on one side only	One side: 9000 (jumbo) / Other: 1500 (standard)	Align both interfaces to the same MTU — lower to 1500 if jumbo not supported end-to-end
Misconfigured ip mtu command	Any non-standard value set by accident or from a template	`no ip mtu` to restore default, or set explicitly to 1500

6. Scenario 4 — Authentication Mismatch

R1 was recently hardened — OSPF MD5 authentication was enabled on all its interfaces as part of a security policy. After the change, the R1–R2 neighbour disappeared and has not re-formed. R2 has not yet been updated with the authentication configuration.

Step 1 — Confirm Neighbour is Absent

NetsTuts_R1#show ip ospf neighbor
! ── Empty ─────────────────────────────────────────────────────────

NetsTuts_R1#ping 10.0.12.2
!!!!!
! ── IP reachability still works — fault is OSPF-specific ─────────

Step 2 — Check Authentication Configuration

NetsTuts_R1#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40
  Simple password authentication enabled             ← Auth type shown
  ! ── or: Message digest authentication enabled ───────────────────

NetsTuts_R2#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.2/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40
  ! ── No authentication line — R2 has no OSPF auth configured ─────

R1's interface shows

Simple password authentication
    enabled

(or MD5 if key chain is used), while R2's interface has no authentication line — authentication is disabled. OSPF authentication validation happens before all other Hello field checks — if authentication fails, the Hello is discarded immediately and the sender does not receive any error notification. The neighbour never reaches INIT state.

Step 3 — Confirm with debug ip ospf events

NetsTuts_R1#debug ip ospf events
OSPF: Rcv pkt from 10.0.12.2, GigabitEthernet0/0 :
      Mismatch Authentication type. Input packet specified type 0,
      we use type 2
! ── Type 0 = no auth (R2), Type 2 = MD5 (R1) ────────────────────

NetsTuts_R2#debug ip ospf events
OSPF: Rcv pkt from 10.0.12.1, GigabitEthernet0/0 :
      Mismatch Authentication Key - No key configured but pkt has
      a key, or there is key mismatch

NetsTuts_R1#undebug all
NetsTuts_R2#undebug all

The debug output is explicit — R1 receives a Hello from R2 with authentication type 0 (none) but R1 is configured for type 2 (MD5). R2 receives a Hello from R1 with an MD5 key but has no key configured. Both sides reject the other's Hellos — the neighbour cannot form. The fix is to configure matching authentication on R2.

Step 4 — Fix the Authentication Mismatch

! ── Check what R1 is using ────────────────────────────────────────
NetsTuts_R1#show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 NetsTuts@OSPF
 ip ospf hello-interval 10

! ── Configure matching auth on R2 ─────────────────────────────────
NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#ip ospf authentication message-digest
NetsTuts_R2(config-if)#ip ospf message-digest-key 1 md5 NetsTuts@OSPF
NetsTuts_R2(config-if)#exit

! ── Verify neighbour forms ────────────────────────────────────────
NetsTuts_R1#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
2.2.2.2       1  FULL/BDR  00:00:38   10.0.12.2   GigabitEthernet0/0

The key ID (1), authentication type (MD5), and key string (NetsTuts@OSPF) must all match on both interfaces. A mismatch in the key ID alone (e.g., R1 uses key ID 1, R2 uses key ID 2) also causes authentication failure even if the key string is the same — OSPF uses the key ID to select which key to validate against. The adjacency forms immediately after matching authentication is configured on R2.

OSPF Authentication Types — Summary

Type	IOS Command (Interface)	Security	Notes
Type 0 — None	`no ip ospf authentication` (default)	None — Hellos are unauthenticated	Default — fine for lab, not recommended for production
Type 1 — Plain text	`ip ospf authentication` + `ip ospf authentication-key [key]`	Low — key visible in plain text in packet captures	Prevents accidental neighbour formation — not secure against captures
Type 2 — MD5	`ip ospf authentication message-digest` + `ip ospf message-digest-key [id] md5 [key]`	Medium — key is MD5-hashed in the packet	Recommended for production — prevents rogue router injection

7. Scenario 5 — Network Type Mismatch

R2 and R3 have a stable OSPF neighbour relationship — both show FULL state in show ip ospf neighbor. However, routes learned from R3 are not appearing in R2's routing table, and vice versa. The link is an Ethernet point-to-point connection between two routers (no switches, no other OSPF routers on this segment).

Step 1 — Check Neighbour State and DR/BDR Roles

NetsTuts_R2#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
3.3.3.3       1  FULL/DR   00:00:37   10.0.23.6   GigabitEthernet0/1

NetsTuts_R3#show ip ospf neighbor
Neighbor ID  Pri  State       Dead Time  Address     Interface
2.2.2.2       0  FULL/DROTHER 00:00:35  10.0.23.5   GigabitEthernet0/0

Something is wrong — R2 sees R3 as DR, while R3 sees R2 as DROTHER with priority 0. On a two-router point-to-point link, DR/BDR election should not occur at all. The presence of DR/DROTHER roles indicates one router is treating the link as a broadcast network type while the other is treating it as something different. A network type mismatch can produce FULL state between the two routers, but the inconsistent DR roles cause route advertisement to fail — each router expects the other to behave according to a different set of OSPF rules for that link type.

Step 2 — Check Network Types on Both Interfaces

NetsTuts_R2#show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.0.23.5/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State BDR, Priority 1
  Timer intervals configured, Hello 10, Dead 40

NetsTuts_R3#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.23.6/30, Area 0
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40
  Neighbor Count is 1, Adjacent neighbor count is 1

R2 is using BROADCAST network type (the default for Ethernet) while R3 has been manually set to POINT_TO_POINT. A point-to-point router does not participate in DR/BDR election and sends Hellos to the 224.0.0.5 multicast (all OSPF routers). A broadcast router participates in DR/BDR election and sends updates only to the DR/BDR. With this mismatch, the two routers form an adjacency (because Hellos are still exchanged and area/timer parameters match) but LSA flooding breaks down — each uses different multicast addresses and DR/BDR assumptions for sending updates.

Step 3 — Fix the Network Type

! ── For a two-router Ethernet P2P link, point-to-point is preferred
! ── (no DR/BDR election, faster convergence) ──────────────────────
! ── Set BOTH interfaces to the same network type ─────────────────

NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#ip ospf network point-to-point
NetsTuts_R2(config-if)#exit

! ── Verify both are now point-to-point ───────────────────────────
NetsTuts_R2#show ip ospf interface GigabitEthernet0/1
  ...
  Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  ...
  Neighbor Count is 1, Adjacent neighbor count is 1

NetsTuts_R2#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
3.3.3.3       0  FULL/  -  00:00:39   10.0.23.6   GigabitEthernet0/1

NetsTuts_R2#show ip route ospf
O     192.168.30.0/24 [110/2] via 10.0.23.6, 00:00:14, GigabitEthernet0/1

After setting R2 to point-to-point, both routers now agree on the network type. The neighbour shows FULL/ - (the dash indicates no DR/BDR — correct for P2P), and OSPF routes from R3 immediately appear in R2's routing table. Using ip ospf network point-to-point on Ethernet links between exactly two routers is a best practice — it eliminates the DR/BDR election overhead and speeds up convergence. If there are more than two OSPF routers on the same Ethernet segment (e.g., a shared LAN), broadcast mode with DR/BDR is required.

Network Type Mismatch Outcomes

Router A Type	Router B Type	Neighbour Forms?	Routes Exchanged?	Symptom
broadcast	broadcast	Yes	Yes	Normal — DR/BDR election occurs
point-to-point	point-to-point	Yes	Yes	Normal — no DR/BDR, FULL/-
broadcast	point-to-point	Yes — reaches FULL	Partial / broken	Routes may be missing — inconsistent DR roles, LSA flooding unreliable
broadcast	non-broadcast	Maybe — timers differ (10/40 vs 30/120)	No	Timer mismatch also present — neighbour flaps or never forms

8. Scenario 6 — Passive Interface / Wrong Network Statement

R1 has no OSPF neighbours at all after initial configuration — not even on the R1–R2 link. R2 shows no neighbour for R1 either. The OSPF process is running on R1. The ping between 10.0.12.1 and 10.0.12.2 succeeds.

Step 1 — Check OSPF Process and Network Statements

NetsTuts_R1#show ip ospf
 Routing Process "ospf 1" with ID 1.1.1.1
 Start time: 00:12:44.221, Time elapsed: 00:45:12.009
 Supports only single TOS(TOS0) routes
 ...
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
    Area BACKBONE(0)
        Number of interfaces in this area is 2
        ...
        Active interfaces: GigabitEthernet0/1
        Passive interfaces: GigabitEthernet0/0

The show ip ospf command reveals the problem immediately — Gi0/0 (the R1–R2 link) is listed as a Passive interface. A passive OSPF interface does not send or receive OSPF Hello packets — it is advertised into OSPF as a connected network but participates in no neighbour relationships. This is intentional for stub networks facing end hosts (to prevent hosts from becoming OSPF neighbours) but disastrous if accidentally applied to a router-to-router link.

Step 2 — Find the Passive Interface Configuration

NetsTuts_R1#show running-config | section router ospf
router ospf 1
 passive-interface GigabitEthernet0/0
 network 10.0.12.0 0.0.0.3 area 0
 network 192.168.10.0 0.0.0.255 area 0

The explicit passive-interface GigabitEthernet0/0 command is suppressing all OSPF Hello packets on the R1–R2 link. This was likely a copy-paste or template error — the passive-interface command was intended for Gi0/1 (the stub network facing end hosts), not Gi0/0 (the inter-router link). The network statement correctly covers the 10.0.12.0/30 subnet — the only problem is the passive-interface.

Step 3 — Check for Wrong Network Statement (Secondary Cause)

! ── Alternative: What if passive-interface is not the issue? ──────
! ── Check if network statement covers the interface IP ───────────
NetsTuts_R1#show ip ospf interface GigabitEthernet0/0
%OSPF: OSPF not enabled on GigabitEthernet0/0
! ── Interface is not in any OSPF network statement ───────────────

! ── Check what network statement is configured ───────────────────
NetsTuts_R1#show running-config | section router ospf
router ospf 1
 network 10.0.13.0 0.0.0.3 area 0
!           ^^^^^^ Wrong — should be 10.0.12.0 not 10.0.13.0 ──────
 network 192.168.10.0 0.0.0.255 area 0

! ── 10.0.12.1 (Gi0/0 address) is NOT covered by 10.0.13.0/30 ────
! ── OSPF is not enabled on Gi0/0 at all ──────────────────────────

If show ip ospf interface [int] returns %OSPF: OSPF not enabled on [interface], the interface's IP address is not matched by any OSPF network statement — OSPF is completely absent from that interface. A one-digit typo in the network statement (10.0.13.0 instead of 10.0.12.0) causes the interface to be silently excluded from OSPF. No error is generated — OSPF simply ignores the interface.

Step 4 — Fix Both Issues

! ── Fix A: Remove passive-interface from the router link ─────────
NetsTuts_R1(config)#router ospf 1
NetsTuts_R1(config-router)#no passive-interface GigabitEthernet0/0
NetsTuts_R1(config-router)#exit

! ── Fix B: Correct the wrong network statement ────────────────────
NetsTuts_R1(config)#router ospf 1
NetsTuts_R1(config-router)#no network 10.0.13.0 0.0.0.3 area 0
NetsTuts_R1(config-router)#network 10.0.12.0 0.0.0.3 area 0
NetsTuts_R1(config-router)#exit

! ── Verify OSPF is now enabled on Gi0/0 ─────────────────────────
NetsTuts_R1#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.1/30, Area 0, Attached via Network Statement
  ...
  Neighbor Count is 1, Adjacent neighbor count is 1

NetsTuts_R1#show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
2.2.2.2       1  FULL/BDR  00:00:37   10.0.12.2   GigabitEthernet0/0

After removing the passive-interface and/or correcting the network statement, OSPF Hellos begin flowing immediately and the neighbour forms within one Hello interval (10 seconds by default). Best practice: use passive-interface default to make all interfaces passive, then use no passive-interface [int] explicitly for each router-to-router link. This approach is fail-safe — new interfaces default to passive and never accidentally become OSPF-speaking toward end hosts.

Passive Interface — Correct vs Incorrect Usage

Interface Type	Passive-Interface?	Reason
Router-to-router link (inter-router)	❌ No — must not be passive	OSPF Hellos must flow between routers to form adjacency
Stub LAN facing end hosts only	✅ Yes — should be passive	Prevents unnecessary Hellos on user-facing segments; the network is still advertised into OSPF
Loopback interface	✅ Yes — passive by nature	Loopbacks cannot form adjacencies; marking passive is optional but consistent with best practice
WAN link to ISP (not running OSPF)	✅ Yes — passive if OSPF-enabled	Prevents OSPF Hellos being sent to ISP devices that do not understand them

9. Full Diagnostic Reference & Decision Tree

show ip ospf neighbor — Complete Field Guide

NetsTuts_R2#show ip ospf neighbor

Neighbor ID   Pri   State       Dead Time   Address       Interface
1.1.1.1        1   FULL/BDR    00:00:36    10.0.12.1     GigabitEthernet0/0  ← [1]
3.3.3.3        0   FULL/  -    00:00:38    10.0.23.6     GigabitEthernet0/1  ← [2]

! ── Field meanings ───────────────────────────────────────────────
! Neighbor ID  : OSPF Router ID of the peer (highest IP on loopback,
!                or highest interface IP if no loopback)
! Pri          : OSPF priority used for DR/BDR election on this link
!                0 = never eligible to be DR or BDR
! State        : Current neighbour state / DR role
!   FULL/BDR   [1] : Full adjacency; this router is the BDR on that link
!   FULL/  -   [2] : Full adjacency; point-to-point — no DR/BDR
!   FULL/DR        : Full adjacency; this router is the DR
!   2WAY/DROTHER   : 2-way only; neither router is DR/BDR (correct for DROTHERs)
!   EXSTART/DR     : Stuck in master/slave election — check MTU
!   INIT           : Hellos received but not bidirectional — check ACL
! Dead Time    : Countdown to declaring neighbour dead
!                Should reset every hello-interval seconds — never reach 0
!                If steadily counting down to 0 → Hello not arriving
! Address      : Source IP of peer's Hello packets (peer's interface IP)
! Interface    : Local interface on which the neighbour is seen

show ip ospf interface — The Primary Comparison Tool

NetsTuts_R2#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.12.2/30, Area 0              ← [A] Area ID
  Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2
  Network Type BROADCAST, Cost: 1                    ← [B] Network type
  Transmit Delay is 1 sec, State BDR, Priority 1     ← [C] DR/BDR state
  Designated Router (ID) 1.1.1.1, Interface address 10.0.12.1
  Backup Designated Router (ID) 2.2.2.2, Interface address 10.0.12.2
  Timer intervals configured, Hello 10, Dead 40      ← [D] Timers
    Wait 40, Retransmit 5
    Hello due in 00:00:08
  Supports Link-local Signaling (LLS)
  Message digest authentication enabled              ← [E] Auth type
    Youngest key id is 1
  Neighbor Count is 1, Adjacent neighbor count is 1  ← [F] Neighbour count

Marker	Field	What to Check	Must Match Peer?
[A]	Area	Area number — compare with peer's same field	Yes — must be identical
[B]	Network Type	BROADCAST / POINT_TO_POINT / NON_BROADCAST — compare with peer	Yes — mismatch causes route exchange failure even if FULL state reached
[C]	State / Priority	DR / BDR / DROTHER / POINT_TO_POINT — check for unexpected DR roles	No — but should be consistent with topology (P2P should show POINT_TO_POINT)
[D]	Hello / Dead	Hello interval and dead interval — compare with peer	Yes — must be identical on both ends
[E]	Authentication	None / Simple password / Message digest — compare with peer	Yes — type and key must match
[F]	Neighbour Count	Should be ≥ 1 if a neighbour is expected on this link	N/A — reflects current neighbour state

OSPF Adjacency Troubleshooting Decision Tree

Symptom	First Check	Key Finding	Fix
No neighbour — empty table, ping fails	`show ip interface brief` — interface status	Interface down/down or wrong subnet	Fix Layer 1/2/3 first — OSPF cannot run on a down interface
No neighbour — empty table, ping succeeds	`show ip ospf interface [int]` on both routers	Area, auth, or timer mismatch; or interface passive / not in OSPF	Compare [A][D][E] fields — correct the mismatched parameter
No neighbour — interface shows "OSPF not enabled"	`show run \| section router ospf`	Network statement does not cover interface IP, or wrong wildcard mask	Correct the `network` statement to include the interface IP
No neighbour — passive interface suspected	`show ip ospf` — passive interfaces section	Router-to-router interface listed as passive	`no passive-interface [int]` under router ospf
Neighbour stuck at INIT	`show ip access-lists` on both routers	ACL blocking 224.0.0.5 in one direction	Permit OSPF multicast (224.0.0.5) in both directions — see ACL Configuration
Neighbour flapping (forms then drops regularly)	`show ip ospf interface [int]` on both routers	Hello/dead timer mismatch — drop interval = dead timer of faster side	`ip ospf hello-interval` and `ip ospf dead-interval` — align both ends
Neighbour stuck at EXSTART	`show interfaces [int]` on both routers	MTU mismatch — different MTU values	Align IP MTU with `ip mtu [value]` or apply `ip ospf mtu-ignore` as workaround
Neighbour FULL but routes missing	`show ip ospf interface [int]` — Network Type field	Network type mismatch (broadcast vs point-to-point)	`ip ospf network [type]` — set same type on both ends
Neighbour FULL — specific routes absent	`show ip ospf database` — check LSA for missing network	Network not in OSPF process on originating router	Add correct `network` statement or use `redistribute connected`
Neighbour absent after security change	`debug ip ospf events` — auth mismatch messages	Authentication type or key mismatch	Match auth type, key ID, and key string on both interfaces

Key Points & Exam Tips

Always verify basic IP connectivity (ping [peer-ip]) before investigating OSPF — a Layer 1/2/3 fault masquerading as an OSPF issue wastes time. OSPF cannot form neighbours without bidirectional IP reachability.
The neighbour state identifies the fault class immediately: empty/DOWN = Hello not arriving or failing validation; INIT = one-directional only; EXSTART = MTU mismatch; FULL with no routes = network type mismatch or missing network statement.
OSPF validates five Hello fields before forming a neighbour: area ID, hello/dead timers, authentication, stub area flag, and subnet mask. A mismatch in any of these causes silent Hello rejection — no error message is generated.
show ip ospf interface [int] is the most important OSPF diagnostic command — run it on both ends of a failing link and compare area, network type, timers, and authentication type side by side.
debug ip ospf events shows exactly which field caused a Hello rejection with a clear message like area mismatch or Mismatch Authentication type. Always follow with undebug all immediately after capturing output. For persistent monitoring of neighbour state changes use SNMP traps on the %OSPF-5-ADJCHG event.
OSPF neighbour flapping at a precise interval equal to the dead timer is always a hello/dead timer mismatch — the slower router's Hello arrives after the faster router's dead timer expires.
A neighbour stuck at EXSTART with Hellos flowing normally is always an MTU mismatch until proven otherwise. Check show interfaces [int] MTU on both sides.
Network type mismatch (broadcast vs point-to-point) is subtle — the neighbour reaches FULL state but routes are not exchanged. Always check the Network Type field in show ip ospf interface when routes are missing despite FULL adjacency.
A passive-interface on a router-to-router link suppresses all OSPF Hellos — the neighbour never forms. Use show ip ospf to see which interfaces are passive. Use passive-interface default + no passive-interface per router link as a secure baseline.
On the CCNA/CCNP exam: know all seven neighbour states and what failure each state implies, the five Hello validation fields, the difference between EXSTART failure (MTU) and FULL-but-no-routes (network type), and the correct output of show ip ospf neighbor for each link type (FULL/-, FULL/DR, 2WAY/DROTHER).

Next Steps: With OSPF adjacency confirmed FULL, verify routes are being redistributed and summarised correctly — see OSPF Route Summarisation. For multi-area OSPF design and ABR/ASBR configuration see OSPF Multi-Area Configuration. For OSPF authentication configuration from scratch see OSPF Authentication. For Layer 3 routing issues that appear after OSPF is healthy see Troubleshooting Layer 3. For checking OSPF database completeness after adjacency is established see OSPF LSA Types.

TEST WHAT YOU LEARNED

1. `show ip ospf neighbor` on R1 shows R2 in `INIT` state. `show ip ospf neighbor` on R2 shows no entry for R1 at all. The ping from R1 to R2's interface IP succeeds. What does this asymmetric state pattern indicate and what is the most likely cause?

A. Area mismatch — R1 and R2 are in different OSPF areas. R2 discards R1's Hello before recording it B. MTU mismatch — R2 cannot process R1's Hello packets because they exceed the interface MTU C. Unidirectional communication — R1 is receiving R2's Hellos (hence INIT — R1 sees R2 but R2 has not yet seen R1's RID in a Hello), but R2 is not receiving R1's Hellos at all. The most likely cause is an ACL on R2 or an intermediate device blocking OSPF multicast (224.0.0.5) or unicast from R1's direction. A passive-interface on R2 would also cause this — R2 receives but does not send Hellos D. Timer mismatch — R1's Hello interval is faster than R2's dead timer, causing R2 to drop R1's neighbour entry

Correct answer is C. The OSPF INIT state has a precise meaning: the local router has received a Hello from the peer, but the local router's own Router ID has not yet appeared in the peer's neighbour list field (the Hello packet contains a list of all neighbours the sender has heard from). R1 is in INIT because it sees R2's Hellos but R2 has not yet acknowledged seeing R1's Hellos back. R2 has no entry at all for R1 — meaning R2 is not receiving R1's Hellos at all (not even INIT). This asymmetric pattern — one router at INIT, the other with no entry — is the hallmark of unidirectional communication failure. The forward path works (R1 receives R2's Hellos), but the reverse path is broken (R2 never receives R1's Hellos). An ACL blocking OSPF multicast 224.0.0.5 in one direction is the most common cause. A passive-interface on R2's connecting interface would also prevent it from sending Hellos (R1 would have no entry either in that case). Area mismatch (Option A) would cause both routers to discard the other's Hellos — neither would show any state.

2. Two routers share an Ethernet link. R1 has `ip ospf hello-interval 10` (default) and R2 has `ip ospf hello-interval 5` with `ip ospf dead-interval 20`. Both are in the same area with no authentication. Will the neighbour form, and will it be stable?

A. The neighbour will not form at all — hello interval mismatch prevents INIT state B. The neighbour will form but will flap every 40 seconds. R1's dead timer is 40 s (4 × hello of 10). R2 sends a Hello every 5 s — well within R1's 40 s dead timer, so R1's dead timer never expires for R2. But R1 sends a Hello every 10 s — and R2's dead timer is only 20 s. If R1 fails to send two consecutive Hellos (for any reason) before R2's 20 s dead timer expires, R2 declares R1 dead. Even without packet loss, the mismatch creates fragility. Fix: align both timers to the same values on both interfaces C. The neighbour will form and be perfectly stable — only the dead timer must match, not the hello interval D. The neighbour will not form — OSPF requires dead interval to be exactly 4× the hello interval

Correct answer is B. This is a nuanced timer mismatch case. OSPF validates the Hello and dead timer values in incoming Hello packets — if they differ from the local interface configuration, the Hello is rejected. In this scenario, R1 sends Hellos with hello=10, dead=40. R2 sends Hellos with hello=5, dead=20. When R1 receives R2's Hello, it sees hello=5 and dead=20 — these do not match R1's configured hello=10, dead=40. Strictly speaking, IOS should reject this Hello and the neighbour should not form at all. In practice, some IOS versions are more lenient about specific timer combinations, which is why this appears as a flapping scenario in some implementations. The clear answer for the exam is that mismatched timers cause neighbour formation failure or instability — in either case, the fix is to align the hello and dead intervals to the same values on both interfaces. Option C is incorrect — both hello and dead timers must match.

3. An OSPF neighbour between R2 (MTU 1500) and R3 (MTU 1476) is stuck at EXSTART. An engineer applies `ip ospf mtu-ignore` on R2's interface. The neighbour advances to FULL. Is this the correct permanent fix, and what risk remains?

A. Yes — ip ospf mtu-ignore permanently resolves the MTU mismatch by aligning the MTUs at the OSPF layer B. No — ip ospf mtu-ignore must be applied on both sides simultaneously or it has no effect C. Yes — the neighbour is FULL and routes are exchanging, so the fix is complete and no further action is needed D. No — ip ospf mtu-ignore is a workaround, not a fix. It tells OSPF to skip MTU validation during DBD exchange, allowing the neighbour to advance past EXSTART. However, the underlying MTU mismatch remains: R2 may still generate IP packets or OSPF LSU packets up to 1500 bytes, which R3's interface (MTU 1476) cannot handle — these are either fragmented silently or dropped, potentially causing route exchange issues or performance degradation. The correct permanent fix is to align the actual interface MTUs: set R3's ip mtu 1500 or set R2's ip mtu 1476 to match

Correct answer is D. ip ospf mtu-ignore is specifically documented as a workaround for situations where MTU alignment is not immediately possible — it instructs OSPF to skip the MTU field comparison during DBD packet processing, allowing the EXSTART/EXCHANGE deadlock to resolve. However, it does not change the actual MTU of the interface. The physical MTU mismatch still exists: any IP packet larger than 1476 bytes that transits the R2–R3 link may be fragmented (if DF bit is not set) or dropped (if DF bit is set). OSPF LSU packets can be large in topologies with many LSAs — packets exceeding 1476 bytes will be affected. The risk is subtle packet loss or performance issues that are difficult to diagnose because the OSPF adjacency appears healthy. The correct long-term fix is always to align the actual interface MTUs using the ip mtu command. Note that ip mtu (OSPF-layer MTU) and the interface hardware MTU are separate — ip mtu sets the IP layer MTU while the hardware MTU is set with the mtu command.

4. R1's `show ip ospf interface Gi0/0` shows `Network Type BROADCAST` and R2's same output shows `Network Type POINT_TO_POINT`. Both show FULL state in `show ip ospf neighbor`. A network engineer reports that some routes are present but others are inconsistent or missing. Why does FULL state occur despite the mismatch, and why do routes fail?

A. FULL state occurs because the network type mismatch does not prevent Hello exchange or database synchronisation from completing — the adjacency mechanism itself still works. However, LSA flooding breaks down because the two routers use different multicast addresses and different DR/BDR rules for distributing updates. The broadcast router sends updates to 224.0.0.6 (DR/BDR only) while the P2P router sends to 224.0.0.5 (all OSPF). Each router may not receive all updates, causing route inconsistency. Fix: align both to the same network type — point-to-point is preferred for two-router Ethernet links B. FULL state is impossible with a network type mismatch — the output must be misread. The routers are actually in 2WAY state C. The route inconsistency is caused by a separate issue — network type mismatch never affects route exchange, only DR/BDR election D. The FULL state and missing routes are both caused by the MTU being different — not the network type. The network type field is informational only

Correct answer is A. The network type mismatch between broadcast and point-to-point is one of OSPF's most counterintuitive faults because the neighbour can reach FULL state — yet routing is broken. The adjacency mechanism (Hello exchange, DBD, LSR/LSU to FULL) still completes because the underlying exchange process works regardless of network type. The problem is in ongoing LSA flooding after adjacency. On a broadcast network, OSPF uses 224.0.0.6 to send updates exclusively to the DR and BDR, which then flood to all routers. On a point-to-point network, all updates go directly to 224.0.0.5. When one router is broadcast and the other is P2P: the broadcast router sends some updates to 224.0.0.6 (expecting a DR to redistribute them) — but the P2P router has no DR/BDR concept and may not process these. The result is incomplete or asymmetric route tables where some routes appear on one router but not the other, or routes appear and then age out. The fix is to set both interfaces to the same network type — point-to-point is strongly preferred for two-router Ethernet connections as it eliminates DR/BDR overhead and converges faster.

5. What is the Router ID (RID) in OSPF and what is the recommended way to set it? What happens if two routers have the same RID?

A. The RID is the router's hostname translated to an IP — it is set automatically and cannot be manually configured B. The RID is the highest active interface IP address — always set automatically, never manually C. The RID is a 32-bit identifier that uniquely identifies a router in the OSPF domain, formatted like an IP address. IOS selects it in priority order: (1) manually configured with router-id [a.b.c.d] — recommended; (2) highest IP on any active loopback interface; (3) highest IP on any active non-loopback interface at process startup. If two routers have the same RID, OSPF neighbour formation fails — one router will see a duplicate RID in an incoming Hello and log an error. This is why manually configured RIDs or loopback-derived RIDs are recommended — they are stable and unique by design D. The RID is the management IP of the router — it must match the IP used for SSH access

Correct answer is C. The OSPF Router ID is a critical identifier — every router in the OSPF domain must have a unique RID. The IOS selection process follows strict priority: first, a manually configured RID (router-id command under router ospf) always wins. If none is configured, IOS uses the highest IP address on any loopback interface (loopbacks are preferred because they are always up — they never go down due to cable failure or interface issues). If no loopback exists, IOS uses the highest IP on any non-loopback interface that was active when the OSPF process started. The recommendation is always to configure loopback interfaces with /32 addresses on every OSPF router and use them as stable RIDs — either via router-id or by ensuring the loopback has the highest IP. Duplicate RIDs cause neighbour formation failure with a log message like %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id — the router receiving the duplicate will not form adjacency with it. This sometimes occurs when a router is cloned or when templates use the same seed IP.

6. An engineer configures `passive-interface default` under OSPF on R2, intending to suppress Hellos on all stub LANs. R2 has four interfaces: Gi0/0 (link to R1), Gi0/1 (link to R3), Gi0/2 (stub LAN — VLAN 20), Gi0/3 (stub LAN — VLAN 30). After the change, all OSPF neighbours on R2 disappear. What went wrong and what is the correct fix?

A. passive-interface default is not a valid OSPF command — the engineer used the wrong syntax B. passive-interface default removes all interfaces from the OSPF process — the network statements must be reconfigured C. The command only affects interfaces added after it is issued — the existing Gi0/0 and Gi0/1 neighbours should still be active D. passive-interface default makes ALL OSPF-enabled interfaces passive simultaneously — including Gi0/0 and Gi0/1 (the inter-router links). This suppresses Hellos on every interface, causing all existing neighbours to drop. The correct procedure is: (1) configure passive-interface default; (2) immediately follow with no passive-interface GigabitEthernet0/0 and no passive-interface GigabitEthernet0/1 to re-enable Hellos specifically on the router-to-router links. Gi0/2 and Gi0/3 remain passive (no Hellos sent toward end hosts)

Correct answer is D. passive-interface default is a valid and useful OSPF command that sets all current and future OSPF-enabled interfaces to passive mode simultaneously. The intent is sound — suppressing unnecessary Hellos on stub LANs — but the implementation error is that the command applies globally to all interfaces, including the inter-router links. When all interfaces become passive, R2 stops sending Hellos on Gi0/0 and Gi0/1, and the dead timers on R1 and R3 expire — both neighbours go DOWN. The fix is a two-step process applied in the same configuration session: first passive-interface default to make everything passive, then no passive-interface for each interface that needs to send/receive Hellos. This is actually the most secure baseline configuration — it ensures that any new interface added later (e.g., a new VLAN) defaults to passive and never accidentally sends OSPF Hellos to end hosts or untrusted segments.

7. `show ip ospf neighbor` shows a neighbour in `2WAY/DROTHER` state on R2's GigabitEthernet0/2. R2 is the DR on that segment. Is this a fault, and what does it mean?

A. Yes — 2WAY/DROTHER indicates the adjacency is only half-formed. Run clear ip ospf process to force DR re-election and full adjacency B. No — 2WAY/DROTHER is the correct and expected state on a multi-access broadcast network between two DROTHERs (non-DR, non-BDR routers). On a broadcast segment, only the DR and BDR form FULL adjacencies with all other routers. DROTHERs exchange Hellos with each other to establish 2WAY, but do not exchange full LSA databases directly — they send updates only to the DR/BDR (224.0.0.6) and receive floods from the DR (224.0.0.5). This significantly reduces LSA flooding traffic on large multi-access segments C. 2WAY/DROTHER is only valid on NBMA networks — on Ethernet it indicates a network type misconfiguration D. The DROTHER designation means the router has OSPF priority 0 — it is eligible to become DR/BDR but was not elected

Correct answer is B. This is one of the most frequently misunderstood OSPF outputs. On a broadcast network (Ethernet) with three or more OSPF routers, the segment uses a Designated Router (DR) and Backup Designated Router (BDR) to control LSA flooding. All routers form FULL adjacencies with the DR and BDR — these show as FULL/DR or FULL/BDR in the neighbour table. Routers that are neither DR nor BDR are called DROTHERs. Between two DROTHERs on the same segment, OSPF only progresses to 2WAY — bidirectional Hello exchange is confirmed but full LSA database exchange does not occur between DROTHERs directly. Instead, they rely on the DR/BDR to redistribute LSAs. This is intentional design — on a segment with N routers, doing full database exchange between every pair would require N×(N-1)/2 adjacencies. Using DR/BDR reduces this to 2×(N-2) adjacencies (each non-DR/BDR forms FULL with DR and BDR only). 2WAY/DROTHER is only a fault if it appears on a point-to-point link (where FULL/- is expected) or if it appears instead of the expected FULL/DR or FULL/BDR on the DR/BDR themselves.

8. After adding OSPF MD5 authentication to R1's interface with key ID 1 and key string "Campus99", the R1–R2 neighbour drops. R2 is then configured with key ID 2 and the same key string "Campus99". The neighbour still does not form. Why, and what is the fix?

A. The key string "Campus99" contains a capital letter — OSPF keys are case-sensitive and must be all lowercase B. MD5 authentication requires the OSPF process to be restarted with clear ip ospf process before it takes effect C. The key ID must match on both routers — R1 uses key ID 1 and R2 uses key ID 2. OSPF uses the key ID to select which key to validate the incoming packet against. When R1 sends a Hello with key ID 1, R2 looks for a key with ID 1 — it only has key ID 2 and cannot validate the Hello. Fix: configure R2 with ip ospf message-digest-key 1 md5 Campus99 (key ID 1 to match R1) and remove the incorrect key ID 2 D. The authentication type must also be configured at the area level with area 0 authentication message-digest — interface-level authentication alone is insufficient

Correct answer is C. OSPF MD5 authentication uses a key ID field in the OSPF packet to identify which key to use for verification. Both the key ID and the key string must match. When R1 sends a Hello, it includes key ID 1 in the authentication header — the MD5 hash is computed using key ID 1 and the string "Campus99". R2 receives this Hello, sees key ID 1 in the header, and searches its local key chain for a key with ID 1. R2 only has key ID 2 — it cannot find a matching key and discards the Hello. This is a very common misconfiguration when keys are being rotated or when templates use different key IDs on different routers. OSPF supports multiple key IDs simultaneously for graceful key rotation — you can have key ID 1 and key ID 2 both configured during a transition period, with both ends accepting either key. The fix is to ensure at least one matching key ID + key string pair exists on both routers. OSPF authentication is always per-interface in IOS — area-level authentication (Option D) is an alternative method that applies to all interfaces in an area, but interface-level authentication takes precedence and is perfectly valid without the area-level command.

9. `show ip ospf interface GigabitEthernet0/0` on R1 shows `%OSPF: OSPF not enabled on GigabitEthernet0/0`. R1's OSPF configuration shows `network 10.0.12.0 0.0.0.3 area 0`. R1's Gi0/0 IP address is 10.0.12.1/30. Why is OSPF not enabled on the interface?

A. The wildcard mask 0.0.0.3 covers 10.0.12.0 through 10.0.12.3 — this does include 10.0.12.1. However, if the interface has been manually set to passive-interface, or if the network statement was entered while the interface was down, OSPF may not have activated on it. Check show ip ospf for passive interfaces and show ip interface brief for interface state. Alternatively, the network statement may have a typo — e.g., 10.0.13.0 instead of 10.0.12.0 — that appears correct but does not cover 10.0.12.1 B. The interface must be explicitly added to OSPF with ip ospf 1 area 0 — the network statement is an older method and no longer supported C. The OSPF process must be restarted for new network statements to take effect D. OSPF cannot be enabled on GigabitEthernet interfaces — only on Serial or FastEthernet

Correct answer is A. The wildcard mask 0.0.0.3 correctly covers 10.0.12.0–10.0.12.3, which includes 10.0.12.1 — so the network statement logic appears correct. The most common causes of OSPF not activating despite a seemingly correct network statement are: (1) a typo in the network statement (10.0.13.0 instead of 10.0.12.0 is a common one-digit error) — use show run | section router ospf to verify the exact network address; (2) the interface is configured as passive-interface, either explicitly or via passive-interface default — use show ip ospf to check passive interfaces; (3) the interface was down when the network statement was entered and IOS did not activate OSPF on it — bounce the interface or clear the OSPF process. The modern alternative method (ip ospf 1 area 0 directly on the interface) bypasses network statements entirely and is more explicit — Option B is incorrect in saying network statements are not supported, but the interface-level method is increasingly preferred for clarity. OSPF supports any Ethernet interface type (Option D is completely false).

10. A network engineer needs to systematically diagnose why R1 and R2 have no OSPF neighbour, starting with no prior knowledge of the configuration. List the correct step-by-step diagnostic sequence using IOS commands.

A. Run debug ip ospf events immediately — this shows all OSPF issues in one output without needing any other commands B. Run clear ip ospf process on both routers to reset OSPF, then check if the neighbour forms C. Run show ip route ospf — if OSPF routes are present, the neighbour must have formed at some point and the issue is intermittent D. Follow this sequence: (1) ping [peer-interface-ip] — confirm basic IP reachability; if fails, troubleshoot L1/L2/L3 first. (2) show ip ospf neighbor — check current state (empty, INIT, EXSTART, etc). (3) show ip ospf interface [int] on BOTH routers — compare area, network type, hello/dead timers, and authentication type side by side. (4) show ip ospf — check for passive interfaces covering the router-to-router link. (5) show run | section router ospf — verify network statements cover both interface IPs. (6) debug ip ospf events — run briefly during a Hello interval to capture the exact rejection reason, then undebug all

Correct answer is D. Systematic troubleshooting follows a layered, logical sequence — each step either confirms a layer is healthy (allowing focus to move to the next layer) or identifies the fault definitively. Step 1 (ping) is critical because OSPF cannot form adjacency without basic IP reachability — diagnosing OSPF without first confirming Layer 3 is a common time-wasting mistake. Step 2 (show ip ospf neighbor) reveals the current state and immediately suggests the fault class: empty = early failure (auth/area/passive/wrong network statement); EXSTART = MTU; FULL with problems = network type. Step 3 (show ip ospf interface on both sides) is the most powerful single-command comparison — running it on both ends and comparing the six key fields (area, network type, timers, auth) identifies the mismatch without needing debug. Step 4 (passive interface check) is quick and frequently overlooked. Step 5 (network statement review) catches typos and wildcard mask errors. Step 6 (debug) is used only if steps 1–5 do not identify the fault — debug is resource-intensive and should be used last, briefly, with immediate cleanup. Option A (starting with debug) is a valid but less efficient approach that skips the faster passive analysis commands.

Back to Home

Troubleshooting OSPF Neighbor Adjacency

1. OSPF Neighbour Formation — Core Concepts

The OSPF Neighbour State Machine

The Six OSPF Hello Validation Fields

OSPF Network Types and DR/BDR Election

2. Lab Topology & Scenarios

3. Scenario 1 — Area ID Mismatch

Step 1 — Confirm No Neighbour and Verify Basic Reachability

Step 2 — Compare Area IDs with show ip ospf interface

Step 3 — Confirm with debug ip ospf events

Step 4 — Fix the Area Mismatch

Area Mismatch — Common Causes and Prevention

4. Scenario 2 — Hello / Dead Timer Mismatch

Step 1 — Observe the Flapping Pattern

Step 2 — Compare Timers on Both Interfaces

Step 3 — Fix the Timer Mismatch

Timer Mismatch Impact at Different Hello Intervals

5. Scenario 3 — MTU Mismatch (Stuck at EXSTART)

Step 1 — Observe the Stuck State

Step 2 — Check MTU on Both Interfaces

Step 3 — Confirm with debug ip ospf events

Step 4 — Fix: Align MTUs or Use mtu-ignore

Common Causes of MTU Mismatch on OSPF Links

6. Scenario 4 — Authentication Mismatch

Step 1 — Confirm Neighbour is Absent

Step 2 — Check Authentication Configuration

Step 3 — Confirm with debug ip ospf events

Step 4 — Fix the Authentication Mismatch

OSPF Authentication Types — Summary

7. Scenario 5 — Network Type Mismatch

Step 1 — Check Neighbour State and DR/BDR Roles

Step 2 — Check Network Types on Both Interfaces

Step 3 — Fix the Network Type

Network Type Mismatch Outcomes

8. Scenario 6 — Passive Interface / Wrong Network Statement

Step 1 — Check OSPF Process and Network Statements

Step 2 — Find the Passive Interface Configuration

Step 3 — Check for Wrong Network Statement (Secondary Cause)

Step 4 — Fix Both Issues

Passive Interface — Correct vs Incorrect Usage

9. Full Diagnostic Reference & Decision Tree

show ip ospf neighbor — Complete Field Guide

show ip ospf interface — The Primary Comparison Tool

OSPF Adjacency Troubleshooting Decision Tree

Key Points & Exam Tips

TEST WHAT YOU LEARNED

1. show ip ospf neighbor on R1 shows R2 in INIT state. show ip ospf neighbor on R2 shows no entry for R1 at all. The ping from R1 to R2's interface IP succeeds. What does this asymmetric state pattern indicate and what is the most likely cause?

2. Two routers share an Ethernet link. R1 has ip ospf hello-interval 10 (default) and R2 has ip ospf hello-interval 5 with ip ospf dead-interval 20. Both are in the same area with no authentication. Will the neighbour form, and will it be stable?

3. An OSPF neighbour between R2 (MTU 1500) and R3 (MTU 1476) is stuck at EXSTART. An engineer applies ip ospf mtu-ignore on R2's interface. The neighbour advances to FULL. Is this the correct permanent fix, and what risk remains?

5. What is the Router ID (RID) in OSPF and what is the recommended way to set it? What happens if two routers have the same RID?

7. show ip ospf neighbor shows a neighbour in 2WAY/DROTHER state on R2's GigabitEthernet0/2. R2 is the DR on that segment. Is this a fault, and what does it mean?

8. After adding OSPF MD5 authentication to R1's interface with key ID 1 and key string "Campus99", the R1–R2 neighbour drops. R2 is then configured with key ID 2 and the same key string "Campus99". The neighbour still does not form. Why, and what is the fix?

9. show ip ospf interface GigabitEthernet0/0 on R1 shows %OSPF: OSPF not enabled on GigabitEthernet0/0. R1's OSPF configuration shows network 10.0.12.0 0.0.0.3 area 0. R1's Gi0/0 IP address is 10.0.12.1/30. Why is OSPF not enabled on the interface?

10. A network engineer needs to systematically diagnose why R1 and R2 have no OSPF neighbour, starting with no prior knowledge of the configuration. List the correct step-by-step diagnostic sequence using IOS commands.

1. `show ip ospf neighbor` on R1 shows R2 in `INIT` state. `show ip ospf neighbor` on R2 shows no entry for R1 at all. The ping from R1 to R2's interface IP succeeds. What does this asymmetric state pattern indicate and what is the most likely cause?

2. Two routers share an Ethernet link. R1 has `ip ospf hello-interval 10` (default) and R2 has `ip ospf hello-interval 5` with `ip ospf dead-interval 20`. Both are in the same area with no authentication. Will the neighbour form, and will it be stable?

3. An OSPF neighbour between R2 (MTU 1500) and R3 (MTU 1476) is stuck at EXSTART. An engineer applies `ip ospf mtu-ignore` on R2's interface. The neighbour advances to FULL. Is this the correct permanent fix, and what risk remains?

7. `show ip ospf neighbor` shows a neighbour in `2WAY/DROTHER` state on R2's GigabitEthernet0/2. R2 is the DR on that segment. Is this a fault, and what does it mean?

9. `show ip ospf interface GigabitEthernet0/0` on R1 shows `%OSPF: OSPF not enabled on GigabitEthernet0/0`. R1's OSPF configuration shows `network 10.0.12.0 0.0.0.3 area 0`. R1's Gi0/0 IP address is 10.0.12.1/30. Why is OSPF not enabled on the interface?