Cisco: Auto Backup Configuration Using “Configuration Archive”

There are certain question you should ask before reading any further:

• Do you have a change management system in place?
• How often do make changes in router/switch configuration?
• What if you router/switch blown up today?
• Will you be able to recover the previous configuration?
• Oh..you forgot to backup?
• Can you figure out exactly what you did and try to put it back the way it was?

One of the quite old Cisco IOS feature can help you solve this very problem or at least make it easier for you to recover from the loss.
Cisco IOS 12.3 introduced the Cisco IOS archive and archive config commands. A very detailed and comprehensive information is available at this Cisco link “Archiving Configurations and Managing them using Archive Management”

• Cisco IOS archive command can help you automatically save configuration after every change.
• This command can also show you the difference between any two configurations saved.
• These archives can also be created manually as per requirement.
• This command can also be used to automatically log all commands entered by any user.
• This command was introduced with IOS 12.3(4)T. Later it was integrated into IOS Release 12.2(25)S.

Archiving : Cisco IOS Command
Router(config)# archive
Router(config-archive)#?
Archive configuration commands:

• default – Set a command to its defaults
• exit – Exit from archive configuration mode
• log – Logging commands
• maximum – maximum number of backup copies
• no – Negate a command or set its defaults
• path – path for backups
• time-period – Period of time in minutes to automatically archive the running- config
• write-memory – Enable automatic backup generation during write memory

In case you want to archive configuration on an ftp server than following configuration will be used. This will backup config on every “write mem” and periodically after every 15 days.

• ip ftp username ftp-username
• ip ftp password ftp-password
• archive
• path ftp://202.163.x.x/routerconfig/$h
• write-memory
• time-period 21600

Router #show archive
The next archive file will be named ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-14
Archive #  Name
0
1       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-1
2       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-2
3       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-3
4       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-4
5       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-5
6       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-6
7       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-7
8       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-8
9       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-9
10       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-10
11       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-11
12       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-12
13       ftp://202.163.x.x/routerconfig/asw01-cc-syb-8flr-13 <- Most Recent

I can also compare the differences between two archived configurations or the running config and an archived config, using the show archive config differences or incremental-diffs, like this:
Router# show archive config ?
differences              Display the differences between two config files
incremental-diffs        Display lines in config file which will be added to running-config
As these archived configurations are just text files in the flash memory (if stored locally, but in our example we have given ftp path to store the backup), you can copy them back to the startup or running config anytime you want. Besides viewing them with the show archive command, you can view them with the dir flash command if stored locally and use the files in following commands otherwise have to give path to ftp:
show archive config differencees [file1 [file2]]
or
show archive config incremental-diffs [file]

The archive command is a powerful tool that I recommend to Cisco admins to be implemented on all routers. You can do both local backups of configurations as well as remote backups.

How to Automate Cisco Backup Using Configuration Archive

The absolute worst time to realize that a backup doesn’t exist is when that backup is actually needed. Although network devices often don’t house critical data like a typical SAN, backups are still a very important part of day to day operations. These backups are useful when a device fails or a configuration needs to be rolled back. This article is about using an often overlooked IOS feature as a method of automating the Cisco backup process. Primarily, this will look into different ways to create device backups using the archive commands.

Although administrators always have the ability to fire up a TFTP server and do a “copy running-config tftp”, this is one of those things that is often overlooked. In the event of an operation outage due to mistake or device failure, not having current backups can prolong the recovery process. Network devices, as key components to a typical business, should have their configuration backed up regularly. Not all organizations have network management solution that is capable of or configured to do this critical function.

As demonstrated in this article, this is a simple way to keep regular backups of IOS configurations. Third party and open source tools often provide the ability to reach into the network device from the outside and copy the configuration to a tftp server or do a backup directly from the output of “show” commands. The feature discussed here as an alternative to other third party solutions, provides administrators with the ability to backup a configuration by invoking manually, on a scheduled basis or when the running-config is saved.

This article assumes access to a TFTP server that is always on and reachable via static IP address. In the article, the files will be backed up to 192.168.2.2. A suitable Windows TFTP server can be found at the URLs below. My recommendation is to use the “service” edition so it can be daemonized in the Microsoft environment. If there is a need for some other flavor of TFTP, one should be readily available for your platform of choice.

Windows TFTP Servers

• TFTPD32 (Download 32 Bit or 64 Bit as appropriate)

The router configuration is pretty straightforward. The basic configuration is as follows.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

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

That is all that is necessary for a very basic archive configuration. The challenge with this configuration is it is still quite a manual process. Nonetheless, it is a basic configuration and can be tested. To do so is a manual process executed by the “archive config” privilege mode command.

R1#archive config

This should produce an output similar to what is shown below. If not, there is some issue copying the file to the tftp path configured.

R1#archive config
!!
R1#

Looking in the TFTP directory, there should also be a new file listed. Most likely this is called something like “-1”.

Realizing that “-1” is a bit obscure, it might make sense to name the files something like “hostname-x” where “x” is some kind of index number. There are two ways to accomplish this. The first method involves hard coding the path to include the hostname. The second method uses the “$h” variable to derive the hostname from the individual router configuration. I prefer to use the variable method so the configuration is portable from device to device.

Hostname in Path

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

Hostname Variable in Path

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

Now when the file is archived, it will be more descriptive.

At this point, it is very easy for an administrator to manually backup the IOS configuration. The problem with that it is still a manual process. Manual processes have a way of not getting the attention they deserve. There is an option that will allow this to be automatically performed any time the running-configuration is saved. Since administrators should be saving their configurations after any change, it helps solve the problem of not having an iteration of the configuration. This feature is enabled with the “write-memory” option.

Archive Write-Memory Option

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

Now saving the configuration should also archive it. This is easily tested by doing a “wr” or “copy running-config startup-config”.

As can be seen in the image above, the output now shows “[OK]!!”. The !! is the acknowledgement from the TFTP process. In addition, there is another new file created.

The final option that can be added to the configuration is a scheduled backup. This is actually external to the archive process, but is a way to accomplish the goal. For some time, Cisco routers have had the ability to use the kron configuration to schedule router functions. This can be used to automate a weekly or monthly execution of the “archive config” command.

Kron Scheduling of Archive

R1(config)#kron policy-list Archive
R1(config-kron-policy)#cli archive config
R1(config-kron-policy)#exit
R1(config)#kron occure
R1(config)#kron occurenc Backup at 3:20 Sun recur
R1(config)#kron occurrence Backup at 3:20 Sun recurring
R1(config-kron-occurrence)#policy-list Archive

Now the router will execute the archive command every Sunday at 3:20AM. This should produce a current copy of the running configuration on the TFTP server.

To view the archived files from the router, the “show archive log” command can be executed.

R1#show archive
The next archive file will be named tftp://192.168.2.2/R1-4
 Archive #  Name
   0
   1       tftp://192.168.2.2/R1-1
   2       tftp://192.168.2.2/R1-2
   3       tftp://192.168.2.2/R1-3

As demonstrated in this article, there is a pretty easy way to keep regular backups of IOS configurations. Third party and open source tools often provide the ability to reach into the network device from the outside and copy something to a tftp server or do a backup directly. As an alternative, Cisco provides administrators with the archive feature that can be invoked manually, on a scheduled basis or when the running-config is saved. This feature, known as Cisco configuration archive, provides administrators who lack access to sophisticated third party network management solutions a viable solution to keep up with their IOS configuration files.

The next article will build on the understanding of the archive feature and demonstrate using “Cisco Configuration Replace and Rollback”.

Delegating computer object management tasks window 2012

Introduction

The subject of delegating permissions in Active Directory for management of computer objects has been covered many times in many forums. I wanted to try to collect all that information as well as add some refinements of my own.

Rights vs. permissions

In the olden days, back when I was just a wee lad and Windows NT was new, the ability to join a computer to a domain was controller by a user right called Add workstations to domain. This user right is only valid on domain controllers. Any use who had this right could join computers to a Windows NT domain. The user right still exists and is in use even on Windows Server 2012 R2 Domain Controllers running Active Directory domains. When users join their computers to the domain using their own credentials they do it using this user right. It is, in fact, the only option available to them, since no regular users are granted any permissions over computer objects in Active Directory by default.
Back in the NT era this right was granted to the Users group and there was no limit to how many computers any give user could add to the domain. When Windows 2000 came along and with it Active Directory the user right was changed to apply to the Authenticated Users security principal and any one user could only add 10 computers to a domain by default. But the preferred way for Active Directory was to use permissions in the directory service to control object creation, modification and deletion…
Active Directory has a very fine grained permissions set allowing you to set permissions for objects as well as their properties. These permissions work the same way as the rest of the authorization model in Windows does by using Access Control Lists (ACL) with security principals and their permissions listed in individual Access Control Entries (ACE). Permissions can be granted anywhere in the hierarchy and inherited down to objects and containers. Granting permissions in Active Directory to someone or something is often called delegation. Computer objects are of course also included in these permissions and we can create much better delegation of control than we could with just a global user right.
We’ll cover three delegation of control scenarios regarding computer object management in this post:

1. Allowing a security principal to join (add) a computer to a domain
2. Allowing a security principal to join and re-join a computer to a domain
3. Allowing a security principal to rename a computer in a domain
4. Allowing a security principal to move computer objects in a domain

You can of course combine any of these.
Creating a computer object and changing its properties is what is required to join a computer to the domain. The container could be the Computers container or any other OU or container, including the domain itself but I do not recommend that.
When a computer joins an Active Directory domain without specifying a path, it is placed in the Computers container. The Computers container is not an OU and so it cannot have Group Policy Objects linked to it or have sub containers or OUs. If you are fine with all computer objects being created in this container you can delegate the permissions below to the Computers container

1. Allowing a security principal to join (add) a computer to a domain

First out is the most common scenario; join a computer to an Active Directory domain. As stated earlier it is not necessary to delegate this to regular users since the very few cases where they join their own computers to a domain should be covered by the Add workstation to domain user right. One exception to this is if you want to tighten down security and remove all security principals from this user right. In that case, if you still want to allow regular users to be able to join computers to a domain you have to delegate permissions to them. The more common case is that whatever deployment solution you use adds the computers to the domain. This is by far the best solution since very few users have any idea what a domain is.
A best practice is to create a service account used only for adding computers to the domain. This account should be clearly labeled, have a strong password and not have any other rights or permissions in you directory except the ability to join the domain. That being said the procedure below works for any security principal you want to delegate permissions to join the domain for.

1. Identify the security principal that you want to delegate permissions for
   This can be any security principal; user, group etc.
2. Identify the container or OU where you want to allow users to manipulate computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select Read All Properties. This is actually redundant since this permissions are already granted to the Authenticated Users principal, but the delegation of control wizard will not let you continue without selecting something on this screen.
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Read All Properties
For the following object types:
    Computer

The selected principals can now join computers to the domain.

2. Allowing a security principal to join and re-join a computer to a domain

The second scenario; allowing a principal to also re-join a computer to a domain requires some additional permissions. This is useful if you want to have a service account that can manage all computer accounts, also existing ones. System Center Configuration Manager for example requires these permissions.

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects, select Create selected objects in this folder and Delete selected objects in this folder, and finally hit Next
   
8. The Permissions window opens
   Select Property-specific and select these individual permissions:
   - Reset Password
   - Read and write Account Restrictions
   - Validated write to DNS host name
   - Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary

You chose to delegate control of objects
in the following Active Directory folder:

    <domain>/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@<domain>)
They have the following permissions:
    Reset password
    Read and write account restrictions
    Validated write to DNS host name
    Validated write to service principal name
For the following object types:
    Computer

The selected principals can now join computers to the domain as well as re-join computers when the computer account already exists.

3. Allowing a security principal to rename a computer in a domain

Here goes no. 3…

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder and select Computer objects and hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties.
   Scroll down an add these individual permissions as well:
   - Validated write to DNS host name
   - Validated write to service principal name 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary


You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Write All Properties
    Validated write to DNS host name
    Validated write to service principal name
For the following object types:
    Computer

The selected principals can now rename a computer in a domain.

4. Allowing a security principal to move computer objects in a domain

The last one is a little more involved as it requires changing permissions on both the source container/OU and the destination. The destination container/OU requires the same permissions as in scenario 1 so set those. Follow these steps to configure the source container/OU:

1. Identify the security principal that you want to delegate permissions for
2. Identify the container or OU where you want to allow users to create and configure computer objects
3. Right click the container or OU you selected and select Delegate Control…
   
4. The Delegation of Control Wizard opens, hit Next
   
5. The Users or Groups window opens:
   Select the security principal you want to grant permissions to, then hit Next again.
   
6. The Tasks to Delegate window opens:
   Select Create a custom task to delegate and hit Next
   
7. The Active Directory Object Type window opens:
   Select Only the following objects in the folder, select Computer objects and , select Delete selected objects in this folders, hit Next 
   
8. The Permissions window opens
   Select Property-specific and select Write All Properties. 
   
9. Finally the Completing the Delegation of Control Wizard window opens showing you a summary of your actions. Hit Finish.
   

Delegation of Control Wizard Summary


You chose to delegate control of objects
in the following Active Directory folder:
    saferoad.com/Computers
The groups, users, or computers to which you
have given control are:
    Domain Join Account (SvcJoinComputerToDom@saferoad.com)
They have the following permissions:
    Write All Properties
For the following object types:
    Computer


More information

There is an interesting distinction between joining a domain by exercising the user right Add workstation to the domain and using delegated permissions. If you join by the user right the owner of the resulting computer object is the Domain Administrators group, but if you join by delegated permissions the owner is the user who actually performed the join. Also if a principal has both the user right and delegated permissions, delegated permissions take precedent and are used to join the computer to the domain. A recommended best practice her would be to remove all principals from the user right and just rely on permissions. You do that by applying a policy to your domain controllers where no principal has the user right:

The location of the user right is:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment
You could also increase the default quota of 10 computer accounts added to the domain per user, but I do not recommend that. I essence you are copying the settings from Windows NT to your Active Directory domain and do not take advanced of the advanced delegation model in Active Directory. For completion here is how to change the quota:
From any editor capable of displaying and changing individual attributes of Active Directory objects; display the properties of the domain NC. Locate the ms-DS-MachineAccountQuota property and change it to your desired value:

How to configure Static routing in Linux

July 7, 2015 by cloudibee

Static routes will be added usually through “route add” or “ip route” command. However, “route add” command configures routing on the runtime and doesn’t persist the configuration after a reboot. To make it persistent across reboots, you have to add it to /etc/sysconfig/network-scripts/route-<interface-file> . For example, static routes for the eth0 interface would be stored in the /etc/sysconfig/network-scripts/route-eth0 file. Here are the Steps to configure static routing in Linux.

To add static route using “route add” in command line:

# route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.10.1 dev eth0

1	# route add -net 192.168.100.0 netmask 255.255.255.0 gw 192.168.10.1 dev eth0

To add static route using “ip route” command:

# ip route add 192.168.100.0/24 via 192.168.10.1 dev eth1

1	# ip route add 192.168.100.0/24 via 192.168.10.1 dev eth1

Adding Persistent static route:

You need to edit /etc/sysconfig/network-scripts/route-eth0 file to define static routes for eth0 interface. This configuration will be persistent even after the server is rebooted.

GATEWAY0=192.168.10.1 NETMASK0=255.255.255.0 ADDRESS0=192.168.100.0

1 2 3

GATEWAY0=192.168.10.1 NETMASK0=255.255.255.0 ADDRESS0=192.168.100.0

GATEWAY1=10.64.34.1 NETMASK1= 255.255.255.240 ADDRESS1=10.64.34.10

1 2 3

GATEWAY1=10.64.34.1 NETMASK1= 255.255.255.240 ADDRESS1=10.64.34.10

Save and close the file. Restart networking:

# service network restart

1	# service network restart

There are various ways to verify the routing table in Linux. Few commands are listed below:

# route –n

1	# route –n

# netstat –nr

1	# netstat –nr

# ip route show

1	# ip route show

  http://www.cloudibee.com/static-route-linux/