Heads Up :
The post you are writing will appear in a public forum. Please ensure all content is appropriate for public consumption. Review the employee guidelines for the community here.
In our environment, we have 4x 8540, which are used for the bulk of our APs and 2x 9800-Ls, which are mainly used for external APs (typically working-from-home-APs) and for testing purposes. I had a 2800 connected to the 9800 (17.6.2) and I wanted to...
It seems that a new feature called 'Easy PSK' is supported as of WLC version 17.5. Looking at the description in the documentation, this is something that could potentially be interesting for our environment. The documentation about the specifics on ...
I did an upgrade of CPI from 3.8 to 3.9 today. I did a backup of the 3.8 setup and restored it to the new 3.9 VM setup. It now seems that after the upgrade, all APs (we have around 3000 in the network), have 'lost' their map location. They all come u...
Our setup: We have 4 x 8540 WLCs with a internal management IP that serve internal (private IP) APs and we have 2x 5508 WLCs that are configured with a public management IP to serve APs that typically connect over the internet. This works fine. As th...
By coincidence, I have 2 of our main controllers running on 8.10.162.0 as test. I just pointed the AP to this one and it reverts back correctly. So this seems indeed to have fixed it: [*03/23/2022 12:30:15.0389] CAPWAP State: Discovery[*03/23/2022 12...
The AP was factory restored. I pointed it via CLI to an almost empty WLC (which is used as backup), just to keep the output of the debug somewhat under control. From show ver:cisco AIR-AP2802I-E-K9 ARMv7 Processor rev 1 (v7l) with 1028224/593948K byt...
Thanks Rasika. I am still trying whether I am getting the same issue when bringing CPI 3.9 up with the backup from a day earlier. If this turns out to be the case, I will open a TAC case.
