OSPF Adjacency Problem

Unanswered Question
Apr 9th, 2007

I have a PPP link (Gshdsl) between two nodes. The OSPF had been running for two months. But sudenly , it stopped to form adjacency. One node has FULL state, but the other one LOADING. What is the menaing of LOADING state. What might be the reason of LOADING, not forming an adjacency?

Thanks for advance...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
cisco_lad2004 Mon, 04/09/2007 - 06:16

if it has been working before and just suddenly stopped. And assuming you have not made any changes to your set up or introduced a new IOS. it might be a bug.

what happens if you disable OSPF on the loading router and re enable it again ?

sundar.palaniappan Mon, 04/09/2007 - 06:33

The symptoms you are describing can be as a result of MTU problems on the intermdiate network. Can you enable 'debug ip ospf adj' and that might provide some clues about the cause of the problem. Exercise caution when enabling debug in a production router as with any other debug(s).

HTH

Sundar

cihatbulut Mon, 04/09/2007 - 22:28

Nothing changed. I had tried it. The output of debug ip ospd adj command is:

*Apr 18 16:00:17.758: OSPF: Interface ATM0.1 going Up

*Apr 18 16:00:18.258: OSPF: Build router LSA for area 0, router ID 192.168.98.1, seq 0x80000026, process 1

*Apr 18 16:00:20.494: OSPF: 2 Way Communication to 10.10.1.2 on ATM0.1, state 2WAY

*Apr 18 16:00:20.494: OSPF: Send DBD to 10.10.1.2 on ATM0.1 seq 0x215B opt 0x52 flag 0x7 len 32

*Apr 18 16:00:20.514: OSPF: Rcv DBD from 10.10.1.2 on ATM0.1 seq 0x3C1 opt 0x52 flag 0x7 len 32 mtu 4470 state EXSTART

*Apr 18 16:00:20.514: OSPF: First DBD and we are not SLAVE

*Apr 18 16:00:20.542: OSPF: Rcv DBD from 10.10.1.2 on ATM0.1 seq 0x215B opt 0x52 flag 0x2 len 1452 mtu 4470 state EXSTART

*Apr 18 16:00:20.542: OSPF: NBR Negotiation Done. We are the MASTER

*Apr 18 16:00:20.542: OSPF: Send DBD to 10.10.1.2 on ATM0.1 seq 0x215C opt 0x52 flag 0x3 len 52

*Apr 18 16:00:20.542: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:20.546: OSPF: sent LS REQ packet to 172.27.1.129, length 852

*Apr 18 16:00:20.566: OSPF: Rcv DBD from 10.10.1.2 on ATM0.1 seq 0x215C opt 0x52 flag 0x2 len 592 mtu 4470 state EXCHANGE

*Apr 18 16:00:20.566: OSPF: Send DBD to 10.10.1.2 on ATM0.1 seq 0x215D opt 0x52 flag 0x1 len 32

*Apr 18 16:00:20.586: OSPF: Rcv DBD from 10.10.1.2 on ATM0.1 seq 0x215D opt 0x52 flag 0x0 len 32 mtu 4470 state EXCHANGE

*Apr 18 16:00:20.586: OSPF: Exchange Done with 10.10.1.2 on ATM0.1

*Apr 18 16:00:21.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:21.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1176

*Apr 18 16:00:26.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

*Apr 18 16:00:26.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:26.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1176

*Apr 18 16:00:31.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

*Apr 18 16:00:31.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:31.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1176

*Apr 18 16:00:36.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

*Apr 18 16:00:36.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:36.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1164

*Apr 18 16:00:41.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

If this is a bug, why it appeared after two months?

Thanks for answers..

gaurav.prakash@... Tue, 04/10/2007 - 00:57

Hi,

*Apr 18 16:00:20.566: OSPF: Send DBD to 10.10.1.2 on ATM0.1 seq 0x215D opt 0x52 flag 0x1 len 32

*Apr 18 16:00:20.586: OSPF: Rcv DBD from 10.10.1.2 on ATM0.1 seq 0x215D opt 0x52 flag 0x0 len 32 mtu 4470 state EXCHANGE

flag 0x1 & 0x0 here indicate that the master and slave have nothing more to send. Can you plz let me know what are these IP address:

10.10.1.2 & 172.27.1.129

Do they belong to same or other device/interface..

Regards,

Gaurav Prakash

mohmmad.imran Thu, 04/12/2007 - 16:38

OSPF Neighbor Stuck in LOADING?Cause:

1) MTU Mismatch ( in your case as per the interface output this is not the cause)

2) 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 of the following reasons:

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

2) 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.

3) 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.

the below output shows that the router is retransmitting the LS request packet and is not getting any replies

because the replies are getting corrupted.

*Apr 18 16:00:21.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:21.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1176

*Apr 18 16:00:26.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

*Apr 18 16:00:26.130: OSPF: Database request to 10.10.1.2

*Apr 18 16:00:26.130: OSPF: sent LS REQ packet to 172.27.1.129, length 1176

*Apr 18 16:00:31.130: OSPF: Retransmitting request to 10.10.1.2 on ATM0.1

I believe that either you have a bad interface card on the receiving router or you are facing this issue due to the software BUG. I would suggest try to replace the hardware, hope it will resove your problem

Imran

minumathur Mon, 04/09/2007 - 10:14

Hi

any changes has been made, double check ?

1_ check the hello timer

2 debug ospf adj

this will help you out your problem

-minu

sundar.palaniappan Tue, 04/10/2007 - 05:33

Can you post the output of

1. debug ip ospf adj - from the device on the other end.

2. show int (wan_int) - from the WAN int or sub-int on both ends.

HTH

Sundar

cihatbulut Tue, 04/10/2007 - 22:53

Other device is Cisco 3845 and debug ip ospf adj output is:

*Apr 11 06:44:44.818: OSPF: Build router LSA for area 0, router ID 10.10.1.2, seq 0x80000807, process 1

*Apr 11 06:44:50.806: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.98.1 on ATM1/0.98 from LOADING to FULL, Loading Done

*Apr 11 06:44:51.314: OSPF: Build router LSA for area 0, router ID 10.10.1.2, seq 0x80000808, process 1

Indeed, The 3845 has FULL state but the other device (878) has LOADING state. Very Interesting?

WAN Interfaces;

AT 3845:

________

ATM1/0.98 is up, line protocol is up

Hardware is CX27470 ATMOC3

Internet address is 172.27.1.129/30

MTU 4470 bytes, BW 512 Kbit, DLY 80 usec,

reliability 255/255, txload 15/255, rxload 4/255

Encapsulation ATM

1471 packets input, 115386 bytes

1042 packets output, 178870 bytes

451 OAM cells input, 451 OAM cells output

AAL5 CRC errors : 0

AAL5 SAR Timeouts : 0

AAL5 Oversized SDUs : 0

AAL5 length violation : 0

AAL5 CPI Error : 0

2568180244 packets input, 5940464 bytes

95366500 packets output, 39148288 bytes

Last clearing of "show interface" counters 1w4d

AT 878:

________

ATM0.1 is up, line protocol is up

Hardware is MPC ATMSAR

Internet address is 172.27.1.130/30

MTU 4470 bytes, BW 512 Kbit, DLY 720 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ATM

5964240 packets input, 1291547714 bytes

3029375 packets output, 271670899 bytes

1870267 OAM cells input, 2072864 OAM cells output

AAL5 CRC errors : 0

AAL5 SAR Timeouts : 0

AAL5 Oversized SDUs : 0

Last clearing of "show interface" counters never

I think this is a very interesting problem :)

King Regards,

Actions

This Discussion