You are on page 1of 5

OSPF Neighbor Stuck in LOADING

This is a rare problem in OSPF neighbor relationships. When a neighbor is stuck in the
LOADING state, the local router has sent a link-state request packet to the neighbor requesting
an outdated or missing LSA and is waiting for an update from its neighbor. If a neighbor doesn't
reply or a neighbors' reply never reaches the local router, the router will be stuck in the
LOADING state.
The most common possible causes of this problem are as follows :
1. Mismatched MTU
2. Corrupted link-state request packet
Figure 9-42 shows a network with two routers running OSPF, with R1 experiencing a stuck in
LOADING problem.
Figure 9-42. Network Topology for OSPF Neighbor Stuck in LOADING Problem

Example 9-110 shows the output of show ip ospf neighbor indicating that R2's neighbor is stuck
in LOADING.
Example 9-110 show ip ospf neighbor Command Output Indicates Neighbor State ‚ LOADING, in This Case
R2# show ip ospf neighbor
Interface
131.108.2.1

1

LOADING

Neighbor ID
/-

00:00:37

Pri

State

Dead Time

131.108.1.1

Address

Serial0

OSPF Neighbor Stuck in LOADING ‚ Cause: Mismatched MTU Size
This is a unique problem that happens when an MTU mismatch occurs. If the MTUs are not the
same across the link, this problem occurs. Specifically, if a neighbor's MTU is greater than the
local router's, the neighbor sends a large MTU packet as a link-state update. This packet never
reaches the local router; as a result, the neighbor gets stuck in the LOADING state.
Figure 9-42 shows the flowchart to follow to solve this problem.
Figure 9-43. Problem-Resolution Flowchart

0. line protocol is up MTU 4470 bytes . RELEASE SOFTWARE . The MTU mismatch detection was added in RFC 2178 and was implemented in Cisco IOS Software Release 12. Example 9-112 Verifying Cisco IOS Software Releases Used on R1 and R2 R2# show version Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-I-M). line protocol is up Hardware is PQUICC with Fractional T1 CSU/DSU Kbit. which is lower than 12. BW 256 ______________________________________________________________________________ _______ R1# show interface ATM4/0/0 Hardware is cyBus ATM 80 usec.3. ATM4/0/0 is up.3(10)T.3(10)T . 11. DLY 20000 usec. Because R2 is running 11.0. BW 155520 Kbit.Debugs and Verification Example 9-111 shows the interface configurations on both R1 and R2. DLY Example 9-112 shows the Cisco IOS Software release that both R1 and R2 are running. Example 9-111 R1 and R2 Configurations Have Different MTU Values R2# show interface Serial0 Serial0/0 is up. MTU 2048 bytes . Version (fc1) Copyright (c) 1986-1999 by cisco Systems. Both configurations show the MTU value different from each other's. sub MTU 4470. Inc.3 and later. it fails to detect the mismatched MTU.

Example 9-113 shows the output of debug ip ospf adj on R2.2. R1 replies with an LSA that exceeds 2048. so R2 never gets that packet because it is too large. R2's MTU is 2048.1. which does not support MTU mismatch detection. Example 9-113 debug ip ospf adj Command Output on R2 Shows the Transmission History of DBD Packets to R1 R2# debug ip ospf adj OSPF adjacency events debugging is on R2# OSPF: Retransmitting request to 131.2. To change the MTU on an interface (in this case. Version (fc2) 12.1 on Serial0 OSPF: Database request to 131. which does support MTU mismatch detection. but R1's reply never makes it to R2 because the packet is too large. When R2 sends the LS request packet for the new instance of the LSAs. R1 detects MTU mismatches only when R2's MTU is higher than R1's. RELEASE SOFTWARE Copyright (c) 1986-1999 by cisco Systems. The debugs show that R2 continually is retransmitting the DBD packet to R1. otherwise . length 12 OSPF: Retransmitting request to 131.108.7T. so even though R1 is running Cisco IOS Software code with MTU mismatch detection. make sure that the MTUs on both sides match. indicating that OSPF neighbors are in the FULL state after fixing the unicast problem.1 OSPF: sent LS REQ packet to 131.0(7)T .1.1 on Serial0 Solution In this particular case.108.108. To fix this problem. In this case. enter the following interface-level command: interface serial 0 mtu 4470 Example 9-114 shows the output of show ip ospf neighbor.______________________________________________________________________________ _______ R1# show version Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JSV-M) . Example 9-114 Verifying That OSPF Forms Neighbor After Fixing the MTU Problem .0.2. Inc.10T. R2 is running Cisco IOS Software Release 11. In other words.108. MTU mismatch detection is valid only for a neighbor with an MTU higher than that of the local router. R1 is running Cisco IOS Software Release 12. R2's Serial 0 interface). R1 cannot detect an MTU mismatch because R2's MTU is lower than R1's. it does not complain.3.

Figure 9-44. such as a switch.1 1 Neighbor ID Pri State Dead Time Address FULL/00:00:32 131.  The receiving router is calculating the wrong checksum. either the receiving router's interface is bad or the error is caused by a software bug. Link-state request packets usually become corrupted because of the following reasons:   A device between the neighbors. This is a sign of packet corruption.1. This is the least likely cause of this error message. the neighbor discards the packet and the local router never receives the response from the neighbor. In this case.108. Example 9-115 Logs Show OSPF Received Bad Packets .108. Problem-Resolution Flowchart Debugs and Verification Example 9-115 shows the log messages on R2 indicating that R2 is receiving an OSPF packet with a bad checksum. This causes the OSPF neighbor to be stuck in the LOADING state.2.1 Serial0 OSPF Neighbor Stuck in LOADING ‚ Cause: Link-State Request Packet Is Corrupted When a link-state request packet is corrupted. The sending router's packet is invalid.R2# show ip ospf neighbor Interface 131. either the sending router's interface is bad or the error is caused by a software bug. is corrupting the packet. Figure 9-44 shows the flowchart to follow to solve this problem. In this case.

this problem is fixed by replacing hardware.108.2.108. Example 9-116 R2 Is Not Receiving Replies to Its Link-State Request Packets Because of Packet Corruption R2# debug ip ospf adj OSPF adjacency events debugging is on R2# OSPF: Retransmitting request to 131.108.1. This could be a simple bad port on the switch or a bad interface card on the sending/receiving router.1.1.1.108.1 Serial0 .108. Serial0 Example 9-116 shows that R2 is retransmitting the LS request packet and is not getting any replies because the replies are getting corrupted.1 1 Neighbor ID Pri State Dead Time Address FULL/00:00:32 131.1 OSPF: sent LS REQ packet to 131.2.108.1. Example 9-117 shows the output of show ip ospf neighbor indicating that OSPF neighbors are in the FULL state after fixing the corrupt link-state request packet problem.2.R2# show log %OSPF-4-ERRRCV: Received invalid packet: Bad Checksum from 131.108.1. Serial0 %OSPF-4-ERRRCV: Received invalid packet: Bad Checksum from 131.1 on Serial0 Solution Most of the time.108.1 on Serial0 OSPF: Database request to 131. Example 9-117 Verifying That the Corrupt Link-State Request Packet Problem Has Been Resolved. length 12 OSPF: Retransmitting request to 131. Allowing an OSPF Adjacency to Form R2# show ip ospf neighbor Interface 131.1.2.