OSPFCCNA 200-301

OSPF Neighbor Stuck in LOADING State

Presenting Symptom

An OSPF neighbor is stuck in the LOADING state and never transitions to FULL.

Network Context

Two Cisco routers (R1 and R2) are connected via a FastEthernet link in a small branch office. Both run IOS 15.x. OSPF is configured in area 0 with network type broadcast. The neighbor adjacency forms but gets stuck in LOADING state.

Diagnostic Steps

1

Check OSPF neighbor state

show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2         1   LOADING/ -      00:00:32    10.0.0.2        FastEthernet0/0

The neighbor is stuck in LOADING state, indicating that the routers are exchanging LSA databases but not completing the exchange. This suggests a problem with LSA delivery or processing.

2

Check OSPF database summary list

show ip ospf database database-summary
OSPF Router with ID (10.0.0.1) (Process ID 1)
  Router Link States (Area 0)
    Link ID         ADV Router      Age         Seq#       Checksum
    10.0.0.1        10.0.0.1        100         0x80000002 0x00A1B2
    10.0.0.2        10.0.0.2        200         0x80000001 0x00C3D4
  Net Link States (Area 0)
    Link ID         ADV Router      Age         Seq#       Checksum
    10.0.0.2        10.0.0.2        150         0x80000001 0x00E5F6

If the database summary shows missing LSAs or inconsistencies, it may indicate that the routers are not receiving all LSAs. However, in a LOADING state, the issue is often that one router is not receiving the Database Description (DBD) packets correctly.

3

Check OSPF interface MTU mismatch

show ip ospf interface FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/24, Area 0
  Process ID 1, Router ID 10.0.0.1, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 10.0.0.2, Interface address 10.0.0.2
  Backup Designated router (ID) 10.0.0.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:03
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 10.0.0.2  (Designated Router)
  Suppress hello for 0 neighbor(s)

Check the MTU value. If the MTU on the interface is not the same as the neighbor's, OSPF will fail to exchange DBD packets and get stuck in LOADING. The MTU is not shown in this output by default; use 'show interfaces FastEthernet0/0' to see MTU.

4

Check interface MTU on both routers

show interfaces FastEthernet0/0 | include MTU
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

If the MTU values differ between the two routers, OSPF will not form a full adjacency. The router with the smaller MTU will drop DBD packets that exceed its MTU, causing the neighbor to stay in LOADING. Both interfaces must have the same MTU.

Root Cause

The OSPF neighbor is stuck in LOADING state because the MTU on the two routers' interfaces is mismatched. R1 has MTU 1500, while R2 has MTU 1400. When R1 sends DBD packets larger than 1400 bytes, R2 drops them, preventing the database exchange from completing.

Resolution

Configure the same MTU on both interfaces. On R2, set MTU to 1500: interface FastEthernet0/0 ip mtu 1500 end Alternatively, set both to a lower common value. After changing MTU, clear the OSPF process to re-establish adjacency: 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:36 10.0.0.2 FastEthernet0/0 Also verify MTU matches with 'show interfaces FastEthernet0/0 | include MTU' on both routers.

Prevention

1. Standardize MTU across all OSPF interfaces in the network. 2. Use the 'ip mtu' command consistently during initial configuration. 3. Implement MTU discovery mechanisms or use a common MTU value (e.g., 1500) for all links.

CCNA Exam Relevance

On the CCNA 200-301 exam, OSPF neighbor states and troubleshooting are tested via multiple-choice questions and simulation labs. Candidates must know the OSPF state progression (DOWN, INIT, 2WAY, EXSTART, EXCHANGE, LOADING, FULL) and common causes for stuck states. The LOADING state specifically tests understanding of LSA exchange and MTU issues.

Exam Tips

1.

Memorize the OSPF neighbor state machine and what each state means.

2.

Remember that a mismatch in MTU causes OSPF to get stuck in EXSTART or LOADING state.

3.

Know that 'show ip ospf neighbor' and 'show interfaces' are key troubleshooting commands.

Commands Used in This Scenario

Test Your CCNA Knowledge

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

Practice CCNA Questions