Roaming Between AP Groups?

[Toivo Voll]

We have a site where we're running 7.6.110 WLC code with a mix of APs from 1242s to 3700s. Globally all data rates, including 1 Mbps, are enabled, and we have a number of SSIDs. No bueno.

To help with channel utilization, we created (as per TAC's guidance) an AP group and RF profile that disabled some of the low rates, then placed some APs into said group. The SSIDs and interfaces are the same between all the AP groups, so there's never any inter-controller or L3 roaming.

Unfortunately it appears that if a 7925g hears an AP in the group and another AP in the default group with different rate sets, it fails to associate properly to either. Visibly the wireless symbol goes all the way to crossed out, and in the neighbor list you can tell that it's cycling through channels fruitlessly. Controller debugs show association failure due to rates, code 18. TAC now says that all APs that can hear each other must have the same data rate settings (i.e. all APs between which one might ever roam must be in the same RF profile.)

Is there any documentation or guidance about this? Is it the mandatory rates that are the issue, or does any mismatch cause this? Is there any way to restrict the low data rates of some APs in denser areas while leaving the same rates enabled in less dense areas and still have roaming with 7925s?

[Sahil Mengi]

Hi Tovio,

1. If you havent reduced the number of wlans serviced in this unique ap group, i am afraid its not serving you any good. The air is still busy.

2. Why do you need lower rates at all, 1,2,5.5 mbps at all? Have you tried disabling them at a global level?

3. What security do you have on this wlan? Is cckm enabled?

http://www.cisco.com/c/en/us/td/docs/wireless/technology/vowlan/troubleshooting/VoWLAN_Troubleshooting_Checklist.html

[Toivo Voll]

Thanks, Smengi!

Having the low data rates turned off does reduce channel utilization, all other things being equal, unless I misunderstood. Reducing SSIDs also reduces channel utilization. (Reducing how much APs on the same channel hear each other reduces utilization. Reducing client traffic reduces utilization. These we can't really affect, though.)

We're afraid that turning off the low rates globally will reveal coverage holes and strand critical legacy devices, so we wanted to go wing-by-wing. Arranging for a site-wide outage is a major change control hassle, doing it an area at a time is operationally easier. Also, while in most places the coverage is fine, there are service corridors etc. where density and co-channel interference aren't issues, and the extra range from the low rates would be beneficial.

Security is WPA2 PEAP with CCKM. We're pretty confident this is not authentication related (unless there's some bug or other unexpected interaction.)

We (and TAC) has run the WLC config through the config analyzer with voice checks.I just ran through the checklist you pointed to as well. The major discrepancy is that CAC is also not globally enabled, and TAC feels that this may be related. DTIM is 1 instead of 2, but we have Vocera in the mix and they insist on that. Beacon interval is 100 ms, although oddly enough the 7925g site survey reports it occasionally as being 102.

The core of my question though is whether there's any way to have two APs with different rate sets in proximity to each other and still have the wireless network work for all devices, including 7925gs, and where the issue with rate mismatches causing association failures is documented, if anywhere.

[Rasika Nayanajith]

If possible take a wireless packet capture  when 7925g moving from AP1 to AP2 (where you can take capture on AP2 operating frequency). That should capture Reassociation Request & Reassociation Response frame for a given client & tells you (status code) why client cannot associate to AP2 (data rate mismatch or any other reason). This post should gives you an idea what I am referring to

http://mrncciew.com/2014/10/28/cwap-reassociation-reqresponse/

Regarding Beacon Interval, it is 102.4ms or 100 TU (1TU=1024 microseconds). When 7925G reporting it may be in ms. so 102 value is correct. If it is referring as 100,then it should be Time Units.

I would a test this with 7.6.130.0 code if possible

HTH

Rasika

*** Pls rate all useful responses ***

[Toivo Voll]

A capture would be nice, we might see about trying to get one. The problem partially is knowing which AP the phone is trying to associate to. We've seen it be well within range of half a dozen APs, and fail to associate to any of them for 15-30 seconds, then associate to one at -71 dBm when there's a -40 dBm one available.

The Beacon Interval for most APs in the 7925g site survey is listed as 100ms, but for some it's 102ms; the phone specifically points this out as being "not recommended." I've been told that this is in fact expected behavior and not a problem.

7.6.130.0 suggest a FUS upgrade from what we have and won't pre-load with 1242s, so that upgrade is going to be a bit more challenging.

This is what we saw from the client debug on the WLC:

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx STA - rates (0): 140 18 24 36 48 72 96 108 108 72 96 108 0 0 0 0

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx suppRates  statusCode is 18 and gotSuppRatesElement is 0

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx STA - rates (4): 152 48 96 108 48 72 96 108 108 72 96 108 0 0 0 0

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx extSuppRates  statusCode is 18 and gotExtSuppRatesElement is 0

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx Sending Assoc Response to station on BSSID 44:ad:d9:61:78:25 (status denied rates) ApVapId 6 Slot 0

*apfMsConnTask_1: Oct 27 13:11:07.126: 44:2b:03:55:xx:xx Scheduling deletion of Mobile Station:  (callerId: 84) in 1 seconds

[Rasika Nayanajith]

Yes, debug indicate clearly due to data rate mismatch (re)association rejected. Refer this for more detail

https://supportforums.cisco.com/document/141136/80211-association-status-80211-deauth-reason-codes

statusCode 18: Will happen if the rates in the assoc request are not in the BasicRateSet in the beacon

Does your 7925G operate in 5GHz or 2.4GHz ? 

if it is 2.4GHz Make 11Mpbs mandatory & disable all lower data rates in 2.4GHz, this will still allow 802.11b if you have any legacy.

If it is in 5GHz, make sure 12Mbps is mandatory & disable all lower data rates in that band.

If your 7925G does not sending 12Mbps as supported rate then I would check the firmware of the phone & make sure it got latest  on it. (looks like 12Mpbs is not coming as supported rate from the phone where as in beacon that is set as mandatory)

Also one more suggestion, do not mix 1242 & 3700 in the same area & expect smooth roaming. Make sure roamed AP nearby area are all same type (sometime client stick to a/g AP rather move onto a n AP)

**** Pls do not forget to rate our responses if you find them useful ***

HTH

Rasika

[Toivo Voll]

Thanks, the Savarlak articles were pretty invaluable in figuring it out to start with, those really need to be a proper Cisco document somewhere.

The 7925s are currently in "auto-a" due to there not being sufficient 5 GHz coverage everywhere. Consequently turning off rates <12 in a is not going to happen, but the Deployment Guide suggests that this is acceptable. 

For bg, we'd love to turn off rates <12 in the majority of the building, but that would completely wreck service areas, basement corridors etc. and leave a lot of coverage holes there, and that's not really acceptable. That's why we went with AP groups / RF zones to begin with. The idea was to leave basements, kitchens etc. with lower rates enabled, turn off lowest rates for the rest of the building, and then do very dense areas with hundreds of users with even more aggressive rate reduction.

The phones are left at factory defaults, with no changes to PHY or rates restricted. As long as 6, 12 or 24 are mandatory on the network, I though it should work, but this does not appear to be the case if the adjacent APs have different sets. We can do some more experimentation, but I was hoping there'd be a clear explanation somewhere of what combinations do / don't work.

We're adding APs and converting to 3700s, so that problem will eventually self correct, but that's still months away from completion.

[Rasika Nayanajith]

Which version of firmware on your 7925G ?

Rasika

[Toivo Voll]

The phones are running CP7925G-1.4.4.3.LOADS

[Rasika Nayanajith]

I think 1.4.5 (CP7925G-1.4.5SR1.3)is the latest, if possible load this to one of the phone & see if that make any differences.

HTH

Rasika