Here, logs are your best friends. Every time RRM changes channel or power level, logs tell you why in details. If RRM does not change your APs channel, there may be a very good reason for that. An interesting test might be to manually change a couple of APs' channel, and see if RRM does nothing or brings them back to the same channel. From there, you might be able to think of any local design specifics that may trigger this action.
Also keep in mind that RRM is configurable, and that it is triggered only if the expected gain is as you configured it. This "expected gain" might need to be up to 35 dB if this is how you set RRM up, which may almost freeze RRM's action.
Thanks for replying. I have been able to set up logging to an external syslog server with both the controller logs set at debugging and with SNMP. Correct me if I am wrong, but the RRM messages are at the debugging level? I have to be honest in saying I have looked through 1000's of log entries and search for RRM and only find things about RRM being logged at the debugging level, but I am not seeing the exact reason for the change. The debug log just looks extremely cryptic to me. Do you know what exactly I am supposed to be looking for regarding RRM?
We have decided to upgrade our IOS level to something that Cisco says will fix the issue with APs being set on the same channel. Hopefully that will fix most of the issues with co-channel interference etc. One other thing that is bothering me is that we have APs that are within a reasonable distance to one another an I understand that for RRM to function correctly APs need to have 3 neighbors that see each other at -70db, but we aren't seeing that at all. I guess we will see once the IOS upgrade is done. I'll keep you updated.
Have you read this link, also there are comments on the bottom to Cisco Support guys that do this all the time. I agree rev up the Cisco AP nodes, don't forget to service pack the clients OS too if possible via an patch management too like WSUS or Shavelik. Try different antenna or remove an AP for a few hours after lunch and troubleshoot this home wireless radio technology that is now in the enterprise.
The log information you are looking for is an SNMP trap generated by the controller. In the excellent document pointed by IntegrationArchitect, look at figure 20, by the bottom of the page, this is a channel change information. Look for such info in your controller.
Just for the sake of clarity on RRM... RRM performs 3 actions:
- channel change: this is done at RF group level (if configured) or controller level if there is only one controller per RF group. The group leader collects information from all APs of participating controllers (in the same RF group), and decides if changing one or several AP channels would improve the RF network quality by increasing RSSI and SNR from the other APs perspective (and therefore from the clients perspective). The gain expected from this channel change is seen in Wireless >802.11a/n (or b/g/n) > Auto-RF, by the bottom of the page, in the DCA Sensitivity Level. If the value you see there is, for example, 20 dB, it means that the expected gain on the worst AP needs to be of at least 20 dB to trigger the channel change You can change this sensitivity from the CLI, with the config advanced 802.11a (802.11b) channel dca sensitivity command. If your APs are a bit far away from each other or if DCA sensitivity is low (large number), the algorithm is not triggered because not enough gain would result from the change.
- Power decrease: this is the -70 dBm you are referring to. This is again a RF group level config decided by the RF group leader to reduce the power of APs to a -70 dBm value. As you write, you need 4 APs hearing each others for this algorithm to work. If you have less than 4 APs in the same area, or if the signal they receive from each other is less than -70 dBm, this algorithm is not triggered and the APs stay at their current power level.
- Power increase: this is the coverage hole algorithm, it is controller local (no coordination between controllers). If a certain number of clients go below a defined SNR level, the controller increases the AP power.
RRM is therefore complex, most of the time I found that it could be trusted and was eprforming well given the AP deployment... you can find more detailed explanations about RRM in many places, for example here:
There might be abug in the AP code you run (which code is it BTW?), but before blaming RRM, I would try to test if it is performing as expected (by changing manually AP power and channel, then putting the APs back to Auto and see if RRM does anything), then sniff with Airmagnet to see if the conditions expected by RRM are met... if they are not, RRM does nothing and this is normal. You may then want to change the RRM parameters on your controllers...
BTW, there are some cases where RRM does not offer the performances adapted to your deployments, this does happen... but cases where RRM does not work as expected are more uncommon...
Tell us if we can be of any help.
I have seen the document listed, but I have not had enough time to sit and read the entire thing. Thank you for the explaination of the 3 portions of RRM. Rght now, we are running. 184.108.40.206 on the controller. We are going to upgrade to a version of code that will be compatible with mesh since we are going to add some 1500 series APs for external coverage as well.
Last week, I noticed that around a particular area, all of the APs were on channel one. I took AirMagnet to the location and the amount of co-channel interference was unacceptable. These APs are no more than 30 ft apart. Two of the APs were blasting at Tx 1 and the other was at 4. I need a lot more work when it comes to wireless, but that just doesn't seem right.
The only problem with changing the APs manually is that when we do that, it will knock the clients off and force them to reassociate. The other problem is the amount of change order paperwork involved in making that happen. We have a maintenance window coming up at the beginning on January and I will definitely make the suggestion. I already made the suggestion to hard code the APs in just one area, but no one listens to me.
Thank you both for replying.
Der All, i report the same behaviour for the first Time . Its an Installation based on 5508/1252 and 6.0.x Code. We followed the Rules during Site Survey and Implementation to be optimized for VoWLAN, so distances between LAPs should not be an issue. All APs stucks on Ch/TxPower 1/1. Some debugs shows that RRM Messages will be interchanged, but the algorithms seems to be "dropped off". I am curious to hear about your results...
Bright Regards, Michael
@Jerome: one of our guys performs today his 1st Lab attempt... All the Best to Sascha!
I have not really seen this problem... however, I also try to stick to the 5 GHz band so that I don't have the co-channel issue anyway. I am not always successful, but I have not seen RRM not do a good job. I used to manage power and channel manually several years ago and the more APs that were introduce, the more of a pain it because. RRM has actually been a welcome feature.
There is a very good document to assist in manually tuning RRM. Appaerntly in earlier code it ran too hot at with the Tx power threshold set to default -65dBm, this is changed to default -70dBm however the doc states that good results have been found upto -75dBm.
Also note that significant improvements were made in RRM in code version 6.x so it may be worth giving the thuning a go and upgrading to 220.127.116.11 if you can. Note that some access points will not support this code.
Thanks for sharing the Doc. Does any one have a New version of Deployment guide on HREAP ? I have attached the 2008-2009 version of deployment guide, I know there are out some competitor like "Aruba Network" , which claim to be better ? Did anybody did a testing of this technology ?
Can anybody share the Pro and Cons of Cisco Vs Aruba Network ?
h-reap-design-deploy.pdf 200.5 K
Sorry Jared I dont understand where your info is from so cannot read it in context.
Regarding H-REAP is the question about H-REAP, RRM or RRM in H-REAP.
Yes Aruba do RRM and a version of H-REAP. Cisco say theirs is better and ARuba say theirs is. I have seen some slides proving Ciscos is better, from Cisco obviously. No doubt Aruba have the same.
Your question that someone says that Aruba is better than Cisco its a lot like saying my mum is better than yours, just because someone says its doesnt make it true, except where mums are concerned because all mums are the best.
Specifically what do you or they think Aruba is better at than Cisco, lets justify it and quantify it. Now Aruba has also recenly revamped its RRM or equivalent thereof.
Now if you have H-REAP you must remember that for H-REAP algorithms to work each AP must be able to see 4 other aps above a certain value, I cannot recall off the top of my head the values. So if you have two H-REAP aps in a building RRM will not work. Now if you have 5 aps in and H-REAP group and 20 other aps in your HQ the aps in the H-REAP group will form a sub RRM group where they manage their wireless seperate from the 20 HQ aps as if aps cannot see a neighbour at -85dbM they will form a sub group, now this sub group depends also on enough aps being heard for the RRM algorith to work.
Key takeaways are that you need enough aps in a location for RRM to work, you also need to think about manually tuuning if there are sufficient aps or manually setting aps up for power and channel.