04-08-2022 07:15 AM
We have had to upgrade to IOS-XE from 5520 to 9800. We then had to downgrade back to AireOS from 9800. This is all in VM platform. We are now moving the 9120's back to the 9800. The vm 5520 has been shut down. The 9800 has already had all the AP's joined successfully at one time. I am not able to see AP's join and had to factory reset them to get them to successfully join. Is this an issue with the upgrade/downgrade back to upgrade by chance? Just seeing if anyone else had this issue?
Solved! Go to Solution.
04-10-2022 05:43 AM - edited 04-10-2022 05:45 AM
And just to be clear: 5520 is a physical WLC appliance, NOT a VM!
Maybe you were referring to vWLC in which case there are well known documented issues with AP join between vWLC which have been highlighted on these forums in previous posts. That's in addition to the other issues mentioned above.
"N+1 HA (CSCuf38985)
Note |
When an AP moves from one vWLC to another, it may refuse to join the second vWLC. It occurs when the server hardware fails, or a new instance of vWLCs are created. It is recommended to implement server mirroring scheme at the VMware level such as vMotion or some orchestrator. It is highly recommended to retain a snapshot of the VM instance, one from the mobility domain to which access points have joined previously. Then use the snapshot to start the vWLC instance. Access points then join the vWLC. This method can be also be used for priming access points instead of a physical controller." |
CSCuf38985 : Bug Search Tool (cisco.com)
Like @Arshad Safrulla said the details of what and how you moved the APs around matter and likely resulted in the problem you've seen.
So when moving APs between vWLC generally best to reset to factory default before moving them to be sure they can join the new WLC correctly.
04-08-2022 03:07 PM
Depends, there were certain bugs which was causing this issue. For example APs that are upgraded to Release 17.6.x cannot join controllers that are running AireOS versions earlier than 8.10.162.0, 8.5MR8, or 8.5.176.2(IRCM).
You need to give more information such as from which firmware you were running during the change and what is the process you followed to migrate the AP's from AireOS to 9800 etc.
You cannot simply expect the AP's to join 9800 after shutting down AireOS WLC. You have the below options for the migration.
1. Manually configure the AP Manger IP of new 9800 WLC under each AP by GUI or CLI in AireOS WLC.
2. Create a new VLAN for AP management and configure option 43 pointing to new WLC AP Manager IP.
3. Use CIsco PRIME to migrate the AP's.
04-10-2022 05:43 AM - edited 04-10-2022 05:45 AM
And just to be clear: 5520 is a physical WLC appliance, NOT a VM!
Maybe you were referring to vWLC in which case there are well known documented issues with AP join between vWLC which have been highlighted on these forums in previous posts. That's in addition to the other issues mentioned above.
"N+1 HA (CSCuf38985)
Note |
When an AP moves from one vWLC to another, it may refuse to join the second vWLC. It occurs when the server hardware fails, or a new instance of vWLCs are created. It is recommended to implement server mirroring scheme at the VMware level such as vMotion or some orchestrator. It is highly recommended to retain a snapshot of the VM instance, one from the mobility domain to which access points have joined previously. Then use the snapshot to start the vWLC instance. Access points then join the vWLC. This method can be also be used for priming access points instead of a physical controller." |
CSCuf38985 : Bug Search Tool (cisco.com)
Like @Arshad Safrulla said the details of what and how you moved the APs around matter and likely resulted in the problem you've seen.
So when moving APs between vWLC generally best to reset to factory default before moving them to be sure they can join the new WLC correctly.
04-10-2022 06:42 AM
The resetting seems to be one way. The other way my boss did find was this. However I think we now have some cert issues that may of been caused by doing this. But yes just a factory reset works. Just doing 4 factory resets in 30 different environments is going to be tough. Thank you!
SSC auth-token verification
SSC auth-token configuration is used for bypassing hash validation on AP and provide trust based on token-string.
When SSC hash validation fails on AP but SSC auth-token config is present then AP will bypass this failure and completes DTLS handshake. AP expects and verifies the SSC auth-token received in join-response, the first encrypted CAPWAP packet from controller is same as the one that is already configured. If tokens doesn’t match then AP will terminate session.
Configuration on AireOS controller
(Cisco Controller) >config certificate ssc auth-token <token>
Configuration on Cat-9800 controller
(config)#wireless management certificate ssc auth-token <0/8> <token>
Note:
• On AireOS controller, SSC auth-token configuration will be pushed to APs which are joined at the time of configuration. But it will not be pushed to an AP which joins after the configuration was applied.
• The same behavior is applicable to Cat-9800 controllers running on 16.10 release.
• Starting from 16.11 release, Cat-9800 controllers will push SSC auth-token config to any AP which joins.
• SSC auth-token can be directly configured on AP using below CLI
#capwap ap auth-token <token>
• TODO: mention supported version (AireOS 8.5 onwards(?)).
• SSC auth-token can also be synced to AP via PNP-server
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide