Cisco Object Tracking using IP SLA

One of the very useful features of Cisco's IOS is the track command which allows you to track certain events, based on that events you can take actions. Since this is a very big topic i will split on different posts. Let's first get familiar with the track  command and we will build our scenarios on what it can do

The track command as the name implied detects the state of a certain variable, this variable can be one of many, but i'll just give an example of some of the things that it can observe

• a route in the routing table, wether it exists or not
• an Interface state
• reachability to a certain host ( in conjunction with IP SLA )

this can be very useful in different situations where the router or switch would be able to act on its on in case an event happened. Let's elaborate this with the following topology

Lets assume here that R1 is connected to two switches, both switches are connected to R4.

R1 has two default routes, one which is the main default route with admin distance of 1 and the backup default route with the admin distance of 200. There is no IGP running in this topology.

However, the first default route is pointing to next-hop IP 10.1.4.4, the backup default route is pointing to next-hop IP of 20.1.4.4. Now, here's the real problem. Ethernet unlike many other L2 protocols doesn't detect remote hops failure, meaning that if the link between R4 and SW1 went down, the link between R1 and SW1 will still be up even though the Layer-3 termination of the subnet 10.1.4.0/24 is on R1 and R4, R1 will know nothing about the failed link between R4 and SW4. 

Let’s first check the normal operation of the setup we have on hand.

R1#show run | i ip route

ip route 0.0.0.0 0.0.0.0 10.1.4.4

ip route 0.0.0.0 0.0.0.0 20.1.4.4 200

R1#show ip route

Gateway of last resort is 10.1.4.4 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     20.0.0.0/24 is subnetted, 1 subnets

C       20.1.4.0 is directly connected, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.4.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.4.4

As you can see, the first default route is the only one installed in the routing table due to its lower admin distance.

R1#show ip int brief

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            10.1.4.1        YES manual up                    up     

FastEthernet0/1            20.1.4.1        YES manual up                    up     

Loopback0                  1.1.1.1         YES manual up                    up

All the interfaces are up and everything seems good, now let’s ping R4 loopback sources from R1 loopback

R1#ping 4.4.4.4 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 4/52/124 ms

Seems legit, now let’s simulate a failure between R4 and SW1 by shutting down the interface from R4 side

R4(config)#int f0/1

R4(config-if)#shut

R4(config-if)#

*Mar  1 00:47:51.691: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down

*Mar  1 00:47:52.691: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

Now the whole path of the main default route isn’t usable, but still the F0/0 interface and the main default route is pointing to F0/0

R1#show ip int brief

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            10.1.4.1        YES manual up                    up     

FastEthernet0/1            20.1.4.1        YES manual up                    up     

Loopback0                  1.1.1.1         YES manual up                    up     

R1#show ip route

Gateway of last resort is 10.1.4.4 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     20.0.0.0/24 is subnetted, 1 subnets

C       20.1.4.0 is directly connected, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.4.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [1/0] via 10.1.4.4

Now if we try to ping, the ping will ofcourse fail

R1#ping 10.1.4.4

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.4.4, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

This is where tracking comes into play, since R1 isn’t by default aware by remote Ethernet links state, we can make it track events that might indicate that the link is down, and based on that it can remove the main default route and install the backup routes instead. Here’s how we can do this.

To make it more easier, we’re going to send probes to  10.1.4.4 through interface F0/0 , and we’re going to track it, in case the probes failed, we’re going to switch to remove the main default-route, which ultimately means the other default route will be installed instead

First let’s create a SLA object to start pinging our next-hop IP from the desired interface

R1(config)#ip sla 1?

<1-2147483647> 

R1(config)#ip sla 1

R1(config-ip-sla)#icmp-echo 10.1.4.4 source-interface f0/0

Now we need to specify atleast three parameters to make this work

R1(config-ip-sla-echo)#frequency ?

  <1-604800>  Frequency in seconds (default 60)

R1(config-ip-sla-echo)#frequency 5

R1(config-ip-sla-echo)#timeout ?

  <0-604800000>  Timeout in milliseconds

R1(config-ip-sla-echo)#timeout 1000

R1(config-ip-sla-echo)#threshold ?

  <0-2147483647>  Millisecond threshold value

R1(config-ip-sla-echo)#threshold 1000

Basically, here’s the definition of each of those

·         Frequency (sec) is how often do you want to send a probe

·         Timeout (msec) is what is the absolute timeout if there’s no reply for the probe sent

·         Threshold (msec) the probe was replied but it exceeded a certain amount of time

Keep in mind that the threshold has to have a lower value than the timeout, which makes sense.

After we created the SLA object, we need to activate it by determining when it should run and for how long this probe should be periodically sent.

R1(config)#ip sla schedule 1 life forever start-time now

We just indicated that I want to start SLA object 1 immediately and make it loop forver

Let’s check if it’s working

R1#sh ip sla statistics 1

Round Trip Time (RTT) for       Index 1

        Latest RTT: 32 milliseconds

Latest operation start time: *01:16:38.391 UTC Fri Mar 1 2002

Latest operation return code: OK

Number of successes: 1

Number of failures: 13

Operation time to live: Forever

R1#sh ip sla statistics 1

Round Trip Time (RTT) for       Index 1

        Latest RTT: 32 milliseconds

Latest operation start time: *01:16:38.391 UTC Fri Mar 1 2002

Latest operation return code: OK

Number of successes: 12

Number of failures: 0

Operation time to live: Forever

It seems that our probes are working just fine, now all we need to do is track these probes states to take actions in case it failed.

R1(config)#track 1 rtr 1 reachability

R1(config-track)#delay ?

  down  Delay down change notification

  up    Delay up change notification

R1(config-track)#delay up ?

  <0-180>  Seconds to delay

R1(config-track)#delay up 2

R1(config-track)#delay down ?

  <0-180>  Seconds to delay

R1(config-track)#delay down 2

Keep in mind that Cisco has always been inconsistent with it’s commands, the old name for IP SLA was RTR, now they changed the RTR to SLA syntax but for some unknown reason they didn’t change it under the track command, so rtr 1 here refers to the sla 1 object.

What we just configured here is a tracking instance that observes the start of the SLA object reachability to 10.1.4.4. the delay up refers to the amount of time the track should wait before reacting after it detects that the SLA has reachability, and delay down is what time should it wait until it indicated that the reachability is down. This is useful because in case of flapping links you don’t router to act instantly, you might need to give it time to switch between 2 states

R1#show track 1

Track 1

  Response Time Reporter 1 reachability

  Reachability is Up

    1 change, last change 00:08:31

  Delay up 2 secs, down 2 secs

  Latest operation return code: OK

  Latest RTT (millisecs) 84

Associating the track with our main default-route, we should be good to go

R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.4.4 track 1

R1#sh run | i route

ip route 0.0.0.0 0.0.0.0 10.1.4.4 track 1

ip route 0.0.0.0 0.0.0.0 20.1.4.4 200

Now let’s simulate a failure again between R4 and SW1 by shutting the interface F0/1 on R4. Here’s what happens afterwards on R1

R1#

*Mar  1 01:34:18.587: %TRACKING-5-STATE: 1 rtr 1 reachability Up->Down

R1#

*Mar  1 01:34:18.587: RT: del 0.0.0.0 via 10.1.4.4, static metric [1/0]

*Mar  1 01:34:18.591: RT: delete network route to 0.0.0.0

*Mar  1 01:34:18.591: RT: NET-RED 0.0.0.0/0

*Mar  1 01:34:18.591: RT: NET-RED 0.0.0.0/0

*Mar  1 01:34:18.591: RT: add 0.0.0.0/0 via 20.1.4.4, static metric [200/0]

*Mar  1 01:34:18.591: RT: NET-RED 0.0.0.0/0

*Mar  1 01:34:18.591: RT: default path is now 0.0.0.0 via 20.1.4.4

*Mar  1 01:34:18.595: RT: new default network 0.0.0.0

*Mar  1 01:34:18.595: RT: NET-RED 0.0.0.0/0

R1#show ip route

Gateway of last resort is 20.1.4.4 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets

C       1.1.1.1 is directly connected, Loopback0

     20.0.0.0/24 is subnetted, 1 subnets

C       20.1.4.0 is directly connected, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.4.0 is directly connected, FastEthernet0/0

S*   0.0.0.0/0 [200/0] via 20.1.4.4

The backup default route is now installed in the routing table eliminating the Ethernet problem we had before.

R1#sh ip sla statistics

Round Trip Time (RTT) for       Index 1

        Latest RTT: NoConnection/Busy/Timeout

Latest operation start time: *01:35:58.391 UTC Fri Mar 1 2002

Latest operation return code: Timeout

Number of successes: 176

Number of failures: 70

Operation time to live: Forever

The IP SLA indicated that the reason for failure due to timeout, in case it was the threshold, the return code would’ve been threshold. And the latest RTT indicated that there is no connection.

R1#show track

Track 1

  Response Time Reporter 1 reachability

  Reachability is Down

    4 changes, last change 00:04:01

  Delay up 2 secs, down 2 secs

  Latest operation return code: Timeout

  Tracked by:

    STATIC-IP-ROUTING 0

Now we should be able to ping from R1 lo0 to R4 lo0 without a problem

R1#ping 4.4.4.4 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 20/25/36 ms

In the next couple of posts, we’ll dig deeper with advanced configuration of SLA and tracking, overcoming lots of problems we face in our networks.

Configuring a Cisco router as a Domain Name Service server (DNS server) - Basic Configuration

In the internet world, every host is identified by an IP address. The purpose of DNS (Domain Name 

Service) is to translate simple names than can be understood and memorized easily by us; humans, to those IP addresses since it will nearly impossible to memorize the IP address of all the websites you use.

Cisco’s IOS can act as a DNS server, of course it might not scale to big DNS servers out there, but it might come in handy in many situations.

Let’s check this topology

Let’s assume for a moment here that google.com server is attached to R4 and it has an IP address 44.44.44.44. R1 is trying to ping google.com. the configuration can be split into 2 parts.

1-      DNS server configuration

Let’s first enable DNS

DNS(config)#ip dns server

Now that we enabled DNS, we need to statically map the domain name to the ip address of google.com

    

DNS(config)#ip host google.com 44.44.44.44

let’s check our configuration so far

DNS#show hosts

Default domain is lab.local

Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

       temp - temporary, perm - permanent

       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

google.com                None  (perm, OK)  0   IP    44.44.44.44

The configuration is pretty simple indeed, now let’s configure R1 to resolve host name via DNS router

2-   DNS client

First, let’s identify the name-server that we will send DNS requests to, in our case its IP address is 3.3.3.3

    

R1(config)#ip name-server 3.3.3.3

Now let’s enable name lookup ability on R1

     R1(config)#ip domain lookup

Let’s test with ping

                R1#ping google.com

Translating "google.com"...domain server (3.3.3.3) [OK]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 44.44.44.44, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 40/42/48 ms

From the output shown above, it is clear that R1 used the DNS server 3.3.3.3 and that server replied that the host being fetched has an IP address of 44.44.44.44.

Let’s see how the DNS reacted to the request, first let’s enable the debug

DNS#debug domain

Domain Name System debugging is on

*Mar  1 00:34:34.387: DNS: Incoming UDP query (id#41532)

*Mar  1 00:34:34.387: DNS: Type 1 DNS query (id#41532) for host 'google.com' from 10.1.2.1(59224)

*Mar  1 00:34:34.391: DNS: Servicing request using view default

*Mar  1 00:34:34.391: DNS: Reply to client 10.1.2.1/59224 query A

*Mar  1 00:34:34.391: DNS: Finished processing query (id#41532) in 0.004 secs

*Mar  1 00:34:34.391: DNS: Sending response to 10.1.2.1/59224, len 44

You can see that the server identified this as a Type-1 DNS query which means that the requester needs to resolve a hostname into an IP address, other requests like Type-2 might be for an email address and so on. The DNS query number is to identify every request on it’s own, since a single host might request many addresses, this is to distinguish them from one another.

Finally after the DNS server finds the hostname, it replies to R1 with the IP address  of the desired host.

Understanding and configuring SNMPv3

SNMPv3 was introduced to increase security over the previous version SNMPv2c which used clear text communities to authorize SNMP operations by introducing a new security model.

The security model consists of two mains parameters,

1. Authentication (Auth):Which makes sure the proper user is using the service and it is hashed with either MD5 or SHA1.
2. Privacy (Priv): Which encrypts the data between the host and the server and it utilizes DES, 3DES or AES as an encryption methods.

Both Auth and Priv can be combined to form the security model that SNMPv3 uses to operate which can be illustrated in those three methods:

1. NOAuthPriv: No authentication and No Privacy
2. AuthNoPriv: Authentication and No Privacy
3. AuthPriv: Authentication and Privacy

The Structure of SNMPv3 consists of Groups and Users attached to those groups

• SNMP Groups: they contain access control policies to which users with certain privileges. these privileges mainly are the SNMP view they are going to either read or read/write to.
• SNMP Users: The users are assigned with a group, along with the security models they will be using ( Auth and Priv)
• SNMP Hosts: SNMP hosts are servers that recieves pushed SNMP notifications and traps. Since notifications and traps are pushed to the server, each server can be associated with only one user.

Note: SNMP uses either pull or push communication with the server. Pull is when the server requests to read or write something to the router or switch. Push is when the router or switch sends trap or notification to the server. Both are not dependent on each other, you can configure one or both of them

Now let's start configuring SNMPv3

First you have to define a view, which is the part or the MIB tree you want use, in our exmple here we will use two views, ISO view for for read only and we will call it READ and SYSTEM view for read/write and we will call it WRITE

snmp-server view READ iso includedsnmp-server view WRITE system included

Now we need to configure the SNMP group called MANAGMENT that uses both the READ and WRITE views for its associated users

snmp-server group MANAGMENT v3 priv read READ write WRITE

Now let's confirm that with show snmp group

 R1#show snmp group
groupname: ILMI                             security model:v1
readview : *ilmi                            writeview: *ilmi                        
notifyview: <no notifyview specified>    
row status: active
groupname: ILMI                             security model:v2c
readview : *ilmi                            writeview: *ilmi                        
notifyview: <no notifyview specified>    
row status: active
groupname: READGROUP                        security model:v3 priv
readview : READ                             writeview: WRITE                        
notifyview: <no notifyview specified>    
row status: active

Lets associate two users to the MANAGMENT group. READUSER and WRITEUSER

snmp-server user READUSER MANAGMENT v3 auth sha READuserAUTHENTICATIONpassword priv aes 128 READuserPRIVACYpassword

snmp-server user WRITEUSER MANAGMENT v3 auth sha WRITEuserAUTHENTICATIONpassword priv aes 128 WRITEuserPRIVACYpassword 

One thing you'll notice that when you're showing the running-configuration, the user's line will not be shown, in order to see what SNMPv3 users configured you'll have to use the command show snmp user.

R1#show snmp user 

User name: READUSER
Engine ID: 800000090300C2000F940000
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: MANAGMENT

User name: WRITEUSER
Engine ID: 800000090300C2000F940000
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: MANAGMENT

That looks promising, we have now configured SNMPv3 and NMS servers can pull SNMP info from the router or switch. How about configuring the router to push traps incase of a BGP event using SNMPv3, we will use user READUSER that was configured previously for that task

snmp-server host 200.0.0.1 version 3 priv READUSER bgp

let's verify that

R1#show snmp host

 Notification host: 200.0.0.1    udp-port: 162   type: trapuser: READUSER  security model: v3 priv

Resolving OSPF neighbor router-id to hostname

In Large networks, you may find it hard to remember which OSPF neighbor is on a certain link. Of course if you can memorize the router-id of each router in your network that would be amazing, but for someone like me it can be a pain while working on something that needs to be done fast since i have to jot down the topology with IPs on just to remember who's who in the network.

Luckily, there's a command in Cisco IOS that can resolve OSPF neighbor router-id into it's hostname.

ip ospf name-lookup

This is a Global configuration command, now let's see how a typical OSPF show neighbor command looks like

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

2.2.2.2           1   FULL/DR         00:00:31    10.1.2.2        FastEthernet1/0

As you can see, R1 see neighbor R2 by it's router-id, now let's make it see it by hostname

First we need to map R2 hostname to the IP on R1 then configure OSPF router-id hostname resolving.


R1(config)#ip host R2 2.2.2.2

R1#show hosts
Default domain is not set
Name/address lookup uses domain service using source interface Loopback0
Name servers are 2.2.2.2
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined
Host                      Port  Flags      Age Type   Address(es)
R2                        None  (perm, OK)  0   IP    2.2.2.2

As shown above, the hostname R2 can now be resolved to 2.2.2.2 locally on R1, now let's make OSPF resolve hostnames from router-ids

R1(config)#ip ospf name-lookup

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface

R2                1   FULL/DR         00:00:33    10.1.2.2        FastEthernet1/0

As you can see now, the show command displays the hostname instead of the router-id, which be very useful. one thing to notice though is that if you're using an external DNS server for name resolution, it can get very slow when using the show commands because of the name lookup process.

Cisco IOS Configuration Archiving

Juniper has always been easier when rolling back configuration in case you messed up or you just wanted to try something and revert back to your good old working configuration, you can literally rollback to your old configuration with one command rollback 1  and you're back to the previous configuration. Cisco has a similar thing, although tedious; but it nearly gets the job done. The archive  command. There's a similar way to do this using the configure replace command.

You can get under the archive configuration hierarchy with the command arhcive in the global configuration mode

R2(config)#archive
R2(config-archive)#

now let's get to the good stuff. there are several features you can configure to achieve fully automated configuration archive.

First step is to configure the path in which you want the archived configurations to be saved at. personally, i prefer to make a directory to contain only the archived configurations. here's how to do it

R2#mkdir disk0:/archives
Create directory filename [archives]?
Created dir disk0:/archives

After making the directory, you need to point out  from the archive hierarchy to the directory we just created.

R2(config-archive)#path disk0:/archives/backup

Notice that after pointing to the archives directory, i added " /backup ", the reason is that you need to define a base name for the configurations to use is so that the backups name would be like backup-1 , backup-2 etc.. as it will increment till it reaches the highest configurable number which is 14, which can be configured with the maximum command

R2(config-archive)#maximum ?
  <1-14>  maximum number of backup copies
R2(config-archive)#maximum 14

now to make an snapshot of the configuration automatically each time you write your configuration to the memory you'll have enter this command 

R2(config-archive)#write-memory

Basically what it does is that it archives the configuration each time you issue the write command on your router which is good but, keep in mind that if you keep saving every time you enter some command things can get a little bit messy since it will keep archiving and incrementing . There's a way around this but it contradicts a little bit with the whole theory of saving your most recent configurations.

R2(config-archive)#time-period ?
  <1-525600>  Number of minutes to wait between archive creation
R2(config-archive)#time-period 1

time-period  delays the time after an archive creation has been triggered, meaning that if you issued a write  command it doesn't create the archive until the configured time has passed. it's a trade off really, since you can write 20 lines manually or 500 lines pasted from the notepad in that minute and you might need to rollback all of that before the minute is off. no putting this command will just create the archive instantaneously.

let's see how our configuration works so far

 R2#show archive
The maximum archive configurations allowed is 14.
The next archive file will be named disk0:/archives/backup-0
 Archive #  Name
   1      
   2      
   3      
   4      
   5      
   6      
   7      
   8      
   9      
   10
There are currently no configuration saved.

there are no archives saved right now, how about configuring an IP address then saving it. You can actually do this in two ways, either configuring write-memory under the achrive hierarchy or by simply issuing the archive config in the exec mode

 R2#conf tEnter configuration commands, one per line.  End with CNTL/Z.R2(config)#int f0/0R2(config-if)#ip add 10.1.2.1 255.255.255.0R2(config-if)#endR2#writeBuilding configuration...[OK]

R2#show archive
The maximum archive configurations allowed is 14.
There are currently 1 archive configurations saved.
The next archive file will be named disk0:/archives/backup-1
 Archive #  Name
   1        disk0:/archives/backup-0 <- Most Recent
   2      
   3      
   4      
   5      
   6      
   7      
   8      
   9      
   10   

As you can see, the router saved this configuration with the name backup-0 in disk0. lets change the hostname also and make a new archive

R2(config)#hostname cisco-router
cisco-router(config)#end
cisco-router#wr
Building configuration...
*Jun 10 00:52:25.715: %SYS-5-CONFIG_I: Configured from console by console[OK]
cisco-router#show archive
The maximum archive configurations allowed is 14.

There are currently 2 archive configurations saved.

The next archive file will be named disk0:/archives/backup-2

Archive # Name
1 disk0:/archives/backup-0
2 disk0:/archives/backup-1 <- Most Recent
3
4
5
6
7
8
9
10

cisco-router#

excellent eh? now how can you actually see the contents of that configuration, it has been a whilke and you actually can't remember which one you changed the interface IP address in 

you can do that in many way actually, the simplest of them is using the more  command from the exec mode

cisco-router#more disk0:/archives/backup-0

This will show you the whole configuration that is in backup-0 which is very cumbersome to compare with any other config. 

cisco-router#show archive config differences disk0:/archives/backup-0!Contextual Config Diffs:+hostname R2-hostname cisco-router

Notice the (+) and (-) in-front of the hostname lines here, this basically means that the archive your viewing right now contains hostname R2 and  and does not contain hostname cisco-router. it's very neat specially when your comparing your current configuration with an archived one to assess the impact of rolling back.

now we saved the configuration, how do we rollback to this configuration. There are several ways to do this

let's see what our disk contains first

cisco-router#dir disk0:/archivesDirectory of disk0:/archives/
    2  -rw-        1748  Jun 10 2013 00:47:54 +00:00  backup-0 

    3  -rw-        1758  Jun 10 2013 00:52:26 +00:00  backup-1
66875392 bytes total (66863104 bytes free)

As expected, the configurations saved in the disk0 with base name backup. we can load these configs to the routers with several techniques which are fairly different in behavior

• making the archive file the startup-config file! you can do as follow reloading the router, when the router comes up, it will use the configuration was that copied to the startup config, which is not very pretty in downtime prospective. 

 copy disk0:/archives/backup-0 startup-config

• using the configure replace command we talked about earlier, which is better because it replaces the  running configuration with any complete configuration saved on your flash or disk configure 

replace disk0:/archives/backup-0 force

Hopefully i managed to cover the basics of archiving, there's more and as usual old articles are updated with new stuff every now and then. Please feel free to comment regarding any mistakes or new features!

Cisco Configuration Rollback via configure replace

There was always these boring moments when i wanted to reload my lab to a certain point where i configured something, just to try solving a problem in a different approach. at that point i had 3 options,

1. Negate every command that i need to delete 
2. Save the configuration ( copy run start ) right to the point that i normally call ( default configuration ) which is the configuration without the testing parameters that i want to test
3. Save the " default configuration " and issue a write erase, and paste the configuration after the router or switch reload

This was a very time consuming process, specially when you need to test three " BIG " scenarios with complicated parameters, until i found the command from heaven configure replace.

The command works in a very simple manner, it compares the running configuration with the one saved on the flash drive for example, then based on these differences it adds the extra configuration from the configuration saved on the flash to the running configuration and removes the lines that are not present there from the running config. what makes this command very efficient is that you don't need to reload the router/switch to apply a big, like really big configuration.

let's look at this example,

I'm configuring a lab that contains layer 2 and layer 3 configuration ( eventually ! ) and i need to try configuring layer 3 with three different protocols and filters and route-maps etc. 

The easiest way to do this is to configure all the layer 2 parameters then save the configuration to flash 

SW1#copy run flash:layer2-config

Destination filename [layer2-config]?

Verifying checksum...  OK (0x2CC3)

1332 bytes copied in 10.728 secs (124 bytes/sec) 

Check that the file is there

SW1#dir flash:

Directory of flash:/

    1  -rw-        1332                    <no date>  layer2-config

16777212 bytes total (16775816 bytes free)

You can also make sure that this file contains the right configuration 

SW1#more flash:layer2-config

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname SW1

!

~~~output ommited ~~~

Now, you made come configuration and you want to revert back to the point you saved all your layer 2 config without negating or reloading your box.

SW1#configure replace flash:layer2-config

This will apply all necessary additions and deletions

to replace the current running configuration with the

contents of the specified configuration file, which is

assumed to be a complete configuration, not a partial

configuration. Enter Y if you are sure you want to proceed. ? [no]: y

*Mar  1 00:13:34.119: Rollback:Acquired Configuration lock.

*Mar  1 00:13:44.555: %PARSER-6-EXPOSEDLOCKRELEASED: Exclusive configuration lock released from terminal '0' -Process= "Exec", ipl= 0, pid= 196

Total number of passes: 1

Rollback Done

SW1#

*Mar  1 00:13:54.951: %PARSER-3-CONFIGNOTLOCKED: Unlock requested by process '196'. Configuration not locked.

That's how easy it is, you've reverted to your desired configuration with one command