Beruflich Dokumente
Kultur Dokumente
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
LOADING
Neighbor ID
/-
00:00:37
Pri
State
Dead Time
131.108.1.1
Address
Serial0
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#
, BW 256
______________________________________________________________________________
_______
R1#
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
11.3(10)T
RELEASE SOFTWARE
______________________________________________________________________________
_______
R1#
show version
12.0(7)T
, RELEASE SOFTWARE
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#
R2#
OSPF:
Retransmitting
Retransmitting
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
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.
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#
R2#
OSPF:
Retransmitting request
to 131.108.2.1 on Serial0
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
Interface 131.108.2.1 1