Cisco Nexus 7000 Series NX-OS System Management Configuration Guide
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure rollback on Cisco NX-OS devices.
This chapter contains the following sections:
Your software release might not support all the features documented in this module. For the latest caveats and feature information,
see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release. To find information about the features documented in this module, and to
see a list of the releases in which each feature is supported, see the "New and Changed Information"chapter or the Feature
History table in this chapter.
A rollback allows you to take a snapshot, or user checkpoint, of the Cisco NX-OS configuration and then reapply that configuration
to your device at any point without having to reload the device. A rollback allows any authorized administrator to apply this
checkpoint configuration without requiring expert knowledge of the features configured in the checkpoint.
Cisco NX-OS automatically creates system checkpoints. You can use either a user or system checkpoint to perform a rollback.
You can create a checkpoint copy of the current running configuration at any time. Cisco NX-OS saves this checkpoint as an
ASCII file which you can use to roll back the running configuration to the checkpoint configuration at a future time. You
can create multiple checkpoints to save different versions of your running configuration.
When you roll back the running configuration, you can trigger the following rollback types:
atomic—Implement a rollback only if no errors occur.
best-effort—Implement a rollback and skip any errors.
stop-at-first-failure—Implement a rollback that stops if an error occurs.
The default rollback type is atomic.
When you are ready to roll back to a checkpoint configuration, you can view the changes that will be applied to your current
running configuration before committing to the rollback operation. If an error occurs during the rollback operation, you can
choose to cancel the operation, or ignore the error and proceed with the rollback. If you cancel the operation, Cisco NX-OS
provides a list of changes already applied before the error occurred. You need to clean up these changes manually.
Automatically Generated System Checkpoints
The Cisco NX-OS software automatically generates system checkpoints to help you avoid a loss of configuration information.
System checkpoints are generated by the following events:
Disabling an enabled feature with the no feature command
Removing an instance of a Layer 3 protocol, such as with the no router bgp command or the no ip pim sparse-mode command
License expiration of a feature
If one of these events causes system configuration changes, the feature software creates a system checkpoint that you can
use to roll back to the previous system configuration. The system generated checkpoint filenames begin with “system-” and
include the feature name. For example, the first time that you disable the EIGRP feature, the system creates the checkpoint
Whenever a checkpoint is created using the checkpoint or checkpoint checkpoint_name commands, the checkpoint is synchronized
to the standby unit.
A rollback remembers the states of the checkpoint operation, so if the checkpoint operation is interrupted and the system
is left in an inconsistent state, a rollback can complete the checkpoint operation (synchronize the checkpoint with the standby
unit) before proceeding with the rollback operation.
Your checkpoint files are still available after a process restart or supervisor switchover. Even if there is an interruption
during the process restart or supervisor switchover, the checkpoint will complete successfully before proceeding with the
operation. In a supervisor switchover, the checkpoint is completed on the new active unit.
If a process restart or supervisor switchover occurs during a rollback operation, after the restart or switchover completes,
the rollback will resume from its previous state and complete successfully.
Cisco NX-OS creates a checkpoint of the running configuration in the
virtual device context (VDC) that you are logged into. You can create different
checkpoint copies in each VDC. You cannot apply the checkpoint of one VDC into
another VDC. By default, Cisco NX-OS places you in the default VDC. See the
Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
VDC configuration does not support checkpoints for any operations,
including (but not limited to) VDC creation, VDC deletion, VDC suspension, VDC
reloading, VDC renaming, VDC interface allocation, shared interface allocation,
FCoE VLAN allocation, resource allocation, and resource templates. You should
create your checkpoint from within a specific VDC.
To configure rollback,
you must have network-admin user privileges.
Limitations for Rollbacks
Rollbacks have the
following configuration guidelines and limitations:
You can create up to ten checkpoint copies.
Your checkpoint filenames must be 80 characters or less.
You cannot apply a checkpoint configuration in a nondefault VDC if there is a change in the global configuration portion of
the running configuration compared to the checkpoint configuration.
Your checkpoint filenames must be 80 characters or less.
You cannot start a checkpoint filename with the word system.
Beginning in Cisco NX-OS Release 4.2(1), you can start a checkpoint filename with the word auto.
Beginning in Cisco NX-OS Release 4.2(1), you can name a checkpoint file summary or any abbreviation of the word summary.
Only one user can perform a checkpoint, rollback, or copy the running configuration to the startup configuration at the same
After the system executes the write erase or reload command, checkpoints are deleted. You can use the clear checkpoint database command to clear out all checkpoint files.
A rollback fails for NetFlow if during a rollback, you try to modify a record that is programmed in the hardware.
Although a rollback is not supported for checkpoints across software versions, users can perform a rollback at their own discretion
and can use the best-effort mode to recover from errors.
When checkpoints are created on bootflash, differences with the running-system configuration cannot be performed before performing
the rollback, and the system reports “No Changes.”
Checkpoints are local to a virtual device context (VDC).
Checkpoints created using the checkpoint and checkpointcheckpoint_name commands are present upon a switchover.
Checkpoints created in the default VDC are present upon reload unless a write-erase command is issued before a reload.
Checkpoints created in nondefault VDCs are present upon reload only if a copy running-config startup-config command is issued in the applicable VDC and the default VDC.
A rollback to files on bootflash is supported only on files created using the checkpointcheckpoint_name command and not on any other type of ASCII file.
Checkpoint names must be unique. You cannot overwrite previously saved checkpoints with the same name.
Rollback is not supported in the storage VDC.
Rollback is not supported in the Admin virtual device context (VDC) feature.
Configure the terminal dont-ask command before executing the rollback command to a checkpoint. In a rollback patch, the rollback process does not pause for user interaction and takes the default
values for interactive commands. Configuring the terminal dont-ask command before executing the rollback command helps in resolving this issue.
Rollback is not supported in the context of auto configurations. Checkpoints do not store auto configurations. Therefore,
after a rollback is performed, the corresponding auto configurations will not be present.
When you perform rollback, if the patch contains the reload command for the corresponding module along with the configuration commands for that module, rollback fails. This is because
the rollback action does not wait for the module to come online; it starts executing the configuration commands on the module
even as the reload process is in progress. To resolve this issue, manually execute the configuration commands for the module
after the module is online.
A rollback fails when you execute the bfd hw-offload-module command or the no form of this command. In this instance, failure is because rollback cannot execute these commands when the switch interfaces
that are a part of the BFD sessions are powered up. To resolve this issue, shut down all the interfaces that are a part of
the BFD sessions using the shutdown command before executing the bfd hw-offload-module command or the no form of this command.
The following BFD command configurations are not supported during a rollback configuration:
When an FEX is being configured while a rollback vPC is applied to an interface, the FEX goes offline momentarily. When this
occurs, rollback does not wait for the FEX to come online, and executes the configuration commands for the interface, resulting
in failure because the corresponding FEX is not yet provisioned. To resolve this issue, manually execute the FEX-related configuration
commands after the FEX is online.
Checkpoint descriptions are not persistent across switch reloads. When a description for a checkpoint is created by using
the checkpointdescription command, the description is not visible in the output of the show checkpoint summary command after the switch is reloaded. If the checkpoint description can be qualified as a checkpoint name, we recommend using
the same alphanumeric string for both the checkpoint name and description. The checkpoint name is visible in the output of
the show checkpoint summary command even after the switch is reloaded
Default Settings for Rollbacks
This table lists the default settings for rollback parameters.
Be aware that the
Cisco NX-OS commands may differ from the Cisco IOS commands.
Creating a Checkpoint
You can create up to ten checkpoints of your configuration.
Creates a checkpoint of the running configuration to either a user checkpoint name or a file. The checkpoint name can be any
alphanumeric string up to 80 characters but cannot contain spaces. If you do not provide a name, Cisco NX-OS sets the checkpoint
name to user-checkpoint-number where number is from 1 to 10.
The description can contain up to 80 alphanumeric characters, including spaces.
You can use the no form of the checkpoint command to remove a checkpoint name. Use the delete command to remove a checkpoint file.
show checkpointcp-name [all]
switch# show checkpoint stable
Displays the contents of the checkpoint name.
Implementing a Rollback
You can implement a rollback to a checkpoint name or file. Before you implement a rollback, you can view the differences between
source and destination checkpoints that reference current or saved configurations.
If you make a configuration change during an atomic rollback, the rollback will fail.
Displays the differences
between the source and destination checkpoint selections.
rollback log [exec |
Displays the contents of the
checkpoint database command to delete all checkpoint files.
When a checkpoint is created, you can view
the default configuration
priority-flow-control mode auto using the
show run all command. You cannot view the
configuration priority-flow-control mode auto using
command for the interface.
Configuration Example for Rollback
This example shows how to create a checkpoint file and then implements a best-effort rollback to a user checkpoint name:
Cisco Nexus 7000 Series NX-OS System Management Command
Cisco Nexus 7000 Series NX-OS Virtual Device Context
Nexus 7000 Series NX-OS Fundamentals Configuration Guide
Feature History for
Your software release might not support all the features in this document. For the latest caveats and feature information,
see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release.
Table 1. Feature History for Rollback
Checkpoint and rollback operations support high availability.
Guidelines and Limitations
Checkpoint file naming conventions changed.
Automatically generated system checkpoints
The software automatically generates a system checkpoint when
disabling a feature or license expiration could cause loss of configuration
Guidelines and Limitations
A rollback fails for NetFlow if during rollback, you try to
modify a record that is programmed in the hardware.
A rollback is not supported for checkpoints across software