Wireless Access

I'm working with a ~ 1,250 ap225's backended with pair of 7240's and we're running 6.5.3.5.  The ap's are deployed in a high density deployment in a number of schools. The schools are interconnected at 10GB - while their different "sites" they're connected more like they were local buildings bandwidth wise. I'm working on making some modifications to address co-channel interference there have been some connectivity challenges and while ARM can address manythings, it's not magic.  Some of these are pretty simple changes such as switching from 80mhz to 40mhz channel bonding which fixed some issues, and good or bad, I'm switching some of the 2.4ghz radio's to air-monitor mode - there's just too many of them and until we can migrate to something like AP345's, we'll have to make other adjustments.

I have multiple ap-groups and I've created a copy of each primary ap-group and simply renamed it, and changed which dot11g-radio-profile is used for the new group. 

The challenge I'm running into is that when I move some ap's into one of these new groups, in some instances they are ending up with a Dirty or no config flag set. 

It would make sense if this were happening for all ap's being placed into one of these ap-groups, but this seems to affect some ap's only.  For example, in a small building I regrouped 5 ap's into the new group - 4 worked fine, one is "dirty". For a much larger building I moved ~ 42 ap's into a different new group, 6 came up dirty.

I've noticed that if I move the ap's marked dirty back into their old group, they go back to a happy state.

I've been searching, and seen some much older posts about this sort of stuff, but nothing recent.

When I look at profile-error's, there is an AAA profile error for teh default profile.  

I'd found a show ap debug command, but that was apparently depreciated and wouldn't work in our code revision.

I probably should open a TAC case... but wondered if someone might have some simple suggestions that would point to a solution.

(Thus far I've switched to using ap-name specific device configurations for the ap's I want to adjust in this fashion... but I suspect there's a larger problem here)

"Dirty" typically means either the GRE (protocol 47) or papi (UDP 8211 or 8201) is being blocked between the Access point and the controller.  How was that new ap-group created and how it is different from others?

In unrelated news, you should go all the way down to 20 mhz channels if you have a high density deployment.

Thank you for your response.

I'm pretty certain these ap-groups were originally created via GUI, the new groups were created via CLI.  I copied the configuration for the current groups into an editor, altered the existing names, modified the radio-g line to reference the air-monitor profile.  Then copied and pasted one group to test, then pasted the rest.  To be honest, the first group lookd fine (shows up in the GUI properly, but the AP's didn't come up cleanly after being migrated into that group.  I can copy and paste in the two groups if it would help.  I don't understand why 4 out of 5 ap's would accept the new profile for one group, and 36 out of 42 would accept it in another.  

I understand on the 20mhz channels vs 40mhz channels, but 40 is requested for now.

Looking at "show ap arm state" commands, it looks as though there are enough channels to allow the ap's to adjust power and shift channels enough to make this work, though I suspect there would better power coverage if we were to shift things to 20mhz.  Probably would help alot if we were able to turn on DFS channels as well, but there's a bit of concern about that.

You should do a test.  Here is an easy way to copy an entire group:

config t

ap-group <new group name>

 clone <old group name>

Do that and move APs into the new group and they should be an exact copy.  If all the APs come up, you have a problem with the things you modified.  Change things one by one in the new ap-group and make sure all of the APs stay up.

The plot thickens...

What I'm seeing is this...

If I clone the ap-group, and change the radio profile I get a dirty flag... if I don't change the radio profile, it comes up clean, then I can change the radio profile AFTER the ap is up happy, and it stays happy... (even if I reprovision it again)...

I don't get it.

e.g.

conf t

ap-group PKC-APs-no24

clone PKC-APs

exit

ap-regroup ap-name PKC1-AP225 PKC-APS-no24

This works, then I can go back into the group

ap-group PKC-APs-no24

dot11g-radio-profile "airmonitor-g"

and it's happy...  I don't understand why I can't just change it up from the start... but I can work with this at least...

Thanks!

So what is in the radio profile?

The original ap-group rf dot11g-radio profile includes:

spectrum-monitoring

arm-profile "modified-default-g"

nt-radio-profile "modified-ht-default-g"

modified-default-g includes these lines:

   no 80MHz-support

   max-tx-power 12

   min-tx-power 3

modified-ht-default-g

(nothing is actually listed - could have left this as the regular default)

The new profile references

dot11g-radio-profile "airmonitor-g"

which includes this line:

   mode am-mode

(and the arm profile is "default-g")

which includes:

max-tx-power 9

min-tx-power 6

free-channel-index 40

(the ht-radio-profile is the default, and has nothing listed)

As near as I can tell, that's the whole diifference.

You should check out the driver log and see if something is amiss for that AP:

show ap debug driver-log ap-name <name of ap>

Also, check to see what configuration that AP received:

show ap debug received-config ap-name <name of ap>

I'm uncertain what to look for in the logs you've had me grab, but here are those logs.

This is from one Ap that I switched over to the ap-group with airmonitor-G set for the second radio, and ended up with a "dirty" flag.

Something that might apply, but probably doeesn't is that sometimes the radio's show up in a different order (2.4ghz/5ghz) meaning that sometimes the 5ghz radio is first in the list, while other times it's listed second.

Attachment(s)

debug-mod.txt   80 KB 1 version

I opened a case this morning.

Thank you!

So, at this point, the issue has been confirmed in the lab by the support person who was working my case, and they've submitted it to Engineering...