02-24-2023 08:09 AM
Hi Support team,
I have a requirement to replace current 5508 WLC HA cluster to 9800 WLC at customer DC. The access points are distributed in different countries and centrally managed from the DC WLC. As far as I know the APs will start upgrading as soon as they are registered to new WLC. Is there a way we can prevent this and do staged upgrade. I checked document "High Availability using Patching and Rolling AP Upgrade on Cisco Catalyst 9800 Wireless Controllers". Does it covers migration of APs to new WLC? or it is only possible for the APs currently active under the 9800 WLC?
It would be great help if there is a step by step approach you can share.
Thank you.
Solved! Go to Solution.
02-24-2023 08:52 AM - edited 02-24-2023 09:02 AM
Make sure the ap's are supported on the code you are running on the 9800!!! Also if you are not going to do a full site at once, then you need to make sure you have mobility configured from the 5508 to the 9800. There is a supported code version for that and the guide: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-8/b_c9800_wireless_controller-aireos_ircm_dg.html
From my experience, the current environmnet is up and you just need to validate that the high availabiliity is configured on the access points to point to the existing controller. I'm assuming it is, but if not, make sure this is done. Now you can bring up the new 9800 in parallel, but you don't have to worry, becuase you didn't define the 9800 in the high availability. Make sure you don't add or change option 43 or DNS for controller discovery if you have that in place. You can change that later when you have migrrated all your ap's off the 5508. Now when you are done testing and want to push out a few ap's to test, all you have to do is configure the access point high availability to point to the 9800 as the primary and the 5508 as the secondary. This way in case anything goes wrong, the ap knows to try the 5508.
Now if this is successful, you can then script out the change from the 5508 to the ap's you want to move. If you are not going to move all the ap's in a site at once and need to support roaming between the two environmnets, then make sure you have mobility. Make sure the SSID's are configured exactley the same or else roaming can break. Once you are done with the migration, you can then script the change to change the high availability so that the primary is the 9800 and the secondary is another 9800. Keep in mind that the high availabity is case sensitive for the controller name. ALso note that you can't blank our an entry from the cli, but you can add a blank space to the command.
config ap primary-base " " CAP01 0.0.0.0 <-- 1 space
config ap secondary-base " " CAP01 0.0.0.0 <-- 2 space
config ap tertiary-base " " CAP01 0.0.0.0 <-- 3 space
This is the method I use when moving ap's I'm testing to other controllers. Hope this helps.
02-24-2023 08:52 AM - edited 02-24-2023 09:02 AM
Make sure the ap's are supported on the code you are running on the 9800!!! Also if you are not going to do a full site at once, then you need to make sure you have mobility configured from the 5508 to the 9800. There is a supported code version for that and the guide: https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-8/b_c9800_wireless_controller-aireos_ircm_dg.html
From my experience, the current environmnet is up and you just need to validate that the high availabiliity is configured on the access points to point to the existing controller. I'm assuming it is, but if not, make sure this is done. Now you can bring up the new 9800 in parallel, but you don't have to worry, becuase you didn't define the 9800 in the high availability. Make sure you don't add or change option 43 or DNS for controller discovery if you have that in place. You can change that later when you have migrrated all your ap's off the 5508. Now when you are done testing and want to push out a few ap's to test, all you have to do is configure the access point high availability to point to the 9800 as the primary and the 5508 as the secondary. This way in case anything goes wrong, the ap knows to try the 5508.
Now if this is successful, you can then script out the change from the 5508 to the ap's you want to move. If you are not going to move all the ap's in a site at once and need to support roaming between the two environmnets, then make sure you have mobility. Make sure the SSID's are configured exactley the same or else roaming can break. Once you are done with the migration, you can then script the change to change the high availability so that the primary is the 9800 and the secondary is another 9800. Keep in mind that the high availabity is case sensitive for the controller name. ALso note that you can't blank our an entry from the cli, but you can add a blank space to the command.
config ap primary-base " " CAP01 0.0.0.0 <-- 1 space
config ap secondary-base " " CAP01 0.0.0.0 <-- 2 space
config ap tertiary-base " " CAP01 0.0.0.0 <-- 3 space
This is the method I use when moving ap's I'm testing to other controllers. Hope this helps.
02-24-2023 09:05 AM
Thank you Scott for the guideline. I will workout based on this plan.
02-24-2023 09:25 AM
Glad to help.... you want to validate your scripts which you will have a few, one to make the change, one to blank out a line and the other to finalize your ap HA.
Remember, you will get an error if the controller name is already defined in any other controller fields. That is why you need to define a bogus entry using blank spaces, which will allow you to move an entry to another location.
While tinking about this, this is what has worked for me, you might want to adjust this dependign on how may controllers are defined already.
Optional: if you need mobility during the migration, make sure your 5508 is on the supported code and you have defined mobility between the two.
Note:
You can also define ap authorization list and use the local db. This way you define the mac address of the ap's you want to test/allow on the controller.
02-24-2023 09:37 AM
- Adding to other very useful reply : you can at any stage ( but advised before production too) checkout your WLC 9800 configuration with the CLI command : show tech wireless , have the output analyzed by https://cway.cisco.com/
M.
02-24-2023 09:59 AM
Thank you Marce. I will make sure of this procedure.
02-24-2023 09:59 AM
I will put my story once the activity has been completed.
02-24-2023 09:43 PM
What are the models of the AP?
02-28-2023 02:21 AM
Hi Leo,
provided models:
WLC:AIR-CT5508-50-K9
APs: C2702, C3702, C2802 and C3802. We will be replacing the 27xx and 37xx by early next year but not before the WLC migration to 9800.
02-25-2023 08:16 AM
And to answer your other question - rolling AP upgrade only applies to APs already on the 9800 WLC not migrations.
Also check the TAC recommended code and best practices guide below. Check the compatibility matrix for your APs too. If you're configuring mobility with the 5508 make sure to use 8.5.182.105 (link below).
02-28-2023 04:25 AM
One more query as a concern raised by my customer.
When I upgrade SSO HA 9800 WLCs, Can I still control the AP image upgrade in staged manner. When I go through the documentation, it was mentioned with N+1 scenario only.
Thank you for all your expert advise.
02-28-2023 09:30 AM
>....When I upgrade SSO HA 9800 WLCs, Can I still control the AP image upgrade in staged manner
Best is to enable the ISSU check box in the WebUI upgrade page. The new software is then downloaded to both controllers. AP predownload then happens. Then both controllers upgrade to the new version one after the other (so that APs always stay joined to one of them). The APs are then joined to WLC running a different software version (which was not possible in aireos) and keep operating. The WLC then reboots APs progressively wave by wave so that they come back with the new version. Neighboring APs are not rebooted at the same time so that there is always one AP to service clients in a given area therefore providing zero downtime. The clients do not even notice anything because if they support 802.11v because the AP sends them an order to move to another AP before rebooting. If the client does not support 802.11v they might be disconnected briefly until they connect to another access point ,
M.
02-28-2023 09:41 AM
HI Marce, the ISSU document says it does not support between major release? In such a case how I leverage the advantage of staged AP upgrade? The customer has vast number of APs and they wan to control AP upgrade during minor/major or maintenance release upgrade.
02-28-2023 09:48 AM
Wait... are you migrating from 5508's to 9800's? Because that would be a manual migration which was covered previously in this thread. If you are upgrading a set of 9800's then that is a different story and different ways to accomplish that.
02-28-2023 10:19 AM
I will raise a new thread for that.
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