OSPFCCNA 200-301

OSPF Authentication Mismatch Preventing Adjacency

Presenting Symptom

Two directly connected routers running OSPF fail to form an adjacency, remaining in the INIT or EXSTART state.

Network Context

A small enterprise branch office with two Cisco routers (ISR 4321, IOS XE 16.9) connected via a single Ethernet link. OSPF is configured in area 0 on both routers, but the neighbor adjacency never reaches FULL state. The network uses simple password authentication for OSPF.

Diagnostic Steps

Check OSPF neighbor status

show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2         1    INIT/DR        00:00:32    10.0.0.2        GigabitEthernet0/0

If the state is INIT or EXSTART, adjacency is not forming. A FULL state is normal. INIT indicates a hello was received but not a two-way exchange, suggesting authentication or parameter mismatch.

Verify OSPF interface authentication configuration

show ip ospf interface gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/30, Area 0
  Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 10.0.0.1, Interface address 10.0.0.1
  Backup Designated router (ID) 10.0.0.2, Interface address 10.0.0.2
  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)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Can be protected by per-prefix Loop-Free Fast Reroute
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 0
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
    Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1

Look for authentication type: 'Message digest authentication enabled' (MD5) or 'Simple password authentication enabled'. If one router has authentication and the other does not, or if the keys/passwords differ, adjacency will fail.

Compare authentication configuration on both routers

show running-config | section router ospf

router ospf 1
 network 10.0.0.0 0.0.0.3 area 0
 area 0 authentication message-digest

Check if both routers have the same authentication type (e.g., 'area 0 authentication message-digest') and matching key IDs and keys under the interface. Mismatched keys or one router missing authentication will prevent adjacency.

Debug OSPF adjacency events (if permitted)

debug ip ospf adj

OSPF: Rcv pkt from 10.0.0.2, GigabitEthernet0/0 : Mismatch Authentication Key - Message Digest Key 1

This debug output directly indicates an authentication key mismatch. The router receives a packet but the authentication key does not match. This confirms the root cause.

Root Cause

OSPF authentication mismatch: Router A is configured with MD5 authentication using key ID 1 and key 'cisco123', while Router B is configured with MD5 authentication using key ID 1 but key 'cisco456'. The keys do not match, causing OSPF hello packets to be rejected and adjacency to fail.

Resolution

On Router B, change the OSPF authentication key to match Router A: Router B(config)# interface gigabitEthernet 0/0 Router B(config-if)# ip ospf message-digest-key 1 md5 cisco123 Router B(config-if)# end Alternatively, if authentication is not required, remove it from both routers: Router(config)# router ospf 1 Router(config-router)# no area 0 authentication Router(config-router)# end Then clear OSPF process to re-establish adjacency: Router# clear ip ospf process

Verification

Run 'show ip ospf neighbor' on either router. Expected output: Neighbor ID Pri State Dead Time Address Interface 10.0.0.2 1 FULL/DR 00:00:35 10.0.0.2 GigabitEthernet0/0 The state should be FULL, indicating adjacency is established.

Prevention

1. Use a consistent authentication configuration across all OSPF routers, preferably via a template or automation. 2. Document and manage OSPF keys securely, ensuring all devices use the same key ID and key string. 3. Verify OSPF neighbor formation after any authentication changes using 'show ip ospf neighbor'.

CCNA Exam Relevance

On the CCNA 200-301 exam, OSPF authentication mismatch is a common troubleshooting scenario. Questions may present a 'show ip ospf neighbor' output showing INIT state and ask to identify the cause. Candidates must know that mismatched authentication parameters (type, key ID, or key) prevent adjacency. The exam tests the ability to interpret 'show ip ospf interface' and 'show running-config' to spot authentication discrepancies.

Exam Tips

Memorize that OSPF neighbor states INIT or EXSTART often indicate authentication or parameter mismatch (hello/dead timers, network type, area ID).

In multiple-choice questions, look for options that mention 'authentication key mismatch' or 'area authentication mismatch' when given a scenario with INIT state.

Know the command 'show ip ospf interface' to quickly check authentication type and key ID on an interface.

Commands Used in This Scenario

debug ip ospf adj

Use this command to debug OSPF adjacency events in real-time, helping to troubleshoot why OSPF neighbors are not forming or are flapping.

show ip ospf interface

Displays OSPF interface parameters and status, used to verify OSPF configuration and troubleshoot neighbor relationships.

show ip ospf neighbor

Displays OSPF neighbor information to verify adjacency formation and troubleshoot OSPF neighbor relationships.

show running-config

Displays the current active configuration in DRAM, showing all non-default settings.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions