Live Upgrades

Live Upgrade Services

The Live Upgrade and Firmware Management services in Aruba Central provide seamless upgrade of APs and gateway devices. The Live Upgrade service provides the following functions:

• Upgrades APs, gateway clusters or both
• Selects the required device firmware from a list of available versions
• Allows to schedule upgrades up to one week in the future
• Provides visibility of the upgrade progress
• Allows upgrade of multiple groups in parallel
• Allows termination of upgrades in the middle of the upgrade process

The Firmware Management service provides the user interface and other existing functions like firmware compliance and scheduled upgrades. The service also interfaces with the devices to initiate upgrades and receive upgrade status. The Live Upgrade service provides APIs to the Firmware Management service to initiate or abort live upgrades and decides the logic to orchestrate the upgrade process and the time of upgrade for the devices.

AP Live Upgrade

The Live Upgrade service enables the upgrade of APs without disrupting the connection of the already existing clients and reduces the upgrade duration by running parallel upgrades. The Live Upgrade service interfaces with the AirMatch service to partition all the APs that require upgrade into multiple smaller sets of APs that can be upgraded in parallel and each batch of APs will go for reload sequentially. AirMatch partitions APs based on RF neighborhood data such that neighboring APs are available for clients to roam to when the associated AP is undergoing an upgrade, so all the APs in one AP partition are in the same channel and are not in the same RF neighborhood.

To reduce WAN bandwidth consumption and upgrade duration, a set of APs, known as seed APs, are selected. Only these seed APs download the images directly from the Aruba Activate server. The rest of the APs download the image from its designated seed AP. Seed APs are selected based on the following considerations:

• A non-seed AP is L2 connected to its designated seed AP.

• A non-seed AP is of the same platform model as its designated seed AP.

• Not more than 20 non-seed APs are assigned to a given seed AP.

• Seed AP is randomly selected out of APs which are L2 connected and have same model type.

The following image shows the background process when an AP undergoes the Live Upgrade workflow.

The AP Live Upgrade workflow is as follows:

1. When the scheduled time arrives, the Firmware Management (FM) service sends the AP group details to the Live Upgrade service. The upgrade time can either be the current time or a scheduled time within a month.

2. The Live Upgrade service stores the AP list in the AP group and sets all the APs in the list, in the upgrade INIT state.

3. The Live Upgrade service retrieves the subnet information of the APs from the monitoring module in Aruba Central.

4. The Live Upgrade service selects seed APs based on seed AP selection criteria, and assigns a designated seed AP for each non-seed AP.

5. The Live Upgrade service retrieves the AP partition information from the AirMatch service.

6. The Live Upgrade service initiates an image upgrade of all the seed APs and sends the request to the FM service.

7. The FM service sends an image upgrade request to all the seed APs.

8. All the seed APs download the image from the Activate server.

9. After downloading the image, all the seed APs send upgrade responses and states to the FM service.

10. The FM service forwards the responses and states of all the seed APs to the Live Upgrade service.

11. The Live upgrade service initiates an image upgrade of all the non-seed APs and sends the request to the FM service.

12. The FM service sends an image upgrade request to all the non-seed APs.

13. All the non-seed APs download the image from their designated seed APs.

14. After downloading the image, all the non-seeds APs send upgrade responses and states to the FM service.

15. The FM service forwards the responses and states of all the non-seed APs to the Live Upgrade service.

16. The Live Upgrade service initiates the reboot for the first AP partition and sends the request to the FM service.

17. The FM service forwards the AP reboot request to all the APs in the AP partition, and all the rebooted

18. APs send reboot responses to the FM service after rebooting.

19. The FM service forwards reboot responses and states to the Live Upgrade service.

20. Remaining AP partitions are rebooted in sequence

Rebooting Access Points

After all the APs finish downloading the image, the Live Upgrade service starts the AP rebooting process. All the APs in one AP partition reboots at the same time. After the Live Upgrade Service receives updates on successful reboot of all the APs in the partition, the service initiates the reboot process for the next AP partition. This process is repeated until all the AP partitions reboot and come up with the new image.

The following is an example workflow of an AP reboot process:

1. The Live Upgrade service sends the AP reboot request for a specific AP partition to the FM service.

2. The request is sent to every AP in the partition.

3. After receiving the reboot request, each AP disables all its radios.

4. All the clients associated with the AP are unable to ping the AP and forced to roam to the neighboring APs.

5. All the neighboring APs associated with the clients perform a session sync with their previously associated AP.

6. The AP starts rebooting a few seconds later.

Upgrading a Gateway Group

As gateways in a gateway group are much smaller in number, seeding and partition concepts are not necessary. To reduce upgrade duration, all the gateways in a cluster are instructed to download the image together. However, they are reloaded sequentially to avoid disruption. As only one gateway is reloaded at any given time, remaining cluster members together need free capacity for clients of only one gateway.

The Cluster UDG (User Anchor Gateway) concept ensures that all the users on a gateway are assigned standby UDG. The user state and Datapath sessions are synced to the standby UDG. When a gateway reloads, cluster failure detection logic detects the failure within a second and moves users to the standby UDG. With multi- version support added, when a gateway reloads with a new firmware version, it rejoins the cluster and can sync the user state and sessions with the cluster members running an older version. Users are not disrupted during the gateway upgrade process.

The gateway Live Upgrade workflow is as follows:

1. The FM service applies all the configured compliance rules which include gateway group names, the firmware version to which the gateway group needs to upgrade, the time at which the group needs to upgrade. The upgrade time can either be the current time or a scheduled time within a month.

2. When the scheduled time to upgrade arrives, the FM service sends the gateway group details to the Live Upgrade service.

3. The Live Upgrade service stores the gateway list in the gateway group and sets all the gateways of the list in the upgrade INIT state.

4. The Live Upgrade service initiates an image upgrade of all the gateways in the group and sends the request to the FM service.

5. The FM service sends the image upgrade request to all the gateways.

6. All the gateways download the image from the Activate server.

7. After downloading the image, all the gateways send upgrade responses and states to the FM service.

8. The FM service forwards the responses and states of all the gateways to the Live Upgrade ser-vice.

9. The Live Upgrade service initiates the reboot request to one of the gateways and sends the request to the FM service.

10. The FM service sends the reboot request to the gateway.

11. The gateway reboots.

12. The gateway sends reboot responses and states to the FM service.

13. The FM service forwards the reboot responses and states to the Live Upgrade service.

14. The rest of the gateways in the group are cycled through the reboot process in sequence.

The following image explains the Gateway Live Upgrade workflow:

Upgrading a Device Image

You can upgrade a device or multiple devices under the Firmware tab in Aruba Central. Any configured device group can be upgraded together or individually.

There are two upgrade types:

1. Live Upgrade

2. Standard

The default upgrade type is Standard. In this upgrade type, all the devices under the selected group download the images directly from the Aruba Activate server and reboot simultaneously. There is no consideration for reducing disruption to the network.

To perform Live Upgrade, set the upgrade type to Live Upgrade.

Firmware compliance configuration parameters:

• Groups: You can choose All Groups, a single group, or a combination of groups

• Firmware version: This is the target firmware version for the selected devices. There are three choices:

  • Choose a specific build number from the drop-down list.

  • Enter a custom build number, for example, 10.0.0.1_74637, and click Check Validity to validate the build number.

  • Set to None. When you set the option to None, set the compliance status as Not Set as you see in the screen capture. When you want to upgrade a device to a specific firmware version from your FTP server instead of Aruba Central, ensure that the Compliance Status is Not Set for the group to which the device belongs. Otherwise, Aruba Central automatically upgrades the group to the configured firmware version in Aruba Central and overrides the firmware version downloaded from your FTP server.

• Upgrade type

  • Standard (default type)

  • Live upgrade

• Upgrade time

  • Now

  • Later date: Firmware upgrade can be scheduled at a future time from the time of upgrade configuration up to one month later.