The main thing with Cisco that causes issues (IOS specifically) is that once you enter a command it is applied. There is no staging, no candidate config like JunOS / Palo Alto thats it you have applied it.
Imagine writing some config to apply to thausands of devices to add a new vlan to a tagged / trunk port (Classic scenario) , but you dont add the add keyword, you are basically screwed …
This has happened and will continue to, however there is the ability to prvide some level of fallback when you apply config. I dont get why Cisco do not push it more or make it a default (There probably is some reason) Anyhow here is an example of how you can set it up.
There are multiple ways of achieveing this, but the logic is as follows.
1 – you create a script with a timer
2 – You setup config archive
3 – You apply your config
4 – Apply this logic
If a command / connectivity is not entered before the timeout, rollback to the last known config
This ensures that if a command wrecked management connectivity a rollback would occur (Much like JunOS commit confirmed x command), the TCL script can be altered to suit
In brief this minimises downtime by providing rllback capabilities, tailored to your environment this could be used moving forward for all changes.
Using Archive Configurations on Cisco IOS for Rollback Capabilities with TCL Script
Introduction
Cisco IOS supports the archive configuration feature, allowing network administrators to store multiple versions of the device configuration. This feature enables rollback capabilities in case of configuration errors or unwanted changes. In this guide, we’ll explore how to configure archive configurations on Cisco IOS devices to store backups locally and include a TCL script to automate the rollback process if a specific command is not entered within a specified time frame.
Setup
Before getting started, ensure you have access to a Cisco IOS device with administrative privileges.
Step 1: Configure Archive Settings
First, configure the archive settings on the Cisco IOS device to specify the maximum number of configuration versions to retain and the frequency of configuration checks.
# Configure archive settings
config t
archive
log config
logging enable
logging size 100
hidekeys
notify syslog contenttype plaintext
path flash:/archive
In the above commands:
logging enable: Enables logging of configuration changes.logging size 100: Specifies the maximum number of entries in the configuration history.hidekeys: Hides passwords in the configuration history.notify syslog contenttype plaintext: Notifies changes to the syslog server.path flash:/archive: Specifies the local directory to store configuration backups.
Step 2: Verify Archive Configuration
Once configured, verify that the archive settings are applied correctly and that configuration changes are being logged.
# Verify archive configuration
show archive
show archive log config all
Step 3: Implement TCL Script for Automated Rollback
To automate the rollback process if a specific command is not entered within a specified time frame, create a TCL script as follows:
::cisco::eem::event_register_timer countdown time 300
namespace import ::cisco::eem::*
proc check_command {} {
if {[catch {cli_exec "show archive config differences nvram:startup-config system:running-config"} result]} {
# Rollback to the latest archived config
set rollback_cmd "configure replace flash:/archive/latest_config"
cli_exec $rollback_cmd
action_syslog msg "Rollback to the latest archived configuration due to no trigger command within the specified time."
action_syslog info "Executed command: $rollback_cmd"
}
}
check_command
In this script, if the ROLLBACK_TRIGGER command is not entered within 300 seconds, it will trigger the rollback process to the latest archived configuration.
Conclusion
By configuring archive configurations on Cisco IOS devices to store backups locally and implementing a TCL script for automated rollback, network administrators can ensure rollback capabilities and quickly revert to previous configuration versions in case of errors or unwanted changes without manual intervention. This feature enhances network management and reduces the risk of downtime caused by misconfigurations.
