Until yesterday it was working

If you, too, are someone who likes to play around with your devices, testing features and enhancements, sooner or later you’ll discoveryou know that it is most important to keep track of changes made in configuration.
Or just think of what I call the Cisco classic: that last fundamental wr (write memory) that you forgot to run and that made you so happy after an unexpected reboot!
Here then is where versioning, that is, keeping track of the different versions of our conf, monitoring the changes made over time, archiving and easily retrieving previous versions should the need arise, is critical.
If you can also automate this operation, it’s a nice plus no? Let’s see how…

Create Cisco read-only user

We will need a user to access our Cisco that has permissions to run show run and NO, you will not use your user or the admin account.

Following the principle of least privilege (PoLP), we will use a user dedicated to our purpose that has only the strictly necessary privileges i.e. read only of the configuration.

We add the user readonly_user with privilege level 4 and password readonly_pass 

cisco-lab#conf t
cisco-lab(config)#username readonly_user privilege 4 secret readonly_pass

We then add the commands we want to enable for privilege level 4 

cisco-lab(config)#privilege exec level 4 show running-config view full

And add file permissions on privilege level 4 

cisco-lab(config)#file privilege 4

Without this, on recent versions of IOS, it is not possible to read the contents of the flash and nvram so the show run output would be empty.

All that remains is to plan the configuration retrieval task and its handling.
Here you’ll see two different approaches, both of which can be customized as needed.

Automatic Verification and Archiving with Zabbix

We talk a lot about Zabbix and personally I’m a big fan of it, so if you’re already using it, it’s obviously the easiest choice:

  • add an Item of type SSH agent
  • make it run show running-config view full

and based on what we want to achieve we will then go on to customize the scheduling, history and any Triggers.
For my needs, for example, I created a Template that you can find on my GitHub.

Use is very simple, after setting up the MACRO for SSH access. cisco zabbix ssh will store 1 configuration per day and create 2 Triggers for these events:

  • configuration changed
  • unable to retrieve data

Scripting Cisco with Expect

The second possibility we discuss is scripting, specifically with Expect.
Expect is an extension of the Tcl scripting language that, quoting man, “talks” to interactive terminals and following a script knows what to expect (yes indeed) from them and how to respond.

We can then script configuration capture and integrate it with our storage needs:
full on a time basis, diff, git, in short whatever you like–starting with this configdump.exp 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#!/usr/bin/expect -f
 
# Variables
 set hostname [lindex $argv 0]
 set username [lindex $argv 1]
 set password [lindex $argv 2]

# Suppress output
 log_user 0
 
# Disable key check if needed
 spawn ssh -o StrictHostKeyChecking=no $username\@$hostname
 
# Enable SSH timeout notification
 expect {
  timeout { send_user "\nTimeout - Check Device\n"; exit 1 }
  eof { send_user "\nSSH Connection To $hostname Failed\n"; exit 1 }
  "*#" {}
  "*assword:" {
   send "$password\n"
  }
 }
 
 expect "*#"
 send "term len 0\n"
 expect "*#"
 
 match_max 65535
 send "show running-config view full\n"
 expect {
  # look for output beginning with "!" and get til final "end"
  -re "!(.*)\nend(\r?\n|$)" {
   set output $expect_out(0,string)
   send "exit\n"
   expect ":~\$"
   send_user $output
   exit 0
  }
  # exit with error
  default {exit 1}
 }

The execution is detailed in the comments: it involves handling interactive input and output through simple sequences of expect Cisco patterns and send the necessary commands.
To execute it we will only have to pass our device parameters to get the configuration output with exit status 0 in case of success, or exit status 1 in case something went wrong. 

1

./configdump.exp CISCO_IP readonly_user readonly_pass

Conclusions

Notwithstanding the need to automate an important activity, as you have seen the proposed solutions are “open” to customizations, even very vertical ones.
Indeed, the intent is to give you the input you need to create your own integration that can be tailored to your existing processes!
Which one will you use? And how? Let us know in the comments!