MAR

19

Cisco Auto Config Backup Archive and KRON

Manual Backup & Restore

Configure your Cisco Router or Switch FTP settings
Iv previously configured a username: ftp1 with a password: cisco on my vsftp server. That will be
used for this purpose.
Configure the clock with the current time.
CR1# clock set 11:41:00 4 April 2012
CR1#
*Apr 4 11:41:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from
00:09:40 UTC Fri Mar 1 2002 to 11:41:00 UTC Wed Apr 4 2012, configured from
console by console.
CR1# show clock
11:41:09.783 UTC Wed Apr 4 2012
CR1#
Configure FTP login parameters
CR1# conf t
CR1(config)# ip ftp username ftp1
CR1(config)# ip ftp password cisco
CR1(config)# end
CR1#
Backup running-config to ftp server (192.168.1.131)
CR1# copy running-config ftp:
Address or name of remote host []? 192.168.1.131
Destination filename [cr1-confg]? backup-config01
Writing backup-config01 !
833 bytes copied in 2.800 secs (298 bytes/sec)
Here is the tail output from the vsftpd server log:
Wed Apr 4 23:42:29 2012 1 192.168.1.14 833 /backup-config01 b _ i r ftp1 ftp 0 *
c
Note: to restore the config file into nvram just issue: copy tftp: running-config
Automatic Local Backup using Kron
This task is configured in three steps.
Step 1. Create a kron policy-list.
This will tell what commands the router should run at the scheduled time.
CR1(config)# kron policy-list AutoSaveConfig
CR1(config-kron-policy)# cli write
CR1(config-kron-policy)# exit
Step 2. Create the kron occurrence.
This tells the router when and how often the policy should run.
CR1(config)# kron occurrence AutoSaveConfigSchedule at 00:40 Thu recurring
CR1(config-kron-occurrence)# policy-list AutoSaveConfig
Verify the kron configuration.
CR1# sh kron schedule
Kron Occurrence Schedule
AutoSaveConfigSchedule inactive, will run again in 0 days 00:05:36 at 00:35 on
Thu
You can view the kron configuration in the running-config:
CR1# show run | s kron
kron occurrence AutoSaveConfigSchedule at 00:35 Thu recurring
policy-list AutoSaveConfig
kron policy-list AutoSaveConfig
cli write
 Automatic Backup to vsftpd FTP Server using Kron
Ill send the router’s running-config to my svftpd FTP server 192.168.1.131, every Thursday at
01:30:00.
CR1(config)# kron policy-list Backup_FTP
CR1(config-kron-policy)# cli show run | redirect
ftp://192.168.1.131/ciscoback1.cfg
CR1(config-kron-policy)# exit

CR1(config)# kron occurrence Backup at 01:30 Thu recurring

CR1(config-kron-occurrence)# policy-list Backup_FTP
CR1(config-kron-occurrence)# end

CR1# show kron schedule

Kron Occurrence Schedule
AutoSaveConfigSchedule inactive, will run again in 0 days 00:02:00 at 1 :30 on
Thu
Backup inactive, will run again in 0 days 00:01:22 at 1 :30 on Thu
Here is tail output from the vsftpd log:
Thu Apr 5 01:29:48 2012 1 192.168.1.14 1044 /ciscoback1.cfg b _ i r ftp1 ftp 0
* c
And here is the confirmation in the running-config that the backup was successful.
CR1# show run
Building configuration...
!
Current configuration : 1042 bytes
!
! Last configuration change at 01:25:17 UTC Thu Apr 5 2012
! NVRAM config last updated at 01:30:39 UTC Thu Apr 5 2012

One of the most important tasks of a network administrator is to backup the network configuration
files of every Cisco device periodically. This periodicity is dictated and established by the
organization policies. Frequency could be every week, every fifteen days or every month
depending on the needs of the organization.

The importance of the configuration files of the network can be seen from many administrative
perspectives:

 Compare and validate configurations between devices.

 In case of any damage of the equipment, configuration files could be used to restore the operational state of the network
with a simple copy and paste of the configuration in another device.
 To rollback configurations to a previous state.

Now, imagine a network with five devices, a backup in this scenario is very simple for a network
administrator. Since only five devices reside in the network, you could access via console, telnet or
ssh into the router and save the configuration in a TFTP server executing the following command
on every device:

R1#copy running-config tftp://<SERVER_IP>/<CONFIGURATION_FILE_NAME/

But what if you have fifty or even one hundred devices? In this type of scenario it is hard to
manually perform backups. The network administrator will be subject to what is often called
“administration burden” because of the amount of devices that have to be manually accessed and
executed the previous command. For this type of situation, you have a variety of external options
available (third party applications), but one that is often overlooked by some network administrators
that is part of the feature set of your Cisco device is the Cisco IOS Auto Archive Feature.

This feature was introduced into Cisco IOS Release 12.3(4), the Archive command enables the
administrator to configure snapshots of the configuration files. The configuration is straightforward.

R1#conf t

Enter configuration commands, one per line. End with Ctrl+Z.

R1(config)#archive
R1(config-archive)#path tftp://172.16.1.10/
Router(config-archive)#time-period 1440
R1(config-archive)#exit
R1(config)#exit

In this case we entered into the global configuration mode and use the “path” command; this set
the path to an external server, in this case a TFTP with the 172.16.1.10 IP address. These are the
necessary commands in order to configure a basic Archive. To test our configuration we could
execute the “archive config” privilege mode command.

R1#archive config

If the TFTP is operational, it should produce the following output.

R1#archive config
!!

Now we can go to the TFTP directory in order to validate if the configuration was successfully sent.

And we see how the configuration file is stored as "-1", this is because, by default, the Archive
feature saves the configuration in increments of one. We can see this if we perform another
manual configuration, save and execute the "show archive" command.

R1#show archive
The next archive file will be named
tftp://172.16.1.10/-3

Archive # Name
0
1 tftp://172.16.1.10/-1
2 tftp://172.16.1.10/-2 <- Most Recent
3
4
5
6
7
8
9
10
11
12
13
14

We see that in the history of the router, the archive tells us that configuration was sent to the TFTP
with the name "-2" and is the most recent. In this output you can note that Archive can only
maintain a maximum registry of 15 configuration files inside the router.

For administration purposes, the default naming convention is not very filexible, because it is not
telling us anything about the device itself. If we want to rapidly identify a device in the directory, we
can use the hostname of the device itself. For this we have two possible options: hardcode the
hostname of the device or set a name variable using "$h" in order to automagically send the
configuration name with the current hostname of the device.

Hostname in Path

R1(config)#archive
R1(config-archive)#path tftp://172.16.1.10/R1
R1(config-archive)#exit

Note that in this case, if the hostname of the device changes in the future to, let's say, R2 the
archive configuration will still send the configuration file with the name set to "R1". For this
purporses we have the second mentioned option.

Hostname Variable in Path

R1(config)#archive
R1(config-archive)#path tftp://192.168.2.2/$h
R1(config-archive)#exit

If we manually save the configuration and then execute the "show archive" command we can see
the results of the configuration.

R1#archive config
!!
R1#show archive

The next archive file will be named

tftp://172.16.1.10/R1-2

Archive # Name
0
1 tftp://172.16.1.10/R1-1 <- Most Recent
2 tftp://172.16.1.10/-2
3 tftp://172.16.1.10/-3
4
5
6
7
8
9
10
11
12
13
14

We can visualize that the most recent configuration file sent is named as "R1-1" which has the
index set to 1.

At this point, it is very easy for an administrator to manually backup the configuration files of the
devices in the network, but the problem partially persists, because this is a manual process. If we
want to sort of "overcome" this we can enable the "write-memory" command inside the Archive
configuration mode. This allows the router to automagically perform the backup instead of
manually saving the configuration.

Time Variable in Path

We could also configure a time variable in the naming convention of the archive configuration. This
is to have the date in the name of the file in the TFTP backup folder.

R1(config)#archive
R1(config-archive)#path tftp://172.16.1.10/$h-$t
R1(config-archive)#exit

If we execute the "archive config" command we can see that the time is set in the name of the file.

Archive Write-Memory Option

R1(config)#archive
R1(config-archive)#write-memory
R1(config-archive)#exit

If we execute the "write memory" or "copy running-config startup-config" commands we can see
that the configuration is automatically stored in the TFTP folder.
The "copy running-config startup-config" responds with "[OK]!!" which is the acknowledgement of
the TFTP. With this operation, the local configuration changes are saved and automatically sent to
the TFTP server.

If we need to save the configuration file every certain amount of time, we can use the "time-period"
operation. This option allows us to perform the configuration backup every certain amount time,
this way we don't have to manually console, telnet or ssh into the device. The "time-period" option
must be set in minutes, therefore if according to the organization policies, backups need to be
executed every week, we would need to configure a time period of 10080.

Archive Time-Period Option

R1(config)#archive
R1(config-archive)#time-period 10080
R1(config-archive)#exit

The next backup will be performed in one week exactly (time in minutes), but what if we would like
to configure this periodicity with an explicit date time? Unfortunately with the current Archive
features, it is not possible. In that case we could combine the Archive feature with Kron Schedule.

Kron is a command scheduler used to automate tasks in the Cisco IOS Software. With Kron, we
can set policies and use them once or with a certain periodicity. For this we configure a Kron Policy
List and then apply an occurrence to the global Kron policy. Note that Kron does not work with
interactive commands, meaning commands that have some type of dialog for validation. An
example would be "copy running-config startup-config". In this case, a dialog would appear in order
to validate the execution of the sentence. Since we have this "limitation" with that sentence, we
could use the "write memory" command which does not need any validation and use it in the Kron
Policy.

in order to get a router to copy the running-config to startup-config, for

example every Sunday at 23:00, complete these steps:

1 - Create a kron policy list—This is the script that lists what commands the router should run at the
scheduled time.

Router#enable
Router#configure terminal
Router(config)#kron policy-list Backup
Router(config-kron-policy)#cli show startup-config | redirect tftp://192.168.1.252/test.cfg
Router(config-kron-policy)#exit

cli—Specifies EXEC CLI commands within a Command Scheduler policy list.

policy-list—Specifies the policy list associated with a Command Scheduler occurrence.
Note: The reason why write was used rather than copy running-config startup-config is because kron does
not support interactive prompts and the copy running-config startup-config command requires interaction. It
is important to remember this when you create commands. Also, note that kron does not support
configuration commands.

2 - Create a kron occurrence—This informs the router when and how often the policy should run.

Router(config)#kron occurrence SaveConfigSchedule at 23:00 Sun recurring

Router(config-kron-occurrence)#policy-list Backup

SaveConfigSchedule—This is the name of occurrence. Length of occurrence-name is from 1 to 31

characters. If the occurrence-name is new, an occurrence structure will be created. If the occurrence-name is
not new, the existing occurrence will be edited.

at—Identifies that the occurrence is to run at a specified calendar date and time.
recurring—Identifies that the occurrence is to run on a recurring basis.
R2(config)#kron policy-list SystemBackup
R2(config-kron-policy)#cli write
R2(config-kron-policy)#cli cli show run | redirect tftp://10.1.1.1/test.cfg
R2(config-kron-policy)#exit

R2(config)#kron occurrence SystemBackup at 23:00 Sun recurring

R2(config-kron-occurrence)#policy-list SystemBackup