When setting the WLAN Radio Policy - do I have to reboot APs?

[tdennehy]

I have a controller running 7.2 code.  I changed the radio policy on a WLAN yesterday to 802.11a only, and noticed all of the clients (ticket scanners, in this case) were still mixed between 802.11g and 802.11a.  I wanted to move them all to 5 GHz for obvious reasons.

After making the change, the clients remained on both frequencies.  I then went to the AP they are all associated to and turned off the 5 GHz radio, and then they all jumped to 2.4 GHz.  I then went the other direction, turning on the 5 GHz and turned off the 2.4 GHz.  They all jumped to 802.11a as expected.

I turned the radios back up on the AP, and they went back to the way they were.

I did reboot some of the APs and then I noticed after a packet capture that the 2.4 GHz disappeared on some of the APs.

Does anyone know if you have to reboot the APs after changing the radio policy?  Sure seems that way to me, even though I have never done it in the past.

Thanks in advance...

[Scott Fella]

You don't have to reboot the AP's. when champion the radio policies or any of the WLAN settings, it will glitch your WLAN for a moment which will drop the clients for a quick second. If you set the radio policy to 802.11a, then the clients should not be able to join on the 2.4 for that WLAN.

Sent from Cisco Technical Support iPhone App

[Scott Fella]

One thing to note, if you disable the 802.11b by setting the WLAN to 802.11a only. Is the device associated and authenticated and in the RUN state. Some devices don't like being forced to a certain band by the WLC. Sometimes you will have devices that will not successfully authenticate. It's better to set the radio to use on the device itself. I have ran into various devices that not setting the radio policy to all causes authentication issues. Now if I set the policy to 802.11b or b/g, the devices work fine. So just play around with settings and see what works and doesn't.

Sent from Cisco Technical Support iPhone App

[tdennehy]

Scott,

I agree with you on all counts.  You should set the client to where you want it to be.

I was told the clients (not under my control) were a/b/g, and they search 802.11g and then 802.11a.  I wanted to find out if that was true or not.  Needless to say we're having problems with the ticket scanners.

I can set the radio policy to 802.11a, and the clients will still stay on 802.11g.  See screenshots below.  I agree, some clients don't like being forced to a certain band, and some don't like load balancing turned on at the controller.

It is almost as if the switch to turn off the 802.11b/g doesn't do anything.

[Scott Fella]

I don't see how these can connect if you enable only 802.11a. You need to test and actually see if a laptop can see or connect to that ssid on the 2.4ghz. I have used this feature to be able to do some testing and never had any issue. What I would try is to change the radio policy to 802.11a only hit apply and then disable the wlan for a few seconds then enable it and hit apply. This will drop the scanners and they should not be able to connect to the 5ghz.

Sent from Cisco Technical Support iPad App

[tdennehy]

Verified.  Radio Policy set to 802.11a, and did a site survey yesterday with AirMagnet Site Survey Pro with both 2.4 GHz and 5 GHz scanning turned on.

I have both frequencies being broadcasted.  The controller is ignoring the radio policy on the main WLAN.

Now I don't believe anything the controller GUI is telling me.  I am going to have to survey the entire building to see what is being broadcasted, on what frequencies, and where.

[Saravanan Lakshmanan]

#what's the wlan id used, do you've APs co-located that're part of different AP groups having this ssid broadcasted.

#these are ways to verify the behavior:

With A only set on WLAN, use insidder/netstumbler and check ssid on 2.4g beacons.

WLC>show cont d0 - See the ssid is listed or not.

reboot AP when it pulls the config from wlc see it adds that ssid on radio d0.

#Possible bug CSCty61970, its applicable only if you're using AP group. it's been fixed on 7.2.110.0 and higher releases, if you're already on this or higher code then open a TAC case. workaround - delete and recreate the AP group.

#AP group can't override Radio policy unless RF profile configured with all datarates disabled for that radio.

[tdennehy]

Verified.  Radio Policy set to  802.11a, and did a site survey yesterday with AirMagnet Site Survey Pro  with both 2.4 GHz and 5 GHz scanning turned on.

I have both frequencies being broadcasted.  The controller is ignoring the radio policy on the main WLAN.

Now  I don't believe anything the controller GUI is telling me.  I am going  to have to survey the entire building to see what is being broadcasted,  on what frequencies, and where.

These APs are in one AP Group that is mainly used for ticketing scanners.  We only want the ticket scanner WLAN on 2.4 GHz, however the controller will not push the 802.11a-only command into the configuration.

Here is the odd part.  There is a small subset of APs that do obey the command.  The rest do not.

I used AirMagnet WiFi Analyzer.  I definitely see the WLAN on both frequencies.  I also used Wireshark with three airpcap adapters and I see the WLAN on 2.4 GHz.  Trust me, that controller is not sending the command from the GUI to the running config.

But CSCty61970 - I am using an AP Group.  I don't think it has been fixed, or if it has, we are seeing a variant of that bug.  I tried to tell TAC, but have not heard back.

If the workaround is to delete and recreate the AP Group, how can I be sure the controller will do what I tell it to do.  At this point I do not believe anything the controller is telling me when I configure anything.  I would rather create a new AP Group and assign the APs to the new group instead of deleting and recreating.  If I do that, then the controller might not do what I tell it to do, and leave the entire system (and 16,000+ users) offline.

Here's another thought.  There used to be an RF Profile on the AP Group, but it has been taken off.  I wonder if I have found a new bug that has something to do with an AP Group ignoring the GUI if there used to have an RFP on the AP Group.

[Saravanan Lakshmanan]

I see that you've asked this Radio policy question on multiple threads.

"We only want the ticket scanner WLAN on 2.4 GHz, however the controller will not push the 802.11a-only command into the configuration."

//If you want G-only then why you expect to push A-only.

"If the workaround is to delete and recreate the AP Group, how can I be sure the controller will do what I tell it to do."

//I understand, you need to test with one AP on that newly created group, if it works move all AP. Have you tried to use cli command.

----------------------

Are the Main WLAN selected A-only that mapped to default group broadcasting both A and G on that AP, then we're dealing different issue here. Are different model APs seeing this issue.

What's the current WLC code that's seeing this issue, what was the last code it worked?

Did you upgrade the WLC code that trigger this issue?

Do you use Mix of both Single and Dual band Radio APs?

Are RF profiles created globally and used on AP group in question?

Yes, On GUI there's no Radio policy override per WLAN on each AP group, however there is cli command - see below?

Did you first verify whether you're hitting an issue due to AP group(s) not inheriting Radio policy, Try below command and workaround.

WLC>show wlan apgroups

Do you see 'none' instead of 'A-only' for Radio policy, if so use the workaround to fix it.

workaround:-

WLC>config wlan apgroup radio-policy 802.11a-only

[tdennehy]

Let me first start out with YOU ARE A GREAT HELP.  I APPRECIATE YOU HELPING ME!

Controller running 7.2.110.7

My goal is to  set the WLAN to either 802.11a or 802.11g only. It doesn't matter  which, but it needs to be set. Our ticket scanners are 802.11a/b/g, and  they scan to find the best channel. When they roam, they take 45 seconds, and during this time no scanning can happen.  If I can move them to one band, we might see better performance.

With the Radio Policy set to 802.11a-only at the moment, this is what I see:

The APs that belong to this AP Group will follow the radio policy from 802.11a to 802.11g when changed. (ie, this one works)

Site Name........................................ EventPlaza-RFP

---

1 intf-guestwireless-800Disabled None

4 intf-ticketing-750 Disabled None

3 intf-pos-760 Disabled None

7 intf-internal-770 Disabled None

The APs that belong to this AP Group will NOT follow the radio policy from 802.11a to 802.11g when changed. (ie, this one does NOT work)

Site Name........................................ Ticketing-RFP

1 intf-guestwireless-800Disabled All

6 intf-tablet-780 Disabled None

4 intf-ticketing-750 Disabled All

3 intf-pos-760 Disabled All

From what I can tell, it looks as if our problem is backwards.

See answers inline:

Are the Main  WLAN selected A-only that mapped to default group broadcasting both A  and G on that AP, then we're dealing different issue here. Are different  model APs seeing this issue.

A: I just  looked at the output of show wlan apgroups and found "none", but also  found that the APs that do not work have "all". (these APs continue to  bcast on 2.4 GHz and 5. GHz.

What's the  current WLC code that's seeing this issue, what was the last code it  worked? I think it worked before our last upgrade. (I am new here)

Did you upgrade the WLC code that trigger this issue? (I believe so)

Do you use Mix of both Single and Dual band Radio APs? (We only have 3502i, 3502e and 3502p access points)

Are RF  profiles created globally and used on AP group in question? They were,  but have been removed. That is why the AP Groups have RFP in the name.  But has been removed for AP Group.

Yes, On GUI  there's no Radio policy override per WLAN on each AP group, however  there is cli command - see below? (I will look at it)

Did you first  verify whether you're hitting an issue due to AP group(s) not  inheriting Radio policy, Try below command and workaround. (I am going  to create a new AP Group and try moving APs to it and try that first)

[Saravanan Lakshmanan · Accepted solution]

If you've updated the code and seeing this issue then you're hitting a bug for sure, Only creating new AP group(s) or deleting and recreating the existing AP group(s) or using the mentioned cli command for AP group can help.

It is not going to help any changes made on existing AP group since it has inherited wrong Radio policy config, also AP group has no gui config to override the WLAN settings. Changing the main radio policy on wlan config will make no difference since the AP group reset Radio policy to All is hardcoded after code update.

[tdennehy]

I agree.  The only way to fix it is to create new AP Groups or delete/create existing ones.  I haven't tried using the CLI...