Problem: 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 :

• Mismatched MTU

• 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  Neighbor ID   Pri  State     Dead Time   Address         Interface 131.108.2.1     1  LOADING  /-  00:00:37    131.108.1.1     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

Debugs and Verification

Example 9-111 shows the interface configurations on both R1 and R2. Both configurations show the MTU value different from each other's.

Example 9-111 R1 and R2 Configurations Have Different MTU Values

 R2#  show interface Serial0  Serial0/0 is up, line protocol is up   Hardware is PQUICC with Fractional T1 CSU/DSU  MTU 2048 bytes  , BW 256 Kbit, DLY 20000 usec, _____________________________________________________________________________________ R1#  show interface ATM4/0/0  ATM4/0/0 is up, line protocol is up   Hardware is cyBus ATM  MTU 4470 bytes  , sub MTU 4470, BW 155520 Kbit, DLY 80 usec, 

Example 9-112 shows the Cisco IOS Software release that both R1 and R2 are running. Because R2 is running 11.3(10)T, which is lower than 12.0.3, it fails to detect the mismatched MTU. The MTU mismatch detection was added in RFC 2178 and was implemented in Cisco IOS Software Release 12.0.3 and later.

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), Version  11.3(10)T  ,  RELEASE SOFTWARE (fc1) Copyright (c) 1986-1999 by cisco Systems, Inc. _____________________________________________________________________________________ R1#  show version  Cisco Internetwork Operating System Software IOS (tm) RSP Software (RSP-JSV-M) , Version  12.0(7)T  , RELEASE SOFTWARE (fc2) Copyright (c) 1986-1999 by cisco Systems, Inc. 

Example 9-113 shows the output of debug ip ospf adj on R2. The debugs show that R2 continually is retransmitting the DBD packet to R1, but R1's reply never makes it to R2 because the packet is too large.

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.108.2.1 on Serial0 OSPF: Database request to 131.108.2.1 OSPF: sent LS REQ packet to 131.108.1.1, length 12 OSPF:  Retransmitting  request to 131.108.2.1 on Serial0 

Solution

In this particular case, R2 is running Cisco IOS Software Release 11.3.10T, which does not support MTU mismatch detection. R1 is running Cisco IOS Software Release 12.0.7T, which does support MTU mismatch detection. R1 detects MTU mismatches only when R2's MTU is higher than R1's; otherwise , it does not complain. In other words, MTU mismatch detection is valid only for a neighbor with an MTU higher than that of the local router.

In this case, R2's MTU is 2048, so even though R1 is running Cisco IOS Software code with MTU mismatch detection, R1 cannot detect an MTU mismatch because R2's MTU is lower than R1's.

When R2 sends the LS request packet for the new instance of the LSAs, R1 replies with an LSA that exceeds 2048, so R2 never gets that packet because it is too large. To fix this problem, make sure that the MTUs on both sides match. To change the MTU on an interface (in this case, R2's Serial 0 interface), enter the following interface-level command:

  interface serial 0   mtu 4470  

Example 9-114 shows the output of show ip ospf neighbor, indicating that OSPF neighbors are in the FULL state after fixing the unicast problem.

Example 9-114 Verifying That OSPF Forms Neighbor After Fixing the MTU Problem

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/-    00:00:32   131.108.1.1   Serial0  

OSPF Neighbor Stuck in LOADING ‚ Cause: Link-State Request Packet Is Corrupted

When a link-state request packet is corrupted, the neighbor discards the packet and the local router never receives the response from the neighbor. This causes the OSPF neighbor to be stuck in the LOADING state.

Link-state request packets usually become corrupted because of the following reasons:

• A device between the neighbors, such as a switch, is corrupting the packet.

• The sending router's packet is invalid. In this case, either the sending router's interface is bad or the error is caused by a software bug.

• The receiving router is calculating the wrong checksum. In this case, either the receiving router's interface is bad or the error is caused by a software bug. This is the least likely cause of this error message.

Figure 9-44 shows the flowchart to follow to solve this problem.

Figure 9-44. 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 is a sign of packet corruption.

Example 9-115 Logs Show OSPF Received Bad Packets

 R2#  show log  %OSPF-4-ERRRCV: Received invalid packet: Bad Checksum from 131.108.1.1, Serial0 %OSPF-4-ERRRCV: Received invalid packet: Bad Checksum from 131.108.1.1, 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.

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.2.1 on Serial0 OSPF: Database request to 131.108.2.1 OSPF: sent LS REQ packet to 131.108.1.1, length 12 OSPF:  Retransmitting request  to 131.108.2.1 on Serial0 

Solution

Most of the time, this problem is fixed by replacing hardware. This could be a simple bad port on the switch or a bad interface card on the sending/receiving router.

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.

Example 9-117 Verifying That the Corrupt Link-State Request Packet Problem Has Been Resolved, Allowing an OSPF Adjacency to Form

 R2#  show ip ospf neighbor  Neighbor ID  Pri  State     Dead Time  Address       Interface  131.108.2.1  1    FULL/-    00:00:32   131.108.1.1   Serial0