In an interactive session, when you run a command, it’s executed and it changes the running configuration. This behaviour is known as one-stage configuration commit. In the confirm-commit or the two-stage configuration commit, changes in configurations are stored in a staging database. These changes don’t affect the running configuration until you run the commit command. This two-stage process creates a target configuration session, where you can make, edit, and verify configuration changes before committing them to the running state of the switch. You can also commit the changes for a time period you specify before you commit them permanently. After the specified time period, the switch reverts to the previous configuration if you don’t run the commit command. When a commit is successful, you can view the commit information that includes the commit ID, username, and timestamp.

The following figure shows the two-stage configuration commit process.

Two-stage configuration commit has the following configuration guidelines and limitations:

• This feature is supported only for a CLI interface in a user-interactive session.

• Before you run any feature-related configuration commands, enable the feature using the feature command and commit it using the commit command.

• Two-stage configuration commit mode doesn’t support other modes like maintenance mode, scheduler mode, or virtual mode.

• When you’re in the two-stage configuration commit mode, avoid editing configurations in one-stage configuration commit mode from different sessions at the same time.

• Review the configurations using the show configuration command before committing the changes.

• Show configuration displays the staged configs:

  • It displays the real difference, that is yes and no form of the same command will result in empty config.

  • It is recommended to issue the exact no form of the cli to negate the config.

    Example: to negate ‘ip address x’ config, user has to give ‘no ip address x’ instead of ‘no ip address’.

  • Interface layer change commands (switchport/no switchport) should be issued explicitly.

  • Any invalid config in the session should manually be removed by the user before attempting commit. If could not remove manually clear the session and start a new session.

• If the verification fails, edit and retry the commit.

• If the commit fails, the configuration rolls back to the previous configuration.

• Configurations that you don’t commit aren’t saved after you reload the switch.

• This feature doesn’t support commits with NX-API, EEM, PPM and Netconf.

• You can have only one active two-stage configuration commit session at a given time.

• N9K-C92348GC-X supports two-stage configuration commit from Cisco NX-OS Release 10.5(1)F.

When you abort a configuration session, uncommitted changes are discarded and the configuration session ends. No warning appears before the configuration changes are deleted.

switch(config-dual-stage)# router bgp 1
switch(config-dual-stage-router)# neighbor 1.2.3.4
switch(config-dual-stage-router-neighbor)# remote-as 1
switch(config-dual-stage-router-neighbor)# show configuration 
! Cached configuration
!
router bgp 1
neighbor 1.2.3.4
remote-as 1
switch(config-dual-stage-router-neighbor)# show run bgp 

!Command: show running-config bgp
!Running configuration last done at: Wed Mar 17 16:17:40 2021
!Time: Wed Mar 17 16:17:55 2021

version 10.1(2) Bios:version 
feature bgp


switch(config-dual-stage-router-neighbor)# abort
switch# show run bgp

!Command: show running-config bgp
!Running configuration last done at: Wed Mar 17 16:18:00 2021
!Time: Wed Mar 17 16:18:04 2021

version 10.1(2) Bios:version 
feature bgp

switch#

switch# show configuration commit list
SNo. Label/ID     User     Line         Client     Time Stamp
~~~~ ~~~~~~~~~~~~ ~~~~~~~~ ~~~~~~~~~~~~ ~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
1    1000000001   admin    /dev/ttyS0   CLI        Wed Jul 15 15:21:37 2020
2    1000000002   admin    /dev/ttyS0   Rollback   Wed Jul 15 15:22:15 2020
3    1000000003   admin    /dev/pts/0   CLI        Wed Jul 15 15:23:08 2020
4    1000000004   admin    /dev/pts/0   Rollback   Wed Jul 15 15:23:46 2020

You can rollback the configuration to any of the previous successful commits. Use the rollback configuration command to rollback to any of the last 50 commits.

switch# rollback configuration to ?
1000000015
1000000016
1000000017

:
:

switch#

Each commit ID acts as a (checkpoint or) rollback point. You can rollback to any given
commit ID. When you roll back the configuration to a specific rollback point, you undo
all configuration changes made during the session identified by the commitID for that
rollback point, and you undo all configuration changes made after that point. The
rollback process rolls back the configuration and commits the rolled-back configuration.
The rollback process also creates a new rollback point (commit ID)so that you can roll
back the configuration to the previous configuration.


switch(config-dual-stage)# rollback configuration to 1000000002
Rolling back to commitID :1000000002
ADVISORY: Rollback operation started...
Modifying running configuration from another VSH terminal in parallel
is not recommended, as this may lead to Rollback failure.

Configuration committed by rollback using Commit ID : 1000000004
switch(config-dual-stage)#

You can view the current session configuration using the show configuration command. This command is supported only in the dual-stage mode. The session configuration is cleared if a commit fails.

switch(config-dual-stage-cmap)# show configuration
! Cached configuration
!
class-map type control-plane match-any copp-s-ipmcmiss
class-map type control-plane match-any copp-s-l2switched
class-map type control-plane match-any copp-s-l3destmiss
switch(config-dual-stage-cmap)#

If there is no configuration, the following message appears:

switch(config-dual-stage)# show configuration
! Cached configuration
switch(config-dual-stage)# commit
No configuration changes to commit.
switch(config-dual-stage)#