User guide

Upgrading the Software Getting Started and Upgrading AOS
page 1-6 OmniSwitch AOS Release 7 Switch Management Guide March 2015
Upgrading the Software
This section is to assist with upgrading an OmniSwitch. The goal is to provide a clear understanding of the
basic steps and types of upgrade processes available for an OmniSwitch. Depending upon the AOS
version, model, and configuration of the OmniSwitch various upgrade procedures are supported. This
section provides an overview. Since each AOS release has different upgrade requirements please refer to
the Release Notes for step-by-step instructions.
• Standard Upgrade - The standard upgrade of a standalone chassis or virtual chassis (VC) is nearly
identical. All that's required is to upload the new image files to the Running directory and reload the
switch. In the case of a VC, prior to rebooting the Master will copy the new image files to the Slave
and once the VC is back up the entire VC will be synchronized and running with the upgraded code.
• ISSU - The In Service Software Upgrade (ISSU) is used to upgrade the software on a VC or modular
chassis with minimal network disruption. Each element is upgraded individually allowing hosts and
switches which are dual-homed to maintain connectivity to the network. The actual downtime experi-
enced by a host on the network can vary depending upon the overall network design and configuration.
Having a redundant configuration is suggested and will help to minimize recovery times.
Virtual Chassis - The VC will first verify that it is in a state that will allow a successful ISSU upgrade.
It will then copy the image and configuration files of the ISSU specified directory to all of the Slave
chassis and reload each Slave chassis from the ISSU directory in order from lowest to highest chassis-
id. For example, assuming chassid-id 1 is the Master, the Slave with chassis-id 2 will reload with the
new image files. When Slave chassis-id 2 has rebooted and rejoined the VC, the Slave with chassis -id
3 will reboot and rejoin the VC. Once the Slaves are complete they are now using the new image files.
The Master chassis is now rebooted which causes the Slave chassis to become the new Master chassis.
When the original Master chassis reloads it comes back as a Slave chassis. To restore the role of Master
to the original Master chassis the current Master can be rebooted and the original Master will takeover,
re-assuming the Master role.
Modular Chassis - The chassis will first verify that it is in a state that will allow a successful upgrade.
It will then copy the image and configuration files of the specified directory to the secondary CMM
and reload the secondary CMM which becomes the new primary CMM. The old primary CMM
becomes the secondary CMM and reloads using the upgraded code. As a result of this process both
CMMs are now running with the upgraded code and the primary and secondary CMMs will have
changed roles (i.e., primary will act as secondary and the secondary as primary). The individual NIs
can be reset either manually or automatically.
• Staggered Upgrade - A staggered upgrade is similar to ISSU but is designed for those situations that
do not completely support ISSU. A staggered upgrade may be required when upgrading between differ-
ent AOS release trees (i.e. 7.3.2 to 7.3.3) due to underlying code variations between the two releases
which may not allow CMMs or Master/Slave chassis to communicate after one is upgraded to the
newer version of code.
A staggered upgrade requires a script file to be run prior to the upgrade. The script will copy the
required configuration and image files to the CMMs or chassis to be upgraded. It also provides a mech-
anism to allow the Primary CMM or Master chassis to know the upgrade has been completed success-
fully on the redundant CMM or Slave chassis before rebooting. This allows for an upgrade between
different AOS release trees with minimal network disruption.