Prime AP Migration Tool - Part 1

Mark at IPTel is sharing some of his scripts to help with controller upgrades! Check it out and let us know what you think!  

This article is the first in a series dedicated to how to upgrade your Cisco WLCs within the minimum of client impact. This article provides the background and pre-requisites, with further articles detailing the process. In addition, IPTel have provided the AP migration tool to make life easy to transfer APs from one WLC to the next.

If you've not see the other two articles in this series, you can catch up with the two links below - check the caveats, hints and tips before you start any upgrades:

• Prime AP Migration Tool Part 2: Details on how to upgrade, using the free IPTel supplied tool
• Prime AP Migration Tool Part 3: Caveats, Hints and Tips on WLC code upgrades

The tool can be found on this link: https://www.iptel.com.au/ap-migration-tool.html

If you don't like having all your eggs in one basket, you'll have deployed your Cisco WLAN controllers in SSO mode and now discovered when you do an upgrade that they both reload, one after another. In this article we explore what you need to do to perform a seamless upgrade, with virtually no client impact on a Cisco WLAN Controller. Firstly, you need to take into account a couple of pre-requisite factors: Ensure you have a spare controller Use the Prime AP Migration Tool to move APs around

The bad news is that you need some spare hardware - if you have only a single controller or only a HA pair (in SSO mode) then you can’t do a seamless upgrade. 

When you upgrade the HA pair it copies the new code between the WLCs and reloads each in turn – you’re in for a 15 – 20 minute outage.

The process is even worse if you've not done a pre-upload of code to your APs prior to the WLC code upgrade – once the WLCs are operational on the new code, the APs will join, download, reload onto the new code and join again. The network is going to be unstable while this process occurs.

High Availability (HA)

Firstly, let's have a quick segway onto the issue of High Availability. If you've got one WLC and it goes offline, you're, well offline. If you happen to have a spare WLC handy AND a copy of your config, all good. You can restore the failed controller and maybe have 3 - 4 hours of downtime.

Don't have a spare onsite, and oops, don't have the recent config? You're in real trouble - it could be days or weeks until you return to service.

The HA part codes from Cisco are much cheaper than the fully licenced controllers and inherit the licence once connected - you now have completely seamless fail over (depending on the code version you're running).

That's the good news. The bad news is that you essentially have one single unit, just operating across two pieces of hardware. Make a config error on one and you've just made it on both. There's an outside chance of a bug taking both out at once, but in any case, when you do a code upgrade they will both reload.

The answer to this is a spare controller.

Spare Controller

To overcome this for sites which cannot have any interruption in service, we have developed designs and techniques. The first stage is ensuring you have a spare controller in the network. Fortunately due to Cisco licencing, you can buy the minimum priced HA unit and use this as an HA secondary; once in HA secondary mode (with SSO disabled) it will licence itself for the full number of APs – but only for 90 days (after which there’s a ‘nag’ message).

In addition to providing a holding platform during code upgrades, adding a Spare controller also adds to the overall resilience of the network. We normally configure this as the secondary controller on each AP; it can act as a secondary to multiple primary HA pairs of controllers (you need to configure this for each AP though).

Holding Platform

Once the Spare WLC is in place as the holding platform, you’re all set to be able to do seamless upgrades. The basic premise is to gradually move all APs from the current WLC (or HA pair) to the spare platform. Gradually moving the APs mean any clients will just roam when the AP disappears during the move. To reduce the impact even further, randomise the order in which APs are moved, so you only move one AP at a time in a particular area.

The Prime AP Migration tool is designed to perform just this task – work out a randomised list of APs to change their primary controller to be the spare – they are then rebooted and the AP reconnects on the spare WLC.

Liability Disclaimer 

We supply the tools on this website free of charge for the wireless community use. Note with all our tools the liability disclaimer – we do our best to make these tools as useful as we can, but accept no liability for their use or misuse:

https://www.iptel.com.au/terms-and-conditions-for-usage-of-provided-tools.html