What's new in SWIM with Cisco Catalyst Center version 2.3.7?

Software Image Management (SWIM) in Cisco Catalyst Center (also known as Cisco DNA Center) is one of the most popular use cases of the platform, as it significantly reduces the time and effort required for upgrading software of the networking devices in the Enterprise Campus and Branch. 

Network administrators currently using SWIM will be thrilled with the latest enhancement available in version 2.3.7, where we introduce the ability to control the sequence of devices to be upgraded within a single workflow.

With this new capability, network administrators will benefit from a workflow that provides ease of upgrade, velocity, and control. How? These workflows allow a network operator to initiate the activation of a new software image on the network devices for an entire network site, while now providing the control to define the order of device activation within that site.

Device image upgrade with flexibility and control

As an example, let's say we have a branch office with six Cisco Catalyst switches, and we want to create a single workflow that will take care of the upgrade of all six switches. In this branch office example, there are two Cisco Catalyst 3650 switches. One of them is acting as a distribution switch. The other four switches are a mix of Cisco Catalyst 9300 switches and Cisco Catalyst 9200-L switches. 

When upgrading network devices in bulk, typically there’s a preferred order in which we want the upgrade to happen. For the sake of this example, let’s say we want to upgrade the network devices in the following order:

• Upgrade the Cisco Catalyst 3650 acting as distribution switch first
• Once the first Cisco Catalyst 3650 is upgraded, upgrade the second Cisco Catalyst 3650 
• One the second Cisco Catalyst 3650 is upgraded, upgrade the four other Cisco Catalyst 9K switches in parallel

Figure 1: Depicting the device sequence for upgrade in the branch office example

When triggering a software upgrade for a group of devices using previous versions of Cisco Catalyst Center, the upgrade would happen in parallel for the devices. This means that, for devices to be upgraded in the sequence mentioned above, the network administrator would need to trigger three different workflows. Starting with Cisco Catalyst Center 2.3.7, network administrators can now change this default behaviour and specify the group of devices that need to be upgraded in a sequential order, and the group of devices that can be upgraded in parallel. This means the desired order of upgrade mentioned above can now be completed within a single workflow.

The snapshot below shows a list of six devices in the branch office from our example. The same workflow will be used to configure the upgrade of all six devices:

Figure 2: Upgrading all switches in a branch in a single workflow

The snapshots below highlight how the devices are split into two categories: “Sequence” or “Parallel.” The devices in the “Sequence” category will be upgraded in sequential order while the devices in “Parallel” category will be upgraded all at once.

Figure 3: Devices to upgrade in sequence

Figure 4: Devices to upgrade in parallel

There is also the option to define which group of devices to upgrade first: either the “Parallel” group or “Sequential” group. When selecting the “Devices in Sequential” group to go first, software activation will be triggered for the first device on this list first. Once that device is finalized, the second device in the list will be activated. This will continue until all devices in this group have been upgraded. The workflow will then trigger the upgrade of the devices in “Devices in Parallel” group all at once.

A question that came to mind while reading is can you have multiple parallel and sequential groups within the same workflow? If a customer has two core switches, two distribution switches and x access switches, could you have two sequential groups, one that would upgrade core 1 and distribution 1, and another sequential group that would upgrade core 2 and distribution 2? The same could also be accomplished using a single sequential group upgrading core 1, then distribution 1, then core 2 and then distribution 2, but based on the workflow from the demo video it doesn't appear this is supported.

Figure 5: Devices to upgrade in parallel

Putting it all together: SWIM in action in the Cisco Catalyst Center

The best for last: let’s see this functionality in action. In the video below, we will go through the upgrade process for the branch in our example:

If you want to learn more about SWIM and other Cisco Catalyst Center capabilities, make sure you check the Cisco Catalyst Center YouTube channel. 

If you are ready to test this capability, you can access Cisco Catalyst Center documentation.