FAQs
High availability
What is the difference between High Availability and Secondary (Geo) appliance?
- High Availability ensures fault tolerance. Secondary (Geo) appliance enables disaster recovery.
- High Availability can be configured for the MCN, RCN, and branch appliances. Secondary (Geo) appliance can be configured for MCN and RCNs only.
- High Availability appliances are configured within the same site or geographical location. A branch appliance in a different geographical location is configured as Secondary (Geo) MCN/ RCN appliance.
- High Availability primary and secondary appliance should be the same platform models. The Secondary (Geo) appliance might or might not be the same platform model as the primary MCN/RCN.
- High Availability has higher priority over secondary (Geo). If an appliance (MCN/RCN) is configured with High Availability and Secondary (Geo) appliance, when the appliance fails the secondary high availability appliance becomes active. If both the high availability appliances fail or if the Data Center site crashes, the secondary (Geo) appliance becomes active.
- In High Availability, the primary/secondary switchover happens instantaneously or within 10-12 seconds depending upon the high availability deployment. The primary MCN/RCN to secondary (Geo) MCN/RCN switch over, happens after 15 seconds of the primary being inactive.
- High Availability configuration allows you to configure primary reclaim. You cannot configure primary reclaim for Secondary (Geo) appliance, the primary reclaim happens automatically after the primary appliance is back and the hold timer expires.
Single step upgrade
Note
The WANOP, SVM, and XenServer Supplemental/HFs are seen as OS Components.
Should I use .tar.gz, or single step upgrade .zip package to upgrade to 9.3.x from my current version (8.1.x, 9.1.x, 9.2.x)?
Use the .tar.gz files of the concerned platforms to upgrade the SD-WAN software to 9.3.x. After the SD-WAN software is upgraded to 9.3.x version, perform change management using the .zip package to transfer/stage OS component software packages. After activation, the MCN transfers/stages OS components for all the relevant branches.
After upgrading to 9.3.0 using single step upgrade package (.zip file) do, I need to perform.upg upgrade on each appliance?
No, OS software update/upgrade will be taken care by the single step upgrade .zip package and it is installed as per the scheduling details provided by you in the Change Management Settings of the respective sites.
Why should I use .tar.gz followed by .zip package to upgrade from earlier than 9.3 to 9.3.x, and why not directly use .zip package of 9.3.x?
Single Step upgrade package is supported from 9.3.0.161 onwards and on earlier release versions (prior to release 9.3) this package is not recognized. When the single step upgrade .zip package is uploaded into the Change Management inbox, the system throws an error stating that the package is not recognized. Hence, first upgrade the SD-WAN software to 9.3 or above version and then perform Change Management using the .zip package.
How will the OS Components be installed through single step upgrade, if.upg upgrade is not performed?
The MCN will transfer/stage OS components software packages based on the appliance model, after the Change Management is completed using single step upgrade .zip package. After activation, the MCN starts transferring/staging the OS components software packages for the branches that need them for the scheduled update/upgrade.
How do I install OS components, without scheduling for later installations?
Set the Maintenance Window value to ‘0’ for instant installation of the OS components.
Note
The installation starts only when the appliance has received all the package that is needed for the site, even when Maintenance Window value is set to ‘0’.
What is the use of scheduling installation? Can I use schedule instructions to upgrade VW alone?
Scheduled installation was introduced in SD-WAN release 9.3, and is applicable for OS components only and not for VW software upgrade. With single step upgrade, you need not log into each appliance to perform OS components upgrade and the scheduling option allows you to schedule the OS components installation at a different time other than VW software version upgrade.
Why does the scheduling information in Change Management Settings page appears past schedule date by default and what does it mean?
The Change Management Settings page displays the default scheduling information that is, ‘”start”: “2016-05-21 21:20:00,” “window”: 1, “repeat”: 1, “unit”: “days”’. If the date is a past date it means that, the scheduled installation is based on the time and other parameters like maintenance window, repeat window, and unit and not the date.
What is default schedule installation date/time set to, is it generic or local appliance dependent?
By default the scheduling details is set as ‘2016-05-21 at 21:20:00 (Maintenance window of 1 hour and repeated every 1 day)’. This detail is local appliance site dependent.
How can I install OS Components immediately without waiting for the maintenance / scheduled window?
Set the Maintenance Window value to ‘0’ in Change Management Setting page, this overrides the scheduled installation time.
Which package I should use for upgrade when current software version is 9.3.x or above?
Use single step upgrade .zip package to upgrade to any higher versions when the current software version 9.3.x or above.
When does the OS Components files get transferred/staged to the branches?
The OS components files are transferred/staged to relevant branches after the activation is completed when Change Management is done using single step upgrade .zip package to upgrade the system.
Which appliances receive OS Components files, Is it platform dependent or all branches receive it?
Appliances that are hypervisor based, such as SD-WAN – 400, 800, 1000, 2000 SE and Bare metal SD-WAN - 2100 running on EE license will receive OS components to upgrade.
How does scheduling work?
By default the scheduling details is set as 2016-05-21 at 21:20:00 (Maintenance window of 1 hour and repeated every 1 day) and it implies that the system will check if new software is available for installation every day as repeat value is set to 1 days and will have maintenance window of 1 hours and the installation will get triggered/attempted (if new software is available) at 21:20:00 (local appliance time) effective from 2016-05-21
How do I get to know if the OS Components have been upgraded?
In the Status column, you can see a green tick mark. On hovering over it, you can see the Upgrade is Successful message.
How can I schedule installation of OS components for RCN and its Branches?
Scheduling for RCN is performed from the MCN Change Management Settings page. For RCN branches, you need to log into respective RCN and set the schedule details.
From where can I get the status of scheduled installation?
Status of scheduled installation for RCN can be obtained from the MCN Change Management Settings page. For RCN branches, you need to log in to respective RCN to get the status.
How do I get status of scheduled installation?
Use the refresh button provided on the Change Management Settings page to get status from MCN, and RCN for Branches in Default Region and RCN respectively.
Can I use tar.gz file to upgrade to next release, when single step upgrade was used for previous software upgrade?
You can use tar.gz file to upgrade, but it is not recommended because you can perform software upgrade by using the.upg file. Upload to upgrade operating system (OS) component software by logging into each applicable appliance. From release 9.3 version 1, the Update Operating System Software page is depreciated. As a result, you can perform change management by using the .zip package to upgrade OS components.
How can we validate the current running versions of OS Components?
Now you cannot validate the current running versions of OS components from the UI. You can log in from each console or get STS to view this information.
What difference it would make if I have bare metal appliances in my network? Does scheduling impact bare metal / Virtual appliances?
Bare Metal appliances like SD-WAN – 410,2100,4100,5100 SD-WAN run only SD-WAN software. Bare metal appliances do not need OS components packages. These platforms are treated on par with SD-WAN VPX-SE appliances in terms of software need. The MCN will not transfer OS components packages to these appliances. Setting scheduling information will not take effect for these appliances, because they do not have any OS components that need upgrade.
How does SSU work in high availability environment / deployment?
In high availability deployment at MCN, we have a limitation, where the active MCN switch’s/toggles the role of primary MCN during Change Management and Standby/Secondary MCN takes over. In this case, you can perform Change Management once again with the .zip package on the active MCN for the packages or you can switch back to primary MCN by toggling the role of active MCN so that original primary MCN can take up the role for the OS components packages to be staged to other branches.
How does single step upgrade work in high availability environment / deployment?
While performing single step upgrade in high availability deployment, the role of the primary MCN and the Standby MCN is toggled. This is a limitation. If this happens, perform Change Management again with the .zip package on the active MCN. Alternatively, you can switch back to the primary MCN by toggling the role of the active MCN so that the original primary MCN can stage OS components packages to the branches.
Is single step upgrade support for zero-touch deployment to restart strap the appliances?
Yes, it can be used.
Can I use single step upgrade to upgrade my standalone WANOP appliance?
No.
Can I use single step upgrade to upgrade standalone WANOP appliance deployed in two box mode?
No. Only SD-WAN appliance which is part of two box mode would be upgraded and not the WANOP standalone appliance.
Which package should I use to upgrade to multi-tier network?
Use the single step upgrade package ns-sdw-sw-<release-version>.zip file when the current software version is 9.3.x or above. MCN takes care of staging package to RCN and RCNs stage software package to its respective branches.
After uploading the ns-sdw-sw-<release-version>.zip file, I am seeing only one platform model under current software?
From release 10.0, support for scale architecture is introduced to speed up processing of single step upgrade. You can see only the MCN platform model under current software. Other appliance packages are listed/displayed/processed when you choose the Verify or Stage Appliance button.
For VPX/VPXL/bare metal appliances, which packages are staged for RCN?
Package is staged to RCNs because RCNs Branches can be of any platform model. Hence they need all packages.
How does my branch site behind the RCN obtain OS component packages if RCN is a VPX appliance, and branch is an appliance that needs these packages?
RCN stages the relevant package to the branch that needs the OS component packages after activation of SD-WAN VW software package.
Can I choose Ignore Incomplete during staging and proceed to next stage of change Management? What impact does it have for sites that have not completed staging when this button is selected?
Yes, you can click Ignore Incomplete. This enables Next button and the Progress bar is displayed. This option is provided for scenarios where the site is not reachable and change management is still waiting for staging to complete for those site, so users can proceed to next stage by ignoring the stage state and proceed to activation. After the site comes up, MCN stages the package after completion of activation.
Partial software upgrade
What is partial site upgrade and how can I use it?
Partial site software upgrade is a new feature introduced in release 10.0. You can stage newer version of release 10.x from the MCN and activate staged software version from Local Change Management page on selected sites/branches. Before activating staged software on site/branch, ensure that check box is enabled from MCN.
- This feature is disabled by default. The existing correction mechanism keeps the network in sync. The user has to choose to allow partial site upgrades by enabling a check box on the Configuration > Change Management Settings page.
- Partial Software Upgrade can be done only on a Branch or RCNs and not at the MCN.
Below is the usecase/scenario when partial site software upgrade can be used:
Validate if a software patch with relevant changes is compatible and working for a specific site (where partial site upgrade is done). Validate that the upgraded software is working as expected. This helps validate the new software and fix at a specific site before upgrading entire network with the new software.
Can I use this feature to upgrade from:
- 10.0 to 10.x
- 10.0.x to 10.0.y
- 11.0 to 11.y
- 11.0.x to 11.0.y
- All of the above
Partial Site Software Upgrade is applicable only when appliance is running software release 10.x and newer, and can be used within the same major version of software. It can be used between releases 10.0 to 10.0.x/10.x. Only as part of partial site software upgrade, configuration cannot be changed.
Can I test new feature to test as part of partial software upgrade by enabling them from the config?
No, partial software upgrade requires that now Active and Staged config to be identical. Only software version can change.
Can I disable Partial Software Upgrade for RCN?
No, Partial Software Upgrade can be enabled or disabled from MCN only. At RCN the feature is in read-only mode.
Can I use Partial Software Upgrade when I have active as 9.3.x and 10.0.x as staged?
No, the appliance should be running on release 10.0 as active software.
What happens when Partial Software Upgrade option is disabled from MCN, while some branches are already upgraded through this feature?
MCN sends notification to all appliances in the network that Partial Software Upgrade feature is disabled, and then all appliances in the network are auto-corrected by MCN to match to its active and staged version. However, note that MCN is expecting for Activate Staged option to be clicked from Activation page of Change Management. You can choose to activate the network by clicking Activate Staged button or click Change Preparation to cancel state by accepting the confirmation.
Change Management Roll Back
What is rolled back feature in Change management process?
From release 9.3, the Change management rollback feature enables roll back to the Working Configuration when unexpected events such as, t2-app crash or Virtual path state becomes inactive after a configuration update. The network and the appliances are monitored for 10 mins after the Configuration update and during that interval if the following conditions are met (provided user has enabled the feature), the Staged configuration will be activated. The Active software is rolled back to Staged.
What is the criteria for the configuration roll back to restart?
The rollback occurs, if the following scenarios are encountered:
- MCN - After config/software change, if t2_app service gets disabled due to crash within 30 min interval.
- MCN - After config/software change, if Virtual Path service is down for 30 minutes or longer after activation. The Rollback feature is initiated at the sites.
- Site - After config/software change, if the Site loses its communication with MCN, then the rollback feature is initiated.
- Site - After config/software change t2_app service gets disabled due to crash within 30 min interval.
What happens after rollback?
After configuration rollback, the faulty config/software is presented as Staged software.
How are users notified that roll back occurred?
A yellow banner at the top in the GUI saying Config is rolled back due to respective errors is displayed. Also, you can see it is change management status table. It shows Configuration Error or Software error corresponding to the site for which roll back occurred.
Does config and software both get rolled back?
Yes, if software upgrade is also performed along with configuration, and roll back scenario is encountered then Software also gets rolled back.
What happens if there is an issue in MCN and it crashes or loses connectivity with all the sites?
The entire network is rolled back except MCN. Notification is displayed, and all the sites show roll back status in the change management section. You can resolve the issue on MCN manually.
Can we disable this feature?
Yes, we can disable this feature just before activation. However, by default this feature is enabled.
How does roll back interact with Partial Software Upgrade when I have multi-tier network?
- If partial software upgrade is disabled, and if a site in a region (or the RCN) rolls back, the region with the problem is rolled back and once completed the rollback propagates up to the MCN. As a result, the MCN and the rest of the network to rolled back. Both the RCN in the region that rolled back, and the MCN display the rollback banner that the MCN cannot auto-dismiss the rollback banner at the RCN.
- If partial software upgrade is enabled, and if a site in a region (or the RCN) rolls back, only that region is rolled back. The rollback event does not propagate back to the MCN. As a result, the MCN leaves the region. The MCN does not show rollback banner and does not roll back itself or the network.
In both these scenarios, the RCN displays the rollback banner until it is dismissed. Because, it cannot be auto-dismissed by MCN.