Wireless Access

Hi folks, hopefully someone can shed some light on how this works... For I am confused.

 

I have a pair of VMMs with a cluster of 7240 controllers running AOS 8.4.0.2 CPSEC is enabled with auto cert provisioning.

 

I'm working on moving APs from 6.5 to 8.4 and doing this by re-provisioning the APs. All has been good so far, but yesterday I can into one AP that didn't come up - it was failing to sort out IPsec. Sure enough it wasn't in the whitelist. But why? I haven't had to manually add any other APs to the whitelist.

 

Adding this AP to the whitelist worked, it came up and is happy on the cluster. In an attempt to recreate this I wanted to factory default the AP, delete it from the mobility master, and remove it from the whitelist.

 

The last part is the problem. I removed the AP from the whitelist using the CLI at the /md level. All good... it's gone from the CLI. However it hasn't gone from the MDs. 

 

What should happen here. When removing an AP from the whitelist on the Mobility Master at the managed network level, should that be pushed out to the MDs?

 

This currently feels a bit flaky, but not sure if I've missed something.

Please open a case with TAC to troubleshoot further. I've seen similar behavior also with 8.4.0.2, but have not been able to reliably reproduce it to see what's going on.

I had a similar issue when I upgrade from 6.5 to 8.3. I ended up disabling CPSec to get APs back online since I had to close my change window. I have since manually added all APs to the whitelist but I have not scheduled a change window yet to re-enable CPSec.

 

I am planning on opening a TAC case for when I switch CPSec back on to capture any issues but I'm very curious to see what you find out.

It's odd. I've got something like 800 APs running across two OS8 clusters and it's all worked just fine.... until yesterday when APs have stopped being automatically whitelisted. 

 

This bit of the docs feels a bit messy too. Sometimes it refers to being at the managed network level, other times the MM. As far as I can tell everything should be done at the MM level for whitelisting and viewing the whitelist-db... Though that might be incorrect.

 

There's one reference to the database being copied on demand, so I don't think all the controllers should have a coherent copy of the whitelist-db. This makes sense, because the database could get unwieldy in a big network with a 12 controller cluster.

 

Because manually whitelisting works I've done that, but something is clearly wrong. But there are quite a few bug fixes in 8.4.0.3 related to the management of the whitelist-db so I'm probably going to hold off raising anything with TAC until I've been able to do an upgrade.

My story... We did an upgrade from 6.5 to 8.2. We wanted to cluster our 7210s that is why we wanted to stay current. In the process, TAC recommended going to to 8.3 to resolve some clustering "issues". So, here we go...found some issues where the whitelist wasn't being sync'd for our RAPs on a seperate 7010 controller....Had to get TAC involved, they did some "magic" and got the controllers, cluster to sync the whitelist across the MM to all the controllers....WaLa...now the whitelist is everywhere. RAPs work, CPSEC enabled and working.... Go figure...

A quick update regarding my woes..... My mistake was that when erasing the controllers, before building the cluster, I ran the command: write erase
I should have used: write erase all

The former clears config but not databases from the controller so the whitelist database for cpsec and raps lingers from the old OS.

Because AOS8 doesn't, by default, sync this database across the cluster the stale entries in the various controllers were causing a problem. Issues were pretty weird because all the APs appeared to coming up ok but when user traffic tunnels were setup to one of the three controllers in the cluster they were being rejected as not approved in the whitelist. So the result was some users couldn't connect because the cluster kept load balancing them to that controller.

Fortunately I figured out what was happening pretty quickly, purged the whiltelist-db on all controllers and the problems went away. TAC confirmed this is as a correct diagnosis and reasonable remedy of the problem.

The show whitelist-db command appears to be meaningless at the managed device level. It shows stuff, but in no way reflects how many APs or user tunnels the controller is serving.

Now this problem is fixed I need to revisit the RAPs and how they behave, but for the moment they've all still running on our one remaining 6.5 controller.

Thanks for posting the follow-up, Matthew. I'm sure the difference between "write erase" and "write erase all" has gotten more than a few people.