Prevent certain APs from associating with WLC

[robinwenham]

Hi, we have the following situation which I'd appreciate assistance with.

We have 9 WLCs around a corporate network.  Each of the WLCs was in the same mobility group for failover purposes, and to permit APs to reconnect back to their primary WLC in the event of a failover.

However one of the sites has now been sold and pending separation of the LAN infrastructure the APs need to be isolated and prevented from associating with any WLC other than their primary (on site).  From our experience once the APs know about other WLCs they retain this list in NVRAM even if the secondary WLC is removed from the configuration they will still associate with one of the known APs if possible (Cisco document this).

WLC v 8.1.185.

Does anyone have any recommendations to achieve this?  My thoughts are:

1) configure WAN router to deny outgoing LWAPP / CAPWAP packets.  Router is a managed service which will entail negotiations and cost with the service provider.

2) completely default all APs on site.  69 APs mounted in the roof of a large distribution depot.

3) Use ACLs on the other WLCs to prevent ones from this subnet connecting to them.  May be the easiest because it is all in our control.  But I'm unsure of the implications of this.

4) any other?

Thoughts?

Thanks

R

[Stephen Rodriguez]

That is what the AP authorization feature is for. What you can do is enable AP authorization via the MIC. The add you current AP ti the auth-list, you just need to put in their Mac address. This should stop any AP not in the list from being able to join. I'd push the template from WCS

Steve

Sent from Cisco Technical Support iPhone App

[Scott Fella]

just to add my 2¢...Well if you only want the wlc on the primary site to be the only wlc that these ap's can join, why not change the mobility group name and the VIP, disable AP fallback and remove the mobility for the other 8 WLC's and also remove the mobility from the 8 other WLLC's and isolate it that way.That might be the easiest way.... treat it as a different site.

[robinwenham]

Hi Scott, you would have thought so, and this is what we did on the APs/WLC in question.  However our experience is that once the APs know about a WLC they retain that information in NVRAM - removing the mobility and fallback does not remove this - the AP will associate with any AP that they can reach by IP.  Of course with the "home" controller no longer in the mobility group then having associated with another controller there is no way home...so you have to put the home controller back into the mobility group then they will go back, then take it out again.

It seems to me that the only way to clear this info from the AP is to do a total reset and remove all the files in the file system back to the as-shipped config.

[Scott Fella]

Well once you change the mobility group and virtual they will have different info in nvram. Block udp 12222 & 12223 at the local router and they will never join any wlc outside of their local defined subnet.

Thanks,

Scott Fella

Sent from my iPhone

[robinwenham]

It's not that simple.  If simply changing the config from the controller stopped the APs  from associating to an unwanted controller outside their own network  then I wouldn't be here asking for help.  But that is not the case.

These APs (LAP1242s) keep a list of known controllers in the NVRAM that is not part of the running configuration from the controller - as I recall it is in the environment variables, but all the APs I have here in the office have been defaulted (which includes deleting the ENV_VARS file from flash) so I can't illustrate it.

As I said above, blocking the ports at the router involves managed routers and change requests which we can do but takes it two levels outside our control.

Hence the request for help about using ACLs to deny access to the WLCs from a specific network.

Thanks

Robin

[robinwenham]

@Steve - I see where you are gong with this Steve but it would be a big job 'cos it is the wrong way around for what I want to do - I want to deny APs to a WLC, this involves denying all then adding permits for all the known APs.

Within my infrastucture this is too big a task and potentially risky.  I wouldn't get permission to do this.

Thanks for the thought.

[Leo Laohoo]

WLC v 8.1.185.

Betcha by golly wow!  Can I get a copy of this firmware please????

[Scott Fella]

Your funny Leo. I had a feeling you would post something:)

Sent from Cisco Technical Support iPhone App

[Leo Laohoo]

Your funny Leo. I had a feeling you would post something:)

LOL.

Sorry folks.  Too much caffine with my meusli.

[robinwenham]

@Leo - OK maybe a small typo - 4.1.185...

Mind you v8 might be interesting...

[robinwenham]

So, for the reasons discussed above I don't think that I can use the AP Autorisation feature, and the mobility group changes haven't worked, so does anyone have any thoughts about taking an approach using ACLs to deny access from the subnet?

Thanks in advance

[Scott Fella]

Robin,

We give you suggestion that we think we would do in your situation. If it doesn't fit in your requirements then there is no other choice than to re-configure the other site. If you haven't tested to see if your theory is correct, then you don't have any other choice than delete the nvram.

Sent from Cisco Technical Support iPhone App

[robinwenham]

Scott,

Of course, and I understand that.

Robin

[robinwenham]

I'd like to thank everyone who replied, and to tidy it up.

The recommendation from Cisco is that we implement ACLs on the router to stop any control traffic passing (CAPWAP / LWAPP).

There is no simple way, given our infrastructure, to do this on the controllers.

Regards