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.
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
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.
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.
IntroductionHow to use the Wireless LAN Controller Configuration Analyzer (WLCCA)
Javier Contreras is a Senior Tech Lead for the Wireless Business Unit in Cisco, with over 2 decades of experi...
< PRE >
(#)For this reason being that : - application that doesn't use multicast, sends one copy of each packet ( data unit of traffic at layer 3 ) to each client (" who seeks the traffic ).- application that does use multicast, sends ...
Transferring Crash file from standby:
Login to the Active WLC in HA.
(Cisco Controller) >transfer upload datatype crash
(Cisco Controller) >transfer upload filename <Desired filename>
(Cisco Controller) >transfer up...