SystemEXEC

rollback running-config checkpoint [name]

Rolls back the running configuration to a previously saved checkpoint.

Overview

The 'rollback running-config checkpoint' command is a powerful configuration management tool in Cisco NX-OS that allows network administrators to revert the entire running configuration to a previously saved state. This command is essential for maintaining network stability, especially during change windows or troubleshooting sessions. The underlying concept is that NX-OS supports configuration checkpoints, which are snapshots of the running configuration saved with a user-defined or automatically generated name. These checkpoints are stored in the device's filesystem and can be used to restore the configuration to that exact point in time.

When to use this command: It is best used when a series of configuration changes have been applied and need to be undone quickly. For example, after implementing a new routing policy that causes connectivity issues, rolling back to a checkpoint taken before the change can restore normal operations. It is also useful during software upgrades or hardware replacements where a known good configuration is required. In troubleshooting workflows, it provides a safety net: before making experimental changes, create a checkpoint, and if the changes cause problems, roll back immediately.

Platform-specific behavior for Cisco NX-OS (Nexus): Unlike Cisco IOS, which uses the 'configure replace' command with a file, NX-OS uses checkpoints as a native feature. Checkpoints are created using the 'checkpoint' command and can be listed with 'show checkpoint'. The rollback command replaces the entire running configuration, not just incremental changes. It is important to note that the rollback operation is atomic; if any part of the checkpoint configuration cannot be applied, the entire rollback fails and the running configuration remains unchanged. This prevents partial application that could leave the device in an inconsistent state.

Syntax·EXEC

rollback running-config checkpoint [name]

When to Use This Command

After applying a configuration change that caused network instability, roll back to a known good checkpoint.
Before performing a major upgrade or reconfiguration, create a checkpoint and use this command to revert if needed.
When testing new features in a lab, quickly revert to a baseline configuration using a checkpoint.
To undo a series of changes made during troubleshooting without manually reversing each command.

Parameters

Parameter	Syntax	Required	Description
name	checkpoint [name]	Optional	The name of the checkpoint to roll back to. If omitted, the command rolls back to the most recent checkpoint (either auto-created or manual). The name is case-sensitive and must match an existing checkpoint.

Command Examples

Roll back to a specific checkpoint

rollback running-config checkpoint pre-upgrade

Rollback completed successfully.
Running configuration has been replaced with checkpoint 'pre-upgrade'.

The command replaces the current running configuration with the configuration saved in the checkpoint named 'pre-upgrade'. The output confirms success.

Roll back to the most recent checkpoint

rollback running-config checkpoint

Rollback completed successfully.
Running configuration has been replaced with checkpoint 'auto-ckpt-20250315-1200'.

Without specifying a name, the command rolls back to the latest automatically created checkpoint (if any) or the most recent manual checkpoint. The output shows which checkpoint was used.

Understanding the Output

The output of the 'rollback running-config checkpoint' command is typically brief. A successful rollback displays a message like 'Rollback completed successfully. Running configuration has been replaced with checkpoint <name>.' This indicates that the running configuration has been overwritten with the checkpoint's configuration. If the checkpoint does not exist, an error message such as 'Checkpoint <name> not found' is displayed. In case of failure (e.g., due to incompatible configuration), the switch may reject the rollback and show an error explaining why. It is important to verify the new running configuration after rollback to ensure it matches expectations.

Configuration Scenarios

Rollback after a failed OSPF configuration change

A network engineer added a new OSPF area on a Nexus 9000 switch but caused routing loops. A checkpoint was taken before the change.

Topology

Nexus-9000 (core) --- OSPF Area 0
   |
   +--- OSPF Area 1 (new, problematic)

Steps

1.Create a checkpoint before changes: 'checkpoint pre-ospf-change'
2.Apply OSPF changes (e.g., 'router ospf 1', 'area 1')
3.Observe routing issues
4.Rollback: 'rollback running-config checkpoint pre-ospf-change'
5.Verify OSPF configuration: 'show running-config | section router ospf'

Configuration

! Before rollback, the running config had the new area.
! After rollback, it reverts to the checkpoint.
! No explicit config block needed for the rollback command itself.

Verify: After rollback, use 'show running-config' to confirm the OSPF configuration matches the checkpoint. Also check routing tables with 'show ip route'.

Watch out: If the checkpoint was taken while interfaces were in a different state (e.g., shutdown), the rollback may restore that state, potentially causing outages.

Troubleshooting with This Command

When using 'rollback running-config checkpoint' for troubleshooting, it is a last-resort tool to revert to a known good state. Before rolling back, ensure that the checkpoint is valid and recent. Use 'show checkpoint' to list available checkpoints and their timestamps. If the rollback fails, the switch will display an error message indicating why (e.g., 'Checkpoint not found' or 'Rollback failed due to incompatible configuration'). In such cases, check the system logs with 'show log' for details. If the rollback succeeds but the device behaves unexpectedly, verify the running configuration immediately. Common issues include interface states being restored to a previous admin state or VLAN configurations being overwritten. Always have a backup plan, such as a startup configuration or external backup, in case the rollback does not resolve the issue. On Nexus platforms, the rollback command does not affect the startup configuration; to make the change permanent, copy the running config to startup with 'copy running-config startup-config'.

CCNA Exam Tips

Remember that rollback replaces the entire running configuration; it does not merge.

Checkpoints are stored in non-volatile memory and persist across reloads.

You must have the 'rollback' privilege to execute this command.

Common Mistakes

Forgetting to create a checkpoint before making changes, leaving no rollback point.

Assuming rollback only reverts specific changes; it replaces the entire config.

Not verifying the running configuration after rollback, leading to unintended state.

Platform Notes

In Cisco NX-OS, the 'rollback running-config checkpoint' command is specific to Nexus switches and is not available on Cisco IOS. The equivalent on IOS is 'configure replace' which uses a file (e.g., 'configure replace flash:backup-config'). On IOS-XE, 'configure replace' is also used. NX-OS checkpoints are stored in the 'volatile:' or 'bootflash:' filesystem depending on the platform. Auto-checkpoints are created by the system before certain operations (e.g., software upgrades) and are named with a timestamp. The 'rollback' command can only roll back to checkpoints; it cannot roll back to the startup configuration directly (use 'copy startup-config running-config' for that). On older NX-OS versions, the rollback command may have limitations, such as not supporting rollback of certain features like VDCs. Always check the release notes for your specific NX-OS version.

Practice for the CCNA 200-301

Test your knowledge with hundreds of CCNA practice questions covering all exam domains.

Practice CCNA Questions