Cisco Blogs

Demystifying the Catalyst: The Basics of Network Software High Availability

What are Rolling Stack Upgrades (RSU) and In-Service Software Upgrades (ISSU) and how should you use them? In this blog post, let’s take a look at the basics of network software high availability.

As we saw in my previous blog about StackPower, businesses requires a highly available campus network with close to zero down time. IT spends considerably on resilient network design, per-device power redundancy and other highly available maintenance technologies.  The last thing they want to deal with is downtime during software upgrades. Let us see how  downtimes can be avoided or minimized during software upgrades on Cisco Catalyst switches.

Cisco Catalyst Series switches minimize traffic interruptions during software upgrades using two technologies – Rolling Stack Upgrade (RSU) available on fixed switches and In-Service Software Upgrade (ISSU) available on chassis based switches. The following two examples explain how they work.

Example 1:

Before Rolling Stack Upgrades:  Typically, fixed switches are combined together in a stack in the wiring closet. When it is time to upgrade a fixed switch with new software (or an urgent patch), IT administrators upgrades each switch in the stack individually. Even though the individual switches are part of a stack, all the switches become inactive until every switch is upgraded. This causes traffic outage during an upgrade. Therefore, in order to execute an upgrade, careful planning is needed that entails identification of a maintenance window, communication in advance to all users and preparation for escalations. 

With Rolling Stack Upgrades: Cisco’sRolling Stack Upgrades allow for one switch to be upgraded at a time in the stack. The other switches (up to nine in a stack) continue to operate normally and aren’t taken offline. Once IT starts the process, all the switches are upgraded automatically and in sequence.

There are two distinct advantages. First, the stack of switches is upgraded without downtime*. Secondly, the upgrade is automatic and IT does not have to “baby sit” the process.

[*Note that for this, the end devices must be connected to two different switches in the stack using duplicate links so that when one switch is going through upgrade, the other is up and carrying traffic from the devices.]

Example 2: For Chassis based switches

Before In-Service Software Upgrades: An IT team may discover after internal testing that an urgent software upgrade is required on the production chassis based switches.  They would usually have to then either schedule a change control for the weekend (the typical time for minimal traffic) or roll out the upgrade during the work week with potential business interruptions.

With In-Service Software Upgrades: This method of upgrade requires the Catalyst chassis based switches to have two supervisor engines for redundancy purposes. When IT starts ISSU, the redundant supervisor engine is upgraded with the new software first while the primary supervisor engine operates normally. Once the upgrade completes, the redundant supervisor becomes the primary and the old primary supervisor engine is then upgraded with the new image.  This upgrade has minimal effect, less than 200ms, on traffic forwarding.

So, what is the benefit to IT? RSU/ISSU allows IT to upgrade the software in switches in production at any time with minimum business interruption.

The following is a list of Cisco switches supporting RSU and ISSU with the actual technology in brackets.

  • Catalyst 6500 (eFSU – enhanced Fast Software Upgrade: similar functionality as ISSU)
  • Catalyst 4500E (ISSU)
  • Catalyst 3750 (RSU)
  • Catalyst 3560 (RSU)

As we saw in this blog, RSU and ISSU are software technologies that ensure the switches stay up and transport traffic even when they are upgraded with new software. RSU is available on fixed switches that can be stacked and ISSU is available on chassis based switches with redundant supervisor modules. These technologies are necessary ingredients to construct a switching network with the most up time.



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.