ACI Firmware Upgrade Overview

Firmware management

Firmware management in Cisco ACI refers to the process of handling various firmware types, including APIC firmware, switch firmware, SMU patches, and Silent Role packages.

  • APIC firmware is the operating system for APIC appliances.

  • Switch firmware is the operating system for ACI switches in the Nexus 9000 series.

  • Software Maintenance Upgrade (SMU) patches and Silent Role (SR) packages address specific defects or hardware components.

Firmware Types and Descriptions

Firmware in Cisco ACI is categorized into several types, each serving a specific function within the system.

Table 1. Firmware Types Comparison

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

Upgrading or Downgrading Cisco ACI Fabrics

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.

  • Ensure that all components are compatible and connected to the ACI infra network before starting the upgrade or downgrade process.

Summary

Actors and components involved in this process include the Cisco APIC, leaf switches, spine switches, App Center apps, and UCS HUU server components.

  • Cisco APIC : Manages the upgrade/downgrade, acts as firmware repository and boot server.

  • Leaf and spine switches: Download firmware from APIC and participate in the upgrade/downgrade.

  • App Center apps: Must be disabled except pre-packaged ones (unless deprecated).

  • UCS HUU server components (CIMC, BIOS, network adapters, RAID controller, disks): Upgraded/downgraded as needed.

This process ensures that all fabric components are upgraded or downgraded in a coordinated manner, following compatibility and backup guidelines.

Workflow

These stages describe the workflow for upgrading or downgrading the Cisco ACI fabric.

  1. Determine target APIC and ACI switch releases and verify compatibility.
    • Upgrade/downgrade APICs and switches to the same release.
    • Check compatibility in release notes and support matrix.
    • Review open caveats or defects for the target release.
  2. Consult the APIC Upgrade/Downgrade Support Matrix for supported paths.
    • If releases are far apart, upgrade/downgrade to intermediate release first.
    • Identify required UCS HUU release for target APIC release.
  3. Review the ACI upgrade architecture and understand expectations and restrictions.
    • Refer to upgrade architecture documentation for guidance.
  4. Export configuration for backup and ensure AES encryption is enabled.
    • Backup configuration using Cisco ACI Configuration Files: Import and Export.
  5. Disable all App Center apps except pre-packaged ones on APICs.
    • App Center deprecation applies from APIC release 6.1(2).
    • Refer to guidelines for App Center apps.
  6. Download APIC and ACI switch firmware to APICs.
    • Follow instructions for downloading images for each release.
    • For release 6.0(2) or later, download both 32-bit and 64-bit switch images after APIC upgrade.
  7. Download ACI switch firmware from APICs to each switch.
    • Switches running release 14.1(1) or later can download images prior to upgrade/downgrade.
    • Refer to guidelines for ACI switch upgrades.
  8. Perform pre-upgrade validations.
    • Use pre-upgrade checklists to validate readiness.
  9. Upgrade or downgrade all server components using HUU as suggested by the Support Matrix.
    • Upgrade CIMC software through APIC for release 6.2(1) or later.
    • Otherwise, upgrade CIMC through CIMC user interface.
  10. Upgrade or downgrade APICs.
    • Follow instructions for upgrading APIC for each release.
  11. Perform pre-upgrade validations (repeat as needed).
    • Use pre-upgrade checklists to validate readiness.
  12. Upgrade or downgrade ACI-mode switches.
    • Wait until all APICs become Fully Fit .
    • Follow instructions for upgrading leaf and spine switches for each release.
  13. If this is a Multistep Upgrade , repeat the steps above to upgrade/downgrade from intermediate to target release after completion and APIC cluster status is Fully Fit .
    • Ensure both APICs and switches are upgraded/downgraded to the target release.

Result

Upon completion, the Cisco ACI fabric and all associated components will be running the target release, with configuration backed up and validated for compatibility.

What’s next

If the Cisco ACI fabric deployment includes Cisco AVS/AVE, upgrade or downgrade the Cisco AVS/AVE to the release compatible with the 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 remote leaf switches.

  • 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 APIC s are upgraded to 4.2(5) or later. For instance, when the Cisco APIC s 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 APIC s. 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 Upgrading or Downgrading Cisco ACI Fabrics .

Prior to switch release 14.1(1):

Not supported. Switches download the image from Cisco APIC s 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 APIC s 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 APIC s 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 APIC s and the switches are upgraded or downgraded to the corresponding versions. For example, when the Cisco APIC s 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 APIC s 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 APIC s 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.

How multistep upgrades and downgrades work

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.

Summary

The key components involved in the multistep upgrade and downgrade process are:

  • APICs: Require upgrade or downgrade to standard release format x.y(z)

  • Leaf and spine switches: Require upgrade or downgrade to switch-specific compatible release format 1x.y(z)

  • Intermediate releases: Software versions that serve as stepping stones between current and target versions

  • Support matrix: Documentation that defines supported upgrade and downgrade paths

Workflow

These stages describe how multistep upgrades and downgrades work:

  1. The system identifies intermediate releases required when a direct upgrade or downgrade path is not available between the current and target software versions. 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.
  2. The upgrade process executes sequential upgrades through each intermediate release, beginning with the first intermediate release identified in the support matrix.
    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).

Huge fabric upgrades and downgrades

A huge fabric upgrade or downgrade is a maintenance operation that

  • involves large numbers of switches split into different maintenance groups

  • occurs over a series of days with staggered timing

  • allows at most two different APIC and switch software releases in the fabric simultaneously, and

  • provides limited supported operations during mixed-release periods.

Mixed release considerations

During huge fabric upgrades or downgrades, 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.

Guidelines for App Center Apps

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


Note

Starting with Cisco ACI release 6.1(2), this no longer applicable as the app center was deprecated.

  • 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.

Determine 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.

Procedure

Step 1

Determine the current software version on APICs.

Note

 

When upgrading a cluster, all Cisco APICs must be running the same software version to join the cluster. Automatic upgrades when joining the fabric are not available until APIC release 6.0(2). For more information, refer to Auto Firmware Update on APIC Discovery.

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.

Step 2

Determine the 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.

Upgrading or downgrading with the scheduler

A scheduler is a feature that

  • enables you to specify a window of time for operations such as upgrading or downgrading Cisco APIC clusters and switches

  • can be configured as one-time only or to recur at a specified time and day each week, and

  • provides automated timing control for system maintenance operations.

Scheduler operation for upgrades and downgrades


Note

Starting with ACI 6.2(1) release, schedulers for upgrades or downgrades are not supported.

The scheduler operates differently for Cisco APIC cluster upgrades and switch upgrades:

  • 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.

For more information about the scheduler, see the Cisco Application Centric Infrastructure Fundamentals document.

Guidelines for scheduler configuration

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.

Configure 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.

Beginning with APIC release 5.1, the GUI scheduler option is no longer supported.

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 .

Configure 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

Configure 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>