I'm trying to find out how to best replace two active 4404's with a WiSM while providing minimal client downtime, and would appreciate some input on my two solutions to help determine which is best.
The WiSM is currently on the live network with no APs associated. It has different management, ap-manager and interface addresses, all on the same subnets as the 4404's. The WiSM is also configured with a different mobility group and hostnames. Other than that, the configuration is exactly the same between the WiSM and the two 4404 controllers.
The original plan was that on a scheduled downtime I would shut off the 4404's, then change all the WiSM IP addresses and hostnames to match that of both controllers, then reboot the WiSM controllers so the AP's associate to the WiSM with minimal issue.
The only problem with that is, while changing the IPs and such, the wireless network will of course be down.
Another plan is that I restrict all vlan traffic that the WiSM uses (on the LAG port-channels) to ensure nothing can 'see' it, while keeping it online. Then I will change the IP addresses and mobility groups to match that of the 4404's while they are still online. This way when it comes to the cutover date, I can just shut off the 4404's, allow vlan traffic to the WiSM, and then just reboot the WiSM. Downtime will ideally be only a few minutes.
So far I'm leaning toward the second alternative, but what I am not sure of is that this would actually work. From my understanding, with Vlan traffic being blocked on the port-channels I can still talk to the WiSM if I allow only the wism service-vlan to get through, but nothing else will be able to see it (APs, 4404's, etc). This will prevent issues with duplicate IP addresses. Am I correct in my understanding?
Thanks for any input on this.
See if this helps you
As you have configured your WiSM with diffreent ip addresses then your current 4404 controller but in same subnet you can configure WiSM and 4404 in same mobility group.
Then you can go to your APs and configure primary controller as WiSM and secondary as 4404 but do that one by one on each AP and let APs move one by one to your WiSM. Once WiSM has all the APs obviously client will also roam on APs on WiSM with very few seconds of downtime.
Once all APs and client have moved to WiSM then you can remove 4404 from mobility group and then take it out of network. At this moment all APs and client are now in WiSM. Then you can change the ip address of management interface as the same what you had on 4404 controller and if possible do not change ap-manager interface ip adress as this may lead to AP reloads.
You may keep your ap-manager ip address as same and change other interface ip addresses one by one what you had on 4404. This way your downtime will be very less.
*Pls rate all helpfull post
Thank you for the great reply Ankur. I have a couple questions based on it.
Will each AP need to be rebooted after setting the primary/secondary controller configuration? The way you worded it made it seem like they will move to the WiSM on their own over time.
Also, does setting the primary controller manually as the WiSM override the hostnames? Currently the hostname of one of the 4404's is CISCO-LWAPP-CONTROLLER and I know that DNS is a vital part in getting an AP to associate properly.
One (hopefully minor) thing I forgot to mention is that the 4404's and the WiSM are on different software versions so there will be a firmware download when the APs associate to the WiSM (1010 and 1020 APs). The WiSM is on 4.2 and the 4404's are on 4.1. Will this cause any trouble besides an increase in downtime due to the firmware downloads?
If you have configured the 2 controllers in same mobility group then when you confirm primary controller , secondary controller under AP detail you do not need to reload the AP and they themself will move to the primary configured controller.
Also when you configure primary and secondary controller name under AP detail you have to configure system name of controller and it is nothing related to DNS at this point.
As you mentioned WiSM is running 4.2 release when AP will move from 4400 controller to WiSM it will start downloading te new image and once new image is downloaded it will reload and join back WiSM only.
So I will recommend you to configure mobility group first and then perform this task on one AP first and then observe the behavior and then you can start with other APs one by one.
*Pls rate all helpfull post
I have considered what you have suggested in order to perform the cut-over.
One issue I see with that is I have to perform these changes to 1 AP at a time. Due to the fact that they all have to perform firmware upgrades, I do not feel that this would be the best option as it can take up to 3-5 minutes for each AP to come back online.
I run 132 access points at this time, so it will pretty much take most of the day to get the campus fully cut-over using this method- all the while there will be seemingly 'random' (as the students/staff see it) connectivity issues through the campus.
In my situation I feel it is probably best to do a planned outage period, during which the change is made to all accesspoints at the same time.
If such is the case, what is your input on the first two suggestions I posted about?
Be careful and be sure to read the caveats for the 4.2 code as it relates to the WISM. There are a lot of known bugs with the 4.2 code. We've seen some random reboot loops after WISM's with 4.2 was loaded. You might be better off downgrading back to 220.127.116.11.
Ankur's comments (using the same mobility group and changing the primary controller) are right on the mark!
As far as the DNS entry, all you need to is point the DNS entry to ANY controller that is in the same mobility group. The DNS entry is only referenced when an LWAP is booting up if it cannot connect to its last-connected controller. If you are going to be decommissioning the 4400 controllers, then you could simply change the DNS entry to point to one of the controllers on the WiSM blade.
Please keep in mind that you must be on the same mobility group (and this includes more than just setting up the mobility group name, but also setting up the IP/MAC address of each controller in every other controller) or changing the primary controller of the AP will have no effect. Populating the Mobility Management table may be obvious to those who are intimately familiar with mobility groups but we got snagged on this once.
You can always test the migration of ONE AP to the WiSM by changing the primary on only one AP.
Also, if you were not already going to do so, you can use Access Point Templates to save time and change the primary controller settings on the APs in bulk.
As far as the 4.2 stability issue goes, we are currently using in an installation approximately twice the size as yours and have not had any major headaches. That said, I think that it works better if the controllers are upgraded to 4.2 first with no LWAPs on them - which it sounds like you have already done.
I hope your migration goes well!
(Please rate helpful posts)
I would like to add the following question:
Since we are ready to implement/install/configure the Wism and replace the current 4404 wlc, would you recommed all the above steps or is there any better strategy to be followed?