ICND1 100-105

ICND1 100-105

Managing Cisco Devices

We will learn how to use commands like copy to change the location of those components and also use troubleshooting commands like show and debug to monitor and verify the process.

Cisco IOS File System and Devices

In managing your Cisco device, you will be transporting and copying files from location to location. You may do it extensively if you are using the network heavily for centralizing your configuration files and IOS images. The good thing about IOS is that it uses the Cisco IFS feature or IOS filesystem to provide a single consistent interface to all the filesystems that the Cisco router uses. This includes the use of the same type of URLs to reference and copy to and from the various locations.

So when copying files from RAM, for example, the running configuration into NVRAM or flash or even backing them up in a TFTP server, you will be able to reference them using URL prefixes that are common and consistent. So NVRAM is called nvram: RAM can be referenced using the system keyword. Flash is flash: and TFTP is tftp: The directory location and file names are also conventions and standards on their IFS.

Managing Cisco IOS Images

One of those maintenance operations that will use a filesystem is the backing up, restore and upgrades of IOS images. This is important in case the brain of the router (the IOS software image) becomes corrupted or accidentally erased. A TFTP or FTP server in the network can be used as a backup repository and also as a central server to store your software upgrades, download them into the router and perform the upgrade.

Before you back up your software images, make sure that there is access to the network TFTP server and there is connectivity to it and then verify that the server has sufficient disk space. You can use show flash to determine the size of your current IOS image. You can also verify the file name requirements on the TFTP server, that may be different depending on the operating system running on that server. Also, some of the TFTP servers require the creation of the destination file in advance to receive the upload.

Verifying Memory and Deciphering Image Filenames

When restoring the image file or when upgrading your operating system, you are going to be using copy commands typically from the network into flash. Be sure to verify that there is enough room in flash if you use show flash. The last line will tell you the available bytes. Also, remember that when issuing the copy command, you will be prompted to erase flash before you copy the files. This is extremely dangerous if you are storing other files in flash like SDM and IPS signature files. It is very important that you maintain the naming conventions of the IOS image files. The components in the file name will tell you a lot about the feature set, the compression status, and versions and release numbers of the image file.

Creating a Software Image Backup

This is an example of the command to back up your software image. A copy flash: tftp: command will do the trick.

Router#copy flash: tftp:
Source filename []? c2800nm-ipbase-mz.124-5a.bin
Address or name of remote host []? 192.168.0.100
Destination filename [c2800nm-ipbase-mz.124-5a.bin]?
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!
12094416 bytes copied in 98.858 secs (122341 bytes/sec)
Router#

A router will go on asking you for the name of the file you want to back up and the address of the TFTP server. You will then have the option to change the file name on the destination location. If you simply hit Enter, you will maintain the file name. Look at the output. The exclamation marks represent success in copying the file. Each exclamation mark represents a UDP segment that has been successfully copied. The last line tells you the number of bytes copied and how long it took to copy.

Upgrading the Image from the Network

Restoring your backup or upgrading the image of the operating system to a new version follows the same process. It will simply transfer those files from the TFTP server into flash. Both would require a reload of the router for the new file and the new image to be active and be used. The copy command is fairly straightforward. It will prompt you for the IP address of the TFTP server as well as the source name and destination file names for the image being transferred. If there is not enough room in flash, it will prompt you to erase flash before copying and you will have to do so in the case that the new file does not fit flash. Similar output in terms of the exclamation marks and the final verification in terms of number of bytes.

Device Configuration Files

Configuration files can also be obtained from the network using protocols like not only TFTP but also FTP and remote copy. You could copy the transferred configuration files straight into RAM and make them your active configuration or you can copy them into startup config, reload the router, and then make them your active configuration. The situation could be a restore of a previous backup or simply to streamline the process of configuration of multiple routers by holding all of the configs in a central location and simply transferring them into all routers. The backup operation can also be accomplished with these protocols and you can back up both your startup or your running configurations.

Cisco IOS copy Command

It is very important to understand that any copy into the running configuration does not really replace the running configuration. It merges the files you are trying to copy with that running configuration. So any nonoverlapping commands will be maintained from both configuration files. Any overlapping commands will be stepped on by the new configuration being copied. This is a merge and the combined configurations may not be what you are expecting or what you are hoping for. This is in contrast to all copy operations into startup configuration; all those are real copies and will overwrite whatever is there in the startup configuration. One of the impacts of this is that the only way to reset the configuration to factory default other than doing it manually command by command is to erase the startup configuration and reload the router.

copy run tftp and copy tftp run Commands

TFTP servers can then be used as a central repository of all of your configurations. You should consider though the security implications of using TFTP. It does not authenticate users and it does not encrypt any information. The figure illustrates the commands to first back up your running config into TFTP and then to restore the configurations from TFTP into the running config. Notice in this second operation how the destination file name has to be that, running-config.

Router#copy running-config tftp:
Address or name of remote host []? 192.168.0.100
Destination filename [router-confg]?
!!
712 bytes copied in 1.340 secs (531 bytes/sec)
Router#

 

Router#copy tftp: running-config
Address or name of remote host []? 192.168.0.100
Source filename []? london.cfg
Destination filename [running-config]?
Accessing tftp://192.168.0.100/london.cfg...
Loading london.cfg from 192.168.0.100 (via FastEthernet0/0): !
[OK - 712 bytes]
712 bytes copied in 9.520 secs (75 bytes/sec)
Router#
*Mar  1 01:55:16.259: %SYS-5-CONFIG_I: Configured from tftp://192.168.0.100/london.cfg by console
Router#

show and debug Commands

Other than image and configuration file maintenance, the overall and general maintenance of the router is ruled by these two commands initially - show commands display static information and they represent a snapshot of the particular component you are trying to display at that particular point in time when you use a show command. The debug commands, on the other hand, will display dynamic information. Examples: live traffic going through the router if you use, for example, a debug ip icmp or live routing protocol advertisements if you use debug ip ospf packets.

The processing load of a debug command is a lot higher than the show command; in fact, show commands will take the snapshot and go. Debug continuously reads live information and if you decide to throw it into the console output, then you could clutter the output and create so much overhead that you could render the router unusable. Other than that, the objectives are pretty clear; the show command has you objective of gathering facts and create that snapshot of that component you want to display. Debugs are used to observe a process or observe live traffic or protocol behaviors going on in real time.

So again, be careful using debugs. Be aware that these commands may generate too much data that is of little use actually for a specific problem and this is due to the fact that some of that data is cryptic and requires knowledge of the protocol or protocols being debugged. Also, try to use debug as a last resort type tool when your problem has been narrowed to a likely subset of causes. With that in mind, you could filter the output of a debug using access control lists. For example, only display the routing protocol updates coming from a certain router or only display the updates related to a certain prefix or destination.

Other guidelines for debug commands: always monitor the utilization of your CPU to make sure that the debug will not crash the router; it could happen. When in doubt, shut down all debugs and you can quickly do that with a no debug all command. You could also use undebug all or "un all". Be aware of the fact that if you enable debugs on your console, you will not see them on your virtual terminal connections unless you issue the command terminal monitor.

Router#
Router#term mon
% Console already monitors
Router#
Router#deb ip icmp
ICMP packet debugging is on
Router#
Router#ping 192.168.0.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
Router#
*Mar  1 02:04:47.863: ICMP: echo reply rcvd, src 192.168.0.100, dst 192.168.0.200
*Mar  1 02:04:47.879: ICMP: echo reply rcvd, src 192.168.0.100, dst 192.168.0.200
*Mar  1 02:04:47.891: ICMP: echo reply rcvd, src 192.168.0.100, dst 192.168.0.200
*Mar  1 02:04:47.899: ICMP: echo reply rcvd, src 192.168.0.100, dst 192.168.0.200
*Mar  1 02:04:47.907: ICMP: echo reply rcvd, src 192.168.0.100, dst 192.168.0.200
Router#
Router#show proc
Router#show processes cpu history
Router   02:05:09 AM Friday Mar 1 2002 UTC
             11111222221111111111     11111
100
 90
 80
 70
 60
 50
 40
 30
 20
 10
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)
               2
    111111119317121111111111111111211111111111111111111111111111
100
 90
 80
 70
 60
 50
 40
 30            *
 20            *
 10         *  *
   0....5....1....1....2....2....3....3....4....4....5....5....6
             0    5    0    5    0    5    0    5    0    5    0
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%
    26
    73
100
 90
 80
 70
 60  *
 50  *
 40  *
 30 **
 20 **
 10 **
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7..
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%
Router#
Router#un all
All possible debugging has been turned off
Router#