Congestion causing OSPF adjacency loss

[Anonymous]

Hi,

Experiencing an issue with between a couple of remote sites connected via a LES link that is intermittently loosing its adjacency with each other.

On closer look on one of the ends is experiencing packet loss. Switch ports, Gbics and all cables have been replaced but still seeing packet loss.

On further investigation the packet loss isn't happening incrementally, in seems to happen at a certain point in time. It also seems the problem could be happening most often first thing in the morning.

The suggestion therefore seems to be that it is experiencing congestion.

So my question is how best to mitigate this problem and keep control traffic / OSPF adjacency active?

My understanding is that control traffic like OSPF would automatically be put into a high priority queue (qp8) and therefore shouldn't suffer from this problem. I haven't done a packet capture yet to confirm this but I can see traffic hitting QP8 using the qosmonitor.

Guess we could enable some flow control but wondered if anyone has experienced this before and what you did to resolve it.

Many thanks in advance.

[Paul_Poyant]

Thanks for the update, Martin.
It's hard to argue with success. Congratulations!

[Anonymous]

HI Paul, thanks for posting.

Just to let you know I managed to resolve the issue. The congestion theory didn't hold up when looking closer and I had explored all the other areas I could think of.

In the end it came down to looking at the differences in the configuration between to two end connections.

The differences I found where that one end had Tx & Rx flow control enabled, the other only had Rx (turned off flow control completely on both ports) but what seemed to fix it was one end having jumbo frames enabled and the other (which was experiencing the packet drops) didn't.

Since the change there has been no packet drops and no adjacency drops.

[Paul_Poyant]

Prioritization can only help when the throughput has slowed but not stopped. What is actually causing real or perceived packet loss - and the degree of such loss - has yet to be established. Given the broad set of possibilities, I have my doubts that this question can be effectively handled outside of a GTAC Support case - but we can give it a try.

What is the cross-section of networking equipment within the OSPF fault domain - make, model, and firmware version? This will help to better focus the troubleshoot.