340 Bridge queue full discards

[kneese]

I have 3 Aironet bridges setup in lab that were pulled from production for intermittent connectivity problems.

They seem to work fine until I put a load on them. I have a laptop directly connected to one bridge. The laptop has software that simulates 100 users hitting a web site continuously.

When the load starts 2 of the 3 bridges constantly report "Radio error: 200+ queue full discards.

According to documentation on CCO the "queue full discards" are related to ethernet traffic overloading the buffers of the radio. This makes sense but how come only 2 are affected? They are all running 8.65 firmware.

I have physically moved bridges around in the lab to move them closer and further away from load generator box. No change in results.

Is it possible these 2 bridges are faulty? Is there a definite way to verify without swapping? I don't have any more spares to play with.

Thanks,

Ken Neese

[derwin]

Hi Ken,

Not 100% sure of your test set up there ??

I would recommend the test bed being

Load generator -------BR root ------ radio link ----BR Non root ----- Load generator reflector

Then to test the 3 just swap it with the non root

Now where are you seeing the queue full discards ???

If they are 350 bridges then set the ethernet port to 10 M half duplex as this matches to radio side and has less chance of over running the buffers (still can be done though)

Congestion can also be a symptom of RF interference.

The radio will listen before it transmitt if it detects an RF signal then it will hold off then try again, the packet that is held off is kept in the buffer and as such you can over run the buffer if there is too much activity on the radio side be that from another legit signal or from intereference

[kneese]

The queue full discards only occur on the non-root bridge. I had 2 bridges that always got the 'queue full discards'. The only bridge that did not get them during testing was the root. So I reconfigured the non-root to root and made the root into non-root.

Now the original root bridge gets the queue full discards. It never did as a root bridge.

[derwin]

Hi Ken,

In relation to your ROOT and NON ROOT where is your traffic source ?

Do you see a high number of CRC errors on the radio stats page ??

If you do not see a high number of CRC errors and your traffic source is at the ROOT end then I suspect what is happening is.

The traffic source is sending the traffic all at once like an FTP transfer the ROOT bridge is fowarding this out the radio side (normal opearation so far) the non root receives this and forwards it out the ethernet side now the traffic destination is sending pack the ACK's the non root bridge trys to transmit these but as the ROOT is sending so much data then the non root retries and then the buffer fills and you get queue full discards.

This is a normal operation in a congested radio network, and you would get the exact same problem on a hub(not a switch) with an all wired ethernet network.

Try limiting your traffic source to a lower transmit rate and see if this resolves the problem.

David

[kneese]

Thanks for the reply. That makes perfect sense. I will try to limit the traffic. The load generator will allow bandwidth limiting.

I do get large (30k+) amounts of CRC errors, holdoffs and the queue full discards.

Thanks for the advice.

Ken

[derwin]

Ken,

The CRC error counters are culmitive from boot up or clearing.

The best way to read CRC errors is as a % of the input packets and the rate of incrementing.

David