Sie sind auf Seite 1von 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

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

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


Kbit, DLY 20000 usec,

MTU 2048 bytes

, BW 256

______________________________________________________________________________
_______
R1#

show interface ATM4/0/0

Hardware is cyBus ATM


80 usec,

ATM4/0/0 is up, line protocol is up

MTU 4470 bytes

, sub MTU 4470, BW 155520 Kbit, DLY

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


(fc1)
Copyright (c) 1986-1999 by cisco Systems, Inc.

11.3(10)T

RELEASE SOFTWARE

______________________________________________________________________________
_______
R1#

show version

Cisco Internetwork Operating System Software

IOS (tm) RSP Software (RSP-JSV-M) , Version


(fc2)

12.0(7)T

, RELEASE SOFTWARE

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


Interface 131.108.2.1 1

Neighbor ID Pri State


Dead Time Address
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
Interface 131.108.2.1 1

Neighbor ID Pri State


Dead Time Address
FULL/00:00:32
131.108.1.1
Serial0

Das könnte Ihnen auch gefallen