We're a hospital with high availability wireless requirement, including Vocera VoIP communicator badges. We want to upgrade to new 3502 APs but first need to migrate 8 production 4402 WLCs all in the same Layer 2 mobility group from 4.2.61 to 7.0.98 which requires 3 reboots (2 step version upgrade plus boot code upgrade). Can we temporarily mix different WLC versions during the upgrade process within the same mobility group without totally blowing up our very stable wireless environment? I want to upgrade one WLC at a time after first moving the access points (one at a time) to an upgraded controller so as make the upgrade of our 170 LAP1121 AP's as transparent as possible to our users. I already have two additional spare WLC 4402s running the 7.0.98 code but I have them defined with a different mobility group name. I'm having VERY intermittent, infrequent Vocera VoIP call establishment issues when trying to connect badges across the different mobility groups, so I'm thinking I might have better luck if I just put them all in the same mobility group during the upgrade though I understand the cross-version isn't supported. Will different version within the same mobility group work for the two or three days that I anticipate this upgrade will take, or am I playing with fire? Thanks!
From controller release 6 there is better migration strategy mainly with preloading the new code to the aps. I havent done this yet but that will help from code 6
Mobility groups may exist with mixed coide versions but roaming is not supported, which kind of negates the whole mobility group issue. Having two seperate mobility froups will mean that the vocera badges have to deauthenticate then reauthenticate to the new mobility group.
I cannot see an easy way to achieve your objectives without a scheduled outage.
Another thing to consider is that there is a change from LWAPP to CAPWAP and I have noticed this makes the upgrades longer.
I realise you are a hospital and would suggest that code 18.104.22.168 is a little new!! Code 22.214.171.124 is assurwave code.
How many access pints do you have per controller. You may be able to get the whole lot done in an hour at a oush and with help but thats not allowing for any issues. I think that when you are at code 6 it will be easier with access point pre loading.
If I can temporarily run different versions within the same mobility group, I'm OK with the loss of mobility; I can live with re-authentication when crossing a controller boundary for duration of the upgrade. It is more important that I can establish reliable communications between wireless endpoints across the controller boundary during the upgrade.
The pre-loading is a helpful feature but my 1121G AP's are not on the list of APs that support this feature, probably because of memory limitations, and obviously you have to get to ver 6 first.
Based on my testing and what I've seen/heard Ver 7 is virtually the same as the AssureWave 6.0.196 with respect to my old B/G 1121 APs; the whole point of this exercise is to get Ver 7 so we can begin the slow process of moving from the 1121 to the 3502 AP platform.
All seven WLC4402-25 are fully loaded with 24 or 25 APs. Those APs have to be "parked" on a different controller for the duration of the multi-step upgrade so as to preclude the issue of AP image corruption that I've read about on this forum (and to also NOT waste the time of upgrading them twice[4.2.205 first, then 7.0.98]).
As we have a backup Ver 4.2.61 WLC 4402 and two Ver 7.0.98 WLC 4402 I can conceivably upgrade two WLCs at a time while the APs are parked on the spare controllers, but I certainly can't do them all at once.
So, it boils down to the question: can I temporarily run different versions within the same mobility group to facilitate my upgrade process? Thanks for all contributions!
Transferring Crash file from standby: Login to the Active WLC in HA.
From CLI: (Cisco Controller) >transfer upload datatype crash (Cisco
Controller) >transfer upload filename (Cisco
Controller) >transfer upload mode tftp (Cisco Controller) >transfer
This is the start of a display filter cross reference between Wireshark
and OmniPeek. The 1st installment is a table of advanced filters. More
filters will be added as time allows. It is a living doc, so check back
for changes every so often Please feel f...