Hitless Software Upgrade (n + 1 Upgrade)

[Nikita Desjardins]

Ivebeen reading software architecture in practice and I have encountered the term hitless in-service software upgrade on chapter 5 page 92.What does a hitless upgrade means in the context of faults, failures and the recovery from there?Maybe my less understanding stem from not being a native english speaker.I have googled for an answer and did not find one.thanks.

The term seems to be used for network hardware such as routers and switches, and means that the firmware can be upgrade without any downtime, dropped packets or connections, or ports being unresponsive.

Hitless upgrade thus means "upgrade without any degradation of service or performance". For a hypothetical scenario, imagine you are playing a video game and want to upgrade your graphics card at the same time. A hitless upgrade would be if you managed to do that without ever interrupting the game or even reducing the frame rate.

This is typically done by exploiting redundancy (at least temporary). You either already have two services running for redundancy anyway, or you temporarily start a second one. You upgrade one of them, seamlessly switch over, then upgrade the other. A real-world example: most devices that have two power supplies are actually designed to run with only one. So, you can upgrade the power supplies by pulling out PSU #1 and replacing it, then pull out PSU #2 and replacing it, without ever having to turn the equipment off.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

First, a set of candidates are selected based on nearby APs information. Rolling AP Upgrade algorithm selects the configured percentage of APs to be upgraded in each iteration while it maintains RF coverage

Clients on the candidate APs are steered to APs which are not in the candidate list before the candidate APs are rebooted. If the clients still persist on the candidate APs, they are sent a de-authentication frame and the AP reloads with the new image.

2. Initiate the upgrade on the controller. Enable the hitless upgrade option as well. Optionally, enable Fallback after upgrade so that the APs move back to the parent controller (without a swap and reset) after activation of the new image and reloading of the parent controller.

This command moves the APs to the specified destination WLC with a swap and reset command. Swap command interchanges the AP image so that the target code is marked primary image for the APs whereas reset command reloads the AP. It is assumed that the destination WLC is on the same version as the APs backup image.

Optionally, one can use the fallback keyword to enable Fallback after Upgrade option so that the APs move back to the parent controller (without a swap and reset) after activation of the new image and reloading of the source controller.

7. If one has not enabled Fallback after Upgrade option (as mentioned in Step5) use this command on destination WLC to move back the APs to the source WLC, once the source WLC is upgraded to the latest code.

When you perform a software upgrade, you need to follow the paths presentedin these Release Notes and use the same image types to achieve a hitless upgrade. Thisapplies to both HA and non-HA deployments. The paths are presented below. An example ofdifferent image types is upgrading a non-LI deployment with an LI image. Suchnon-hitless upgrades require that you reboot devices per your upgrade procedure, andthen reboot all upgraded devices again to establish the new deployment type.

The Deployment page allows you to change the software version, stage, and deploy the configuration across your network after the sites are configured. You can upgrade the SD-WAN software version on all the appliances and sites across the network.

When you restore the previous version, Citrix SD-WAN Orchestrator service initiates a network-wide activation of the previous configuration and restores the previously activated configuration (and/or software) on your network. To restore the previous version, on the Deployment page, navigate to Settings and select Restore Previous Version.

SD-WAN Configuration Editor and SD-WAN Center are superseded by Citrix SD-WAN Orchestrator service. Citrix SD-WAN Orchestrator service supports all configurations that are currently done through SD-WAN Configuration Editor.

In Citrix SD-WAN Orchestrator service, the auto-correction feature is implemented as part of the change management workflow.When the staging fails for a site, and if the site is a control node, you need to restage the site after getting the staging failure message. The Activate now option will not be enabled if the staging fails for the control nodes. If the site that has failed staging is a branch node, you are still allowed to proceed with the activation. But to bring that branch in sync with the network, perform another round of change management.

With the auto-correction feature enhancement, when a staging failure happens, the auto-correction mechanism pushes the expected software and configuration version to the failed branch and tries to bring it up in sync with the current network. The auto-correction feature is applicable for staging failure on the branch node and activation failure on any node.

To troubleshoot an appliance manually, enable the Maintenance Mode check box under Change Management Settings. This check box is used to control if the device needs to be checked for auto-correction or not. Once the maintenance mode check box is cleared, auto-correction brings the appliance in sync with the network software and configuration version.

During software upgrade (11.0.x and earlier versions), the staging, and activation of all the appliances in the network are done at the same time. This includes the High Availability (HA) pair, leading to network downtime. With the HA near-hitless software upgrade feature, the Citrix SD-WAN Orchestrator service ensures that the downtime during the software upgrade (11.1.x and above) process is not more than the HA switch over time.

Step-1: During software upgrade, after the SD-WAN 11.1 release, the Citrix SD-WAN Orchestrator service first performs software upgrade on all the appliances that are in the Standby state across the network. The network is still up and running with the Active appliances in place.

In the case of a configuration-only update, only the sites that have configuration changes are staged and activated. For the remaining sites, the timestamp is updated and processed. The control nodes will get a package staged even if there is no change to the site configuration.

The Sites View section provides details about all the devices in the network. The table contains the role of each site, the appliance details, deployment status, Citrix SD-WAN Orchestrator service connectivity status, software version of each appliance, and a timestamp of the running configuration. If the staging process fails at any site, use the Retry Staging (Primary Device) option, under the Actions column, to reinitiate the staging process. For HA appliances, both the options Retry staging (Primary device) and Retry staging (Secondary device) are available.

You can export the site view details into a CSV or PDF file by using the Export as CSV and Export as PDF options. The downloaded CSV and PDF file name is prefixed with Site List followed by the date and time of the file export.

The Deployment History section provides the status of the previous deployment operations and results. If a partial site upgrade is enabled, the section categorizes the sites based on the software version that the appliances are configured to run. If the last activation fails, you can even view details of the failure by clicking the number link on the Failed column.

Once you click the number link in the Failed column, the Reason for Failed Sites page is displayed. This page provides details such as site name, software version, appliance edition, and an error message mentioning the reason for the failure.

You can export the deployment history details into a CSV or PDF file by using the Export as CSV and Export as PDF options. The downloaded CSV and PDF file name is prefixed with Deployment History followed by the date and time of the file is export.

The Change Management Settings View section helps to troubleshoot an appliance manually. Enable the Maintenance Mode check box. This check box is used to control if the device needs to be checked for auto-correction or not. Once the maintenance mode check box is cleared, auto-correction brings the appliance in sync with the network software and configuration version.

Click Verify Configuration at the top right corner of the Deployment page to validate the network configuration and check for any audit error or warning. The Configuration results page is displayed.

3a8082e126