ACI Firmware Upgrade Overview

About Firmware Management

There are a few types of firmware in Cisco ACI. The following is a brief list of firmware described in this document. This chapter is primarily focused on the top two types of Cisco ACI firmware: Cisco APIC firmware and switch firmware.

Firmware Type

Description

Example

Cisco APIC Firmware

An operation system of APICs running on APIC appliances.

APIC Release 5.2(1g):

aci-apic-dk9.5.2.1g

Switch Firmware

An operation system of ACI switches running on Nexus 9000 series.

ACI Switch Release 15.2(1g):

aci-n9000-dk9.15.2.1g.bin

Software Maintenance Upgrade (SMU) Patch

A patch image for a specific defect on either APICs or ACI switches.

See Software Maintenance Upgrade Patches for details.

A patch for CSCaa12345 on APICs with 5.2(1g) release:

aci-apic-patch-CSCaa12345-5.2.1g-S.1.0.x86_64.tgz

A patch for CSCaa12345 on ACI switches with 15.2(1g) release:

aci-n9000-patch-CSCaa12345-15.2.1g-S.1.1.1.rpm

Silent Role (SR) Package

A package of firmware for specific hardware components on ACI switches.

See Silent Roll Package Upgrade for details.

aci-srpkg-dk9.1.0.0.bin

Workflow to Upgrade or Downgrade the Cisco ACI Fabric

Cisco APIC centrally manages the upgrade and downgrade for the entire fabric. The Cisco APIC acts as the repository of the image (for example, the firmware repository) and as the booting server. Leaf switches and spine switches have connectivity to the Cisco APIC through the ACI infra network, and when upgrading or downgrading, the switches download the firmware from the Cisco APIC. This section provides the recommended steps for a successful upgrade or downgrade.

  1. Pick your target Cisco APIC and ACI switch releases.

    1. Both Cisco APICs and ACI switches must be upgraded or downgraded to the same release.

    2. Cisco APIC and ACI switch releases that are compatible to each other are described in the form of x.y(z) and 1x.y(z). For instance, Cisco APIC release 5.2(1g) corresponds to ACI switch release 15.2(1g).

    3. Check the Release Notes (APIC and ACI switches) for the target release for any open caveats or defects.

  2. See the APIC Upgrade/Downgrade Support Matrix for the supported upgrade and downgrade paths from your current release.

    1. If your current release and the target release are too far apart, you might need to upgrade or downgrade both your Cisco APICs and switches to an intermediate release suggested in the APIC Upgrade/Downgrade Support Matrix first. See Multistep Upgrades and Downgrades for more information.

    2. The APIC Upgrade/Downgrade Support Matrix also shows you which UCS HUU release you need to use for your target Cisco APIC release.

  3. Review the ACI upgrade architecture.

    See ACI Upgrade/Downgrade Architecture to understand what you should expect along with what you must not perform.

  4. Export your configuration for backup.

    See the Cisco ACI Configuration Files: Import and Export document for details. Ensure that AES encryption is enabled.

  5. Disable all App Center apps on the Cisco APICs except for the ones that are pre-packaged on the Cisco APIC image.

    See Guidelines for App Center Apps for details.

  6. Download both the Cisco APIC and ACI switch firmware to your Cisco APICs.

    See the Downloading APIC and Switch Images on APICs section for each release for details:

  7. Download ACI switch firmware from your Cisco APICs to each switch.

    Starting from switch release 14.1(1), switches can download the image from Cisco APICs prior to the upgrade or downgrade. See Rule 5 – Save time by downloading switch images beforehand for details.

  8. Perform pre-upgrade validations.

    See Pre-Upgrade/Downgrade Checklists for details.

  9. Upgrade or downgrade all server components via HUU (CIMC, BIOS, network adapters, RAID controller, and disks) on your Cisco APICs if suggested so by the Support Matrix.

    See Upgrading the CIMC Software for details.

  10. Upgrade or downgrade Cisco APICs.

    See the Upgrading the Cisco APIC section for each release for details:

  11. Perform pre-upgrade validations.

    See Pre-Upgrade/Downgrade Checklists for details.

  12. Upgrade or downgrade the ACI-mode Switches.

    1. Wait until all Cisco APICs become Fully Fit.

    2. See the Upgrading the Leaf and Spine Switches section for each release for details:

  13. If this is a Multistep Upgrade, repeat the steps above to upgrade or downgrade from the intermediate release to the target release after the upgrade or downgrade to the immediate release for both Cisco APICs and switches completed and Cisco APIC cluster status is Fully Fit.


Note

If the Cisco ACI fabric deployment includes Cisco AVS/AVE, upgrade or downgrade the Cisco AVS/AVE to the release compatible with the Cisco APIC. To upgrade or downgrade Cisco AVS/AVE, see the section Recommended Upgrade Sequence for Cisco APIC, the Fabric Switches, and Cisco ACI Virtual Edge in the Cisco ACI Virtual Edge Installation Guide.

Guidelines for ACI Switch Upgrades and Downgrades

Following are the guidelines for ACI switch upgrades and downgrades:

Rule 1 – Divide your leaf and spine switches into at least two groups

For example:

  • Group ODD: leaf 101, leaf 103, spine 1001

  • Group EVEN: leaf 102, leaf104, spine 1002

Rule 2 – Determine how spine switches should be grouped

  • Always keep at least one MP-BGP route reflector (RR) spine switch up and running in each pod.

  • Always keep at least one spine switch with IPN connectivity up and running in each pod.

  • Never perform a graceful upgrade for a spine switch if the given pod has only one spine switch (in the case of multi-pod).

    See Graceful Upgrade or Downgrade of ACI Switches for details.

For example:

Update Group

Pod 1

Pod 2

ODD

leaf 101, leaf 103, leaf 105

spine 1001 (RR, IPN)

spine 1003

leaf 201, leaf 203, leaf 205

spine 2001 (RR, IPN)

spine 2003

EVEN

leaf 102, leaf 104, leaf 106

spine 1002 (RR, IPN)

spine 1004

leaf 202, leaf 204, leaf 206

spine 2002 (RR, IPN)

spine 2004

Where:

  • RR means a Route Reflector spine switch

  • IPN means a spine switch connected to IPN

Rule 3 – Determine how leaf switches should be grouped

  • Always keep one of the leaf switches in the same vPC pair up and running

  • Always keep one of the leaf switches connected to each Cisco Application Policy Infrastructure Controller (APIC) up and running

For example:

Update Group

Pod 1

Pod 2

ODD

leaf 101 (vPC 11, APIC1)

leaf 103 (vPC 12, APIC2)

leaf 105 (vPC 13)

spine 1001

leaf 201 (vPC 21, APIC3)

leaf 203 (vPC 22)

leaf 205 (vPC 23)

spine 2001

EVEN

leaf 102 (vPC 11, APIC1)

leaf 104 (vPC 12, APIC2)

leaf 106 (vPC 13)

spine 1002

leaf 202 (vPC 21, APIC3)

leaf 204 (vPC 22)

leaf 206 (vPC 23)

spine 2002

Where:

  • vPC xx means one vPC pair

  • APICx means a leaf switch connected to the Cisco APIC

Rule 4 – Understand the concurrent capacity in switch update groups

General

  • Each update/maintenance group should contain a maximum of 80 switch nodes.

  • The concurrent capacity (switches that are upgraded or downgraded simultaneously) decides how many switches should be upgraded or downgraded simultaneously within the same update/maintenance group. However, we recommend that you create separate update groups to upgrade or downgraded switches on different schedules instead of relying on the concurrent capacity setting because the concurrent capacity setting doesn’t let you manage which switches in the same group are to be upgraded or downgraded at the same time.

  • If both leaf nodes in the same vPC pair are in the same switch upgrade or downgrade group, only one of the leaf nodes is upgraded or downgraded at a time regardless of the concurrent capacity.

  • Starting from Cisco APIC release 4.1(1), when graceful upgrade or downgrade is enforced and there are no other operational spine switches in the same pod, the upgrade or downgrade is rejected regardless of the concurrent capacity setting.

Prior to Cisco APIC release 4.2(5):

  • Even in the same update group, switches are upgraded or downgraded only one pod at a time.

  • The default concurrent capacity per group is 20.

If you have more than 20 switches in the same group, you can use upgrade scheduler to change the capacity to unlimited.

See the Upgrading the Leaf and Spine Switch Software Version section for details:

From Cisco APIC release 4.2(5):

  • Switches in the same update group are upgraded or downgraded simultaneously, regardless of pods.

  • The default concurrent capacity per group is unlimited.

The above enhancements from Cisco APIC release 4.2(5) take effect as soon as the Cisco APICs are upgraded to 4.2(5) or later. For instance, when the Cisco APICs are upgraded to 4.2(5) and the switches are still at release 13.2(10), the above enhancements will be effective when the switch is upgraded from 13.2(10) to 14.2(5).

This enhancement will help you reduce the time it takes to upgrade your switches.

Rule 5 – Save time by downloading switch images beforehand

Even after you have downloaded Cisco APIC and switch images to the Cisco APIC's firmware repository, the switches still need to download the image from the Cisco APICs. In later releases, this operation can be performed separately from the actual upgrade procedure. This is called pre-download and is equivalent to Step 7 in Workflow to Upgrade or Downgrade the Cisco ACI Fabric.

Prior to switch release 14.1(1):

Not supported. Switches download the image from Cisco APICs when the upgrade or downgrade is triggered.

Switch release 14.(1) - 15.0(x):

  • Pre-download can be performed through the upgrade scheduler.

  • Following is the recommended procedure:

    1. Create update groups with the scheduler set far into the future (such as 10 years in the future). This will trigger switches to download the image from Cisco APICs immediately.

    2. When it’s the time to start the upgrade in the maintenance window, edit the same groups and change the Upgrade Start Time to Now.

  • If the current version of the switches is 14.2(5) or later, the Cisco APIC GUI shows the progress of the pre-download.

Switch release 15.1(1) or later:

  • Pre-download is built in the GUI workflow natively without using a scheduler.

    1. Switches download the image from the Cisco APICs when you create an update group and click Begin Download.

    2. When the pre-download is completed, each switch shows Ready to Install.

    3. Perform Begin Install for the same group to trigger the upgrade.

The above enhancement (pre-download) from switch release 14.1(1) takes effect only after both the Cisco APICs and the switches are upgraded or downgraded to the corresponding versions. For example, when the Cisco APICs are upgraded to 4.2(7) and the switches are still on 13.2(10), pre-download is not available to upgrade the switches from 13.2(10) to 14.2(7). On the other hand, when the Cisco APICs are upgraded to 5.2(1) and the switches are still in 14.2(7), pre-download is performed through the new Cisco APIC GUI using Begin Download for switch upgrades from 14.2(7) to 15.2(1).

Graceful Upgrade or Downgrade of ACI Switches

If you want to isolate a switch from user traffic when performing an upgrade or downgrade procedure, it's helpful to become familiar with the different terms and methods available to better understand what is supported and what is not supported in these situations:

  • Graceful Insertion and Removal (GIR): The operation used to isolate a switch from user traffic.

  • Maintenance mode: Used to isolate a switch from user traffic for debugging purposes. You can put a switch in maintenance mode by enabling the Maintenance (GIR) field in the Fabric Membership page in the Cisco APIC GUI, located at Fabric > Inventory > Fabric Membership (right-click on a switch and choose Maintenance (GIR)).

    If you put a switch in maintenance mode, that switch is not considered as a part of the operational ACI fabric infra and it will not accept regular Cisco APIC communications. Therefore, performing a firmware upgrade or downgrade for a switch in this state is not supported, because the process may fail or may get stuck in an incomplete status indefinitely if you attempt to perform a firmware upgrade or downgrade on the switch while the switch is in this state.

  • Graceful Upgrade: Used to reload a switch after it is isolated from user traffic during an upgrade procedure. Switches are programmed to reboot automatically at a certain point during the firmware upgrade process; this operation will automatically perform GIR prior to that reboot. You can find the Graceful Maintenance option (releases prior to release 5.1) or the Graceful Upgrade option (release 5.1 and later) for a switch in an update group in Admin > Firmware in the Cisco APIC GUI.

    If you wish to halt the procedure after the switch is isolated from user traffic and before it is reloaded in order to ensure the user traffic is flowing through redundant paths, such an operation is currently not supported in ACI.

Guidelines for ACI Switch Graceful Upgrade

All guidelines from Guidelines for ACI Switch Upgrades and Downgrades also apply to Graceful Upgrade. However, this section provides more information on several guidelines that are specifically critical for Graceful Upgrade.

  • As suggested in Rule 2 – Determine how spine switches should be grouped, do not upgrade all spine switches in a pod at one time, especially when you are performing a Graceful Upgrade in a Multi-Pod setup.

    Otherwise, the upgrade will fail, leaving the spine switches isolated from the fabric indefinitely. This is because, as part of the Graceful Upgrade process, IPN connectivity is brought down explicitly on each spine switch being upgraded gracefully so that it can isolate itself from the fabric. Upgrading in this way results in the entire pod, including the spine switches themselves, to lose communication with Cisco APICs and switches in other pods without the means to self-recover.

    Due to this reason, if you are performing a Graceful Upgrade, you must put the spine switches from the same pod into different maintenance/update groups such that the switches get upgraded separately. If the pod has only one spine switch, you must disable the Graceful Upgrade (or Graceful Maintenance) option prior to the upgrade. In case you fail to follow this procedure, refer to the workaround provided in CSCvn28063.

    To avoid this issue, Cisco APIC 4.1(1) release introduced a safe mechanism to reject the upgrade of the last spine switch in a pod when Grace Upgrade is enforced. This block mechanism is also described in Rule 4 – Understand the concurrent capacity in switch update groups.

  • As suggested in Rule 3 – Determine how leaf switches should be grouped, you must put Cisco APIC-connected leaf switches into different maintenance/update groups so that two leaf switches connected to the same Cisco APIC are not upgraded at the same time.

Multistep Upgrades and Downgrades

In the Cisco ACI fabric, all nodes (APICs, leaf switches, and spine switches) should be on the same software release or on a compatible software release, where the APIC nodes have the standard release format of x.y(z), and the leaf and spine switches have the switch-specific standard release format of 1x.y(z). For example, if the APIC nodes are on software release 4.2(1), the leaf switches and spine switches should be on the switch-specific compatible software release of 14.2(1).

APIC Upgrade/Downgrade Support Matrix shows the supported upgrade and downgrade paths for your current version and the target version. If those two versions are too far apart, upgrading or downgrading directly to the target version might not be supported.

When upgrading or downgrading to a release that does not have a direct path from your current release, you must upgrade or downgrade all the APICs and switches to an intermediate supported release to which there is a direct path, then upgrade or downgrade from that release to your desired release. Sometimes, you must move through multiple intermediate releases before being able to get to your desired release, upgrading or downgrading both the APICs and switches to the same release each time.

For example, consider the following situation, where the APIC Upgrade/Downgrade Support Matrix shows multiple intermediate releases for an upgrade from release 2.3(1) to release 4.2(3):

In this situation, you would perform the upgrade in the following manner:

  1. Upgrade the APICs to the 3.1(2) release and the switches to the 13.1(2) release.

  2. Verify that all APICs and switches are in the Fully Fit state and operational after the upgrade to 3.1(2)/13.1(2).

  3. Repeat the same steps for 4.1(2) and 14.1(2).

  4. Repeat the same steps for 4.2(3) and 14.2(3).

Upgrading or Downgrading a Huge Fabric

There are situations where you might have different releases in the fabric at the same time, such as when you're upgrading or downgrading a huge fabric with a large number of switches and you're splitting the switches into different maintenance groups, with the upgrades or downgrades occurring over a series of days. In those situations, you can have at most two different APIC and switch software releases in the fabric at any given time. However, supported operations in those situations are limited. See Operations Allowed During Mixed Versions on Cisco ACI Switches for more information.

Upgrading or Downgrading a Cisco Mini ACI Fabric

The Cisco Application Centric Infrastructure (ACI) release 4.0(1) introduced the Cisco mini ACI fabric for small scale deployments. A mini ACI fabric works with a Cisco Application Policy Infrastructure Controller (APIC) cluster consisting of one physical Cisco APIC and two virtual Cisco APICs (vAPICs) running in virtual machines. This reduces the physical footprint and cost of the Cisco APIC cluster, which allows you to deploy the Cisco ACI fabric in scenarios with limited rack space or initial budget. Examples of such a scenario include a colocation facility or a single-room data center. In such cases, a full-scale Cisco ACI installation may not be practical due to the physical footprint or initial cost.

For more information the Cisco mini ACI fabric, including procedures for installing, upgrading, and downgrading, see the Cisco Mini ACI Fabric and Virtual APICs document:

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/kb/Cisco-Mini-ACI-Fabric-and-Virtual-APICs.html

Guidelines for App Center Apps

If you are running apps from https://dcappcenter.cisco.com/ on your Cisco APIC nodes:

  • Disable those apps before upgrading or downgrading the APIC software on those APIC nodes.

  • Do not install or remove any apps while upgrading or downgrading the APIC software on those APIC nodes.

  • Do not perform an app image upgrade while upgrading or downgrading the APIC software on those APIC nodes.

  • If you upgraded from a release prior to the 3.2(1) release and you had any apps installed prior to the upgrade, the apps will no longer work. To use the apps again, you must uninstall and reinstall them.

  • If you are upgrading to APIC release 5.2(1) or later and you have External Switch App version 1.1 installed, you must remove the app and re-install version 1.2 of the app before you upgrade to APIC release 5.2(1) or later.

After you have completed the APIC software upgrade or downgrade process for the entire fabric (the APIC nodes and switches), re-enable the apps again if you disabled them. You can install or remove apps, or perform an app image upgrade, after the APIC software upgrade or downgrade process is complete.

Determining Current Software Version

Use the procedures in this section to determine the software version that is currently running on the switches and APICs in your fabric.

Determining Current Software Version on APICs

You can determine the software version that is currently running on the APICs in your fabric several ways:

  • Click the System Tools icon ( ) in the upper right corner of the Cisco APIC GUI window, then select About.

  • Navigate to the Controllers page:

    • For releases prior to release 5.1(1), navigate to Admin > Firmware > Infrastructure > Controllers. The software version is shown in the Current Firmware column in the table on this page.

    • For release 5.1(1) and later, navigate to Admin > Firmware, then click Dashboard in the left navigation window. The software version is shown in the Firmware field in the Controllers area on the page.

      You can also determine the software version running on each individual APIC by locating the Controllers area in this same page. The software version running on each APIC is shown in the Current Version column.

Determining Current Software Version on Switches

To determine the software version that is currently running on the leaf and spine switches in your fabric:

  • For releases prior to release 5.1(1), navigate to Admin > Firmware > Infrastructure > Nodes. The software version is shown in the Current Firmware column in the table on this page.

  • For release 5.1(1) and later, navigate to Admin > Firmware, then click Dashboard in the left navigation window. The software version is shown in the Firmware field in the Nodes area on the page.

  • For release 5.2(1) and later, you can also use the Node Summary tab in Admin > Firmware > Nodes.

About Upgrading or Downgrading with the Scheduler

The scheduler enables you to specify a window of time for operations such as upgrading or downgrading Cisco APIC clusters and switches. The windows of time can be one-time only or it can recur at a specified time and day each week. This section explains how the scheduler works for upgrades or downgrades. For more information about the scheduler, see the Cisco Application Centric Infrastructure Fundamentals document.


Note

When performing a Cluster Upgrade, the Cisco APICs must all be the same version for them to join the cluster. There is no automatic upgrade when joining the fabric.

  • Cisco APIC Cluster Upgrade—There is a default scheduler object for Cisco APIC upgrades. While the generic scheduler object has several properties, only the start time property is configurable for the Cisco APIC cluster upgrade. If you specify a start time, the Cisco APIC upgrade scheduler is active from the specified start time for the duration of 1 day. Anytime during this active one-day window, if runningVersion != desiredVersion for the controllers, the cluster upgrade will begin. None of the other parameters of the scheduler are configurable for Cisco APIC upgrades. Please note that you can also perform an Cisco APIC upgrade by using a one-time trigger, which does not use the scheduler. This one-time trigger is also called upgrade-now.

  • Switch upgrades—A scheduler may be attached to a maintenance group. A scheduler attached to a switch maintenance group has several configurable parameters such as “startTime”, “concurCap” and “duration.” These parameters are described below:

    • startTime—The start of an active window.

    • concurCap—The number of nodes to upgrade simultaneously.

    • Duration—The length of an active window.

    Anytime during an active window, if runningVersion != desiredVersion for any switch in that group, the switch will be eligible for an upgrade. Among nodes eligible for an upgrade, the following constraints are applied to pick upgrade candidates:

    • No more than the "concurCap" nodes should currently be upgrading.

    • Only one node in a virtual port channel (vPC) pair is upgraded at a time.

    • The Cisco APIC cluster should be healthy before starting a node upgrade.


    Note

    You have the options of immediate upgrade and scheduler-based upgrade through the GUI, CLI or REST API. For example, with CLI, you can upgrade the switch-group immediately using the firmware upgrade switch-group command in the EXEC mode. This command takes priority over any configured scheduled upgrades.

Scheduler Guidelines

The system will react differently if you set an upgrade schedule to a date in the past, depending on whether you are setting a one-time or a recurring upgrade schedule:

  • If you set a one-time upgrade schedule with a date in the past, the configuration will be rejected by the system.

  • If you set a recurring upgrade schedule with a date in the past, the scheduler triggers the upgrade immediately. For example, if it is noon on Wednesday and you set a recurring upgrade schedule for every Tuesday at noon, the scheduler will first trigger an upgrade immediately, and then will perform upgrades every Tuesday at noon from that point forward.

Configuring a Scheduler Using the GUI

The trigger scheduler allows you to define one-time or recurring time periods where one or more nodes can be upgraded and rebooted without administrator intervention.

Procedure

Step 1

Access the Create Trigger Scheduler window.

Step 2

In the Create Trigger Scheduler window, enter a name for the scheduler policy in the Name field, then click + in the Schedule Windows area to bring up the Create Schedule Window window.

Step 3

In the Window Type field, click either One Time or Recurring, depending on whether you want to configure a one-time or a recurring schedule window.

Step 4

In the Window Name field, enter a name for this schedule window.

The maximum number of characters for this field is 16.

Step 5

Determine the date and time that you want the schedule window to occur.

The options for setting the date and time vary, depending on whether you choose to configure a one-time or a recurring schedule window.

  • If you’re configuring a one-time schedule window, in the Date field, enter a date for the one-time schedule window to occur. For this field, use the format YYYY-MM-DD HH:MM:SS AM/PM, or click the down-arrow to select a date and time from a calendar.

    Note

     

    If you enter a date and time that is in the past (before the current date and time) for the one-time schedule window, the system will reject that entry.

  • If you’re configuring a recurring schedule window, enter the necessary information in the following fields:

    • Day: Select which days that you want the recurring schedule window to occur. Select either a specific day that you want the recurring schedule window to occur every week, or if you want the recurring schedule window to occur every day, on every even day, or on every odd day of the week.

    • Hour: Enter the hour that would like to recurring schedule window to occur, using military 24-hour clock values (0-23).

    • Minute: Enter the minute that would like to recurring schedule window to occur.

    For example, if you wanted to configure a recurring schedule window for every Tuesday at 11:30 p.m., you would make the following selections:

    • Day: Tuesday

    • Hour: 22

    • Minute: 30

Note

 

If you enter a date and time that is in the past (before the current date and time) for the recurring schedule window, the scheduler triggers the upgrade immediately. For example, if it is noon on Wednesday and you set a recurring upgrade schedule for every Tuesday at 11:30 pm, the scheduler will first trigger an upgrade immediately, and then will perform upgrades every Tuesday at 11:30 pm from that point forward..

Step 6

In the Maximum Concurrent Nodes field, enter the maximum number of nodes that will be allowed to go through concurrent (simultaneous) upgrades.

If you enter 0 in this field, the software will automatically select the default value, depending on whether the nodes are APIC nodes or leaf or spine switches.

  • For releases prior to release 4.2(5), the default value "0" for this field is interpreted as 1 for APIC nodes and 20 for leaf or spine switches. The maximum number of nodes per POD that you can enter in this field is 200.

  • For release 4.2(5) and forward, the default value "0" for this field is interpreted as 1 for APIC nodes. For leaf or spine switches, the interpretation of the default value "0" for this field has changed from 20 to unlimited. In other words, when entering "0" in this field, the number of leaf or spine switches that can be upgraded at one time is unlimited.

Step 7

In the Maximum Running Time field, enter the maximum duration for the schedule window, which is the amount of time that you want to allow for the upgrade process to begin.

For this field, use the format DD:HH:MM:SS, with a maximum of 24 hours (01:00:00:00). Enter unlimited if you don’t want to have a time limit enforced on the scheduler window.

For example, assume that you entered the following values in these fields:

  • Maximum Concurrent Nodes: 20

  • Maximum Running Time: 00:00:30:00

In this case, for this schedule window, you’re allowing 20 nodes to upgrade simultaneously, and those 20 nodes will upgrade only if the upgrade process successfully begins within 30 minutes from the start time that you entered in the fields above. If the upgrade process doesn’t begin successfully within 30 minutes, none of the 20 nodes are upgraded at this time, and, if you configured a recurring schedule window, the system will attempt the upgrade for those 20 nodes the next time the scheduler window is set to repeat.

The value that you enter in the Maximum Running Time field doesn’t affect the amount of time that is needed for the switches in a group to upgrade. For example, entering a value of 5 in the Maximum Running Time field only means that the system will abandon the upgrade process for the switches if the upgrades don’t begin after 5 minutes; it doesn’t mean that the system will stop the upgrade process after 5 minutes. Each switch generally takes about 10 minutes for the upgrade.

Step 8

Click OK when you have finished entering the necessary information in the Create Trigger Scheduler window.

The Create Trigger Scheduler window appears again, with your newly-configured schedule window appearing in the Schedule Windows table.

Step 9

Determine if you want to create additional schedule windows for this trigger scheduler.

Click + in the Schedule Windows area to bring up the Create Schedule Window window again, if you want to create more schedule windows for this trigger scheduler.

For example, you might create more schedule windows if you want to configure upgrades to start twice a day, say at 12:00 AM and PM every day, or to configure upgrades on specific days of the week.

Step 10

When you have finished configuring the necessary schedule windows, in the Create Trigger Scheduler window, click Submit.

The Select Node Upgrade window appears again.

Step 11

In the Select Node Upgrade window, locate the Scheduler field and select the trigger schedule that you just configured.

Step 12

Complete any necessary additional configurations in the Select Node Upgrade window, then click Submit.

Configuring a Scheduler Using the NX-OS Style CLI

A schedule allows operations, such as configuration import/export or tech support collection, to occur during one or more specified windows of time.

A schedule contains a set of time windows (occurrences). These windows can be one time only or can recur at a specified time and day each week. The options defined in the window, such as the duration or the maximum number of tasks to be run, determine when a scheduled task will execute. For example, if a change cannot be deployed during a given maintenance window because the maximum duration or number of tasks has been reached, that deployment is carried over to the next maintenance window.

Each schedule checks periodically to see whether the APIC has entered one or more maintenance windows. If it has, the schedule executes the deployments that are eligible according to the constraints specified in the maintenance policy.

A schedule contains one or more occurrences, which determine the maintenance windows associated with that schedule. An occurrence can be one of the following:

  • Absolute (One Time) Window—An absolute window defines a schedule that will occur only once. This window continues until the maximum duration of the window or the maximum number of tasks that can be run in the window has been reached.

  • Recurring Window—A recurring window defines a repeating schedule. This window continues until the maximum number of tasks or the end of the day specified in the window has been reached.

Procedure

  Command or Action Purpose

Step 1

configure

Example:

apic1# configure

Enters global configuration mode.

Step 2

[no] scheduler schedule-name

Example:

apic1(config)# scheduler controller schedule myScheduler

Creates a new scheduler or configures an existing scheduler.

Step 3

[no] description text

Example:

apic1(config-scheduler)# description 'This is my scheduler'

Adds a description for this scheduler. If the text includes spaces, it must be enclosed in single quotes.

Step 4

[no] absolute window window-name

Example:

apic1(config-scheduler)# absolute window myAbsoluteWindow

Creates an absolute (one time) window schedule.

Step 5

[no] max concurrent nodes count

Example:

apic1(config-scheduler-absolute)# max concurrent nodes 300

Sets the maximum number of nodes (tasks) that can be processed concurrently. The range is 0 to 65535. Set to 0 for unlimited nodes.

Step 6

[no] max running time time

Example:

apic1(config-scheduler-absolute)# max running time 00:01:30:00

Sets the maximum running time for tasks in the format dd:hh:mm:ss. The range is 0 to 65535. Set to 0 for no time limit.

Step 7

[no] time start time

Example:

apic1(config-scheduler-absolute)# time start 2016:jan:01:12:01

Sets the starting time in the format [[[yyyy:]mmm:]dd:]HH:MM.

Step 8

exit

Example:

apic1(config-scheduler-absolute)# exit

Returns to scheduler configuration mode.

Step 9

[no] recurring window window-name

Example:

apic1(config-scheduler)# recurring window myRecurringWindow

Creates a recurring window schedule.

Step 10

[no] max concurrent nodes count

Example:

apic1(config-scheduler-recurring)# max concurrent nodes 300

Sets the maximum number of nodes (tasks) that can be processed concurrently. The range is 0 to 65535. Set to 0 for unlimited nodes.

Step 11

[no] max running time time

Example:

apic1(config-scheduler-recurring)# max running time 00:01:30:00

Sets the maximum running time for tasks in the format dd:hh:mm:ss. The range is 0 to 65535. Set to 0 for no time limit.

Step 12

[no] time start {daily HH:MM | weekly (See usage) HH:MM}

Example:

apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

Sets the period (daily or weekly) and starting time. If weekly is selected, choose from these options:

  • monday

  • tuesday

  • wednesday

  • thursday

  • friday

  • saturday

  • sunday

  • even-day

  • odd-day

  • every-day

Examples

This example shows how to configure a recurring scheduler to run every Wednesday. 


apic1# configure
apic1(config)# scheduler controller schedule myScheduler
apic1(config-scheduler)# description 'This is my scheduler'
apic1(config-scheduler)# recurring window myRecurringWindow
apic1(config-scheduler-recurring)# max concurrent nodes 300
apic1(config-scheduler-recurring)# max running time 00:01:30:00
apic1(config-scheduler-recurring)# time start weekly wednesday 12:30

Configuring a Scheduler Using REST API

A schedule allows operations, such as configuration import/export or tech support collection, to occur during one or more specified windows of time.

A schedule contains a set of time windows (occurrences). These windows can be one time only or can recur at a specified time and day each week. The options defined in the window, such as the duration or the maximum number of tasks to be run, determine when a scheduled task will execute. For example, if a change cannot be deployed during a given maintenance window because the maximum duration or number of tasks has been reached, that deployment is carried over to the next maintenance window.

Each schedule checks periodically to see whether the APIC has entered one or more maintenance windows. If it has, the schedule executes the deployments that are eligible according to the constraints specified in the maintenance policy.

A schedule contains one or more occurrences, which determine the maintenance windows associated with that schedule. An occurrence can be one of the following:

  • Absolute (One Time) Window—An absolute window defines a schedule that will occur only once. This window continues until the maximum duration of the window or the maximum number of tasks that can be run in the window has been reached.

  • Recurring Window—A recurring window defines a repeating schedule. This window continues until the maximum number of tasks or the end of the day specified in the window has been reached.

Procedure

Step 1

Download the switch image into the repository.

Example:

POST URL: https://<ip address>/api/node/mo/uni/fabric.xml
<firmwareRepoP>
	<firmwareOSource name="Switch_Image_download" proto="http" url="http://<ip address>/<ver-no>"/>
</firmwareRepoP>

Step 2

Post the following policies, to create a firmware group that consists of your switches with node IDs 101, 102, 103, 104, and to create a maintenance group with node IDs 101, 102, 103, 104:

Example:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<fabricInst>
<firmwareFwP
    name="AllswitchesFwP"
    version="<ver-no>"
    ignoreCompat="true">
</firmwareFwP>

<firmwareFwGrp
    name="AllswitchesFwGrp" >
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<firmwareRsFwgrpp
    tnFirmwareFwPName="AllswitchesFwP">
</firmwareRsFwgrpp>
</firmwareFwGrp>

<maintMaintP
    name="AllswitchesMaintP"
    runMode="pauseOnlyOnFailures" >
</maintMaintP>

<maintMaintGrp
    name="AllswitchesMaintGrp">
        <fabricNodeBlk name="Blk101"
            from_="101" to_="101">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk102"
            from_="102" to_="102">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk103"
            from_="103" to_="103">
        </fabricNodeBlk>
        <fabricNodeBlk name="Blk104"
            from_="104" to_="104">
        </fabricNodeBlk>
<maintRsMgrpp
    tnMaintMaintPName="AllswitchesMaintP">
</maintRsMgrpp>
</maintMaintGrp>
</fabricInst>

Step 3

Post a policy similar to the following to upgrade all the switches based on a scheduler:

Example:

POST URL : https://<ip address>/api/node/mo/uni/fabric.xml
<trigSchedP annotation="" descr="" dn="uni/fabric/schedp-EveryEightHours" name="EveryEightHours" nameAlias="" ownerKey="" ownerTag="" userdom="">
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="17" minute="0" name="third" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="9" minute="0" name="second" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
	<trigRecurrWindowP annotation="" concurCap="unlimited" day="every-day" hour="1" minute="0" name="first" nameAlias="" nodeUpgInterval="0" procBreak="none" procCap="unlimited" timeCap="00:01:00:00.000" userdom=""/>
</trigSchedP>