Cisco Cookbook | O'Reilly Media

Content preview·Buy reprint rights for this chapter

You can think of a Cisco router as a special-purpose computer. It has its own operating system, which is called the Internetwork Operating System (IOS), as well as files and filesystems. So we'll start with a discussion of the basic system administration functions that a router engineer must perform. This includes managing your router's filesystems, upgrading the operating system, doing backups, and restoring the system configuration.

Cisco routers use flash memory, rather than disks, for storing information. Flash storage media is significantly more expensive and slower than disk storage, but the amount of storage needed to run a router is relatively small compared to the amount needed to run a general-purpose computer. Flash also has the important benefit that it tends to be more reliable than disk storage.

Flash storage is similar to Random Access Memory (RAM), but it doesn't need power to retain information, so it is called non-volatile. And, unlike Read Only Memory (ROM), you can erase and rewrite flash easily. There are other types of non-volatile solid state storage, such as Erasable Programmable Read Only Memory (EPROM) and Electronically Erasable Programmable Read Only Memory (EEPROM). EPROM is not suitable for routers because it generally requires an external device such as an ultraviolet light shone through a window on the chip to erase it. EEPROM, on the other hand, can be erased by simply sending an erase signal to the chip. But there is a key difference between EEPROM and flash memory: when you erase something from an EEPROM device, you must erase the entire device, while flash devices allow selective deletion of parts of the medium.

This is an important feature for routers, because you don't always want to erase the entire storage medium in order to erase a single file. In Recipe 1.11 and Recipe 1.12, we discuss ways to erase single files on some types of routers, depending on the type of filesystem used.

There are at least two main pieces of non-volatile storage in a Cisco router. The router's configuration information is stored in a device called the Non-Volatile RAM (NVRAM), and the IOS images are stored in a device called the flash (lowercase). It's important to keep these names straight because, of course, all Flash memory is non-volatile RAM. And, in fact, most routers use Flash technology for their NVRAM. So it's easy to get confused by the terms.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You can think of a Cisco router as a special-purpose computer. It has its own operating system, which is called the Internetwork Operating System (IOS), as well as files and filesystems. So we'll start with a discussion of the basic system administration functions that a router engineer must perform. This includes managing your router's filesystems, upgrading the operating system, doing backups, and restoring the system configuration.

Cisco routers use flash memory, rather than disks, for storing information. Flash storage media is significantly more expensive and slower than disk storage, but the amount of storage needed to run a router is relatively small compared to the amount needed to run a general-purpose computer. Flash also has the important benefit that it tends to be more reliable than disk storage.

Flash storage is similar to Random Access Memory (RAM), but it doesn't need power to retain information, so it is called non-volatile. And, unlike Read Only Memory (ROM), you can erase and rewrite flash easily. There are other types of non-volatile solid state storage, such as Erasable Programmable Read Only Memory (EPROM) and Electronically Erasable Programmable Read Only Memory (EEPROM). EPROM is not suitable for routers because it generally requires an external device such as an ultraviolet light shone through a window on the chip to erase it. EEPROM, on the other hand, can be erased by simply sending an erase signal to the chip. But there is a key difference between EEPROM and flash memory: when you erase something from an EEPROM device, you must erase the entire device, while flash devices allow selective deletion of parts of the medium.

This is an important feature for routers, because you don't always want to erase the entire storage medium in order to erase a single file. In Recipe 1.11 and Recipe 1.12, we discuss ways to erase single files on some types of routers, depending on the type of filesystem used.

There are at least two main pieces of non-volatile storage in a Cisco router. The router's configuration information is stored in a device called the Non-Volatile RAM (NVRAM), and the IOS images are stored in a device called the flash (lowercase). It's important to keep these names straight because, of course, all Flash memory is non-volatile RAM. And, in fact, most routers use Flash technology for their NVRAM. So it's easy to get confused by the terms.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to load configuration commands via the Trivial File Transfer Protocol (TFTP).

You can use the copy tftp: command to configure the router via the TFTP:

Router1#tftp://172.25.1.1/NEWCONFIG
Destination filename [running-config]? <enter>
Accessing tftp://172.25.1.1/NEWCONFIG...
Loading NEWCONFIG from 172.25.1.1 (via FastEthernet0/0.1): !
[OK - 24 bytes]
   
24 bytes copied in 0.192 secs (125 bytes/sec)
Router1#

IOS versions before 12.0 used the command configure network . This command is still available in more recent versions, but it is now deprecated and may not continue to be available in the future.

Generally, most people configure their routers using Telnet and the configure terminal command. For large configuration changes, people tend to resort to cutting and pasting a large set of commands. While this method works, it is inefficient and slow, particularly if you have to configure large numbers of routers. When you use TFTP to download a large set of configuration commands, the router doesn't need to echo each character to your screen, which reduces the overhead and increases the speed.

In our example, we configured the router by making it download the file called NEWCONFIG from the server at 172.25.1.1 using TFTP. The router copies the entire file via TFTP before entering the commands into the running configuration. This is extremely useful because using some commands in the middle of a configuration could disrupt your access to the router—but the rest of the commands might fix the problem. If you tried to enter them manually using Telnet and configure terminal , you would simply lock yourself out of the router. A typical example of this problem happens when you replace an active access list. When you enter the first line, the router puts an implicit deny all

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to store a backup copy of your router's configuration on a TFTP server.

This example shows how to use TFTP to upload a copy of the router's active configuration to a remote server:

Freebsd% /tftpboot/router1-confg
Freebsd% /tftpboot/router1-confg
Freebsd% Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.
   
User Access Verification
   
Password: <vtypassword>
 
Router1>en
Password: <enablepassword>
Router1#tftp://172.25.1.1/router1-confg
Address or name of remote host [172.25.1.1]? <enter>
Destination filename [router1-confg]? <enter>
!!!
9640 bytes copied in 3.956 secs (2437 bytes/sec)
Router1#

We cannot overstress the importance of making regular backups of your router configuration files, and keeping copies of these files in a safe place. If a serious failure damages a router's hardware or software, your configuration will be destroyed. Anybody who has had to reconstruct a complex router configuration file from memory can tell you how difficult and stressful this task is! But, if you have a backup of the last working configuration file, you can usually get a router working again within minutes of fixing any hardware problems.

Typical Mean Time Between Failure (MTBF) estimates for Cisco routers tend to be about 16 years. This sounds like a long time, but in a large network it means that you can expect to see a few failures every year. Unfortunately, human errors resulting in complete or partial loss of the configuration file are far more common than device failures.

In the example, we created an empty backup configuration file on the TFTP server, then instructed the router to send its running configuration to this server. It is important to adjust the file permissions with the Unix chmod command. The transfer will fail if the configuration file is not world writable. We highly recommend moving the configuration files out of the TFTP directory to ensure that the file isn't read by unauthorized users, or accidentally overwritten.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to boot the router using an alternate configuration.

The following set of commands allows you to automatically load a configuration file located on a remote TFTP server when the router boots:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#service config
Router1(config)#Network-auto 172.25.1.1
Router1(config)#Router8-auto 172.25.1.1
Router1(config)#end
Router1#

By default, when the router reloads, it will read the configuration information from a file in its NVRAM. Cisco commonly refers to this file as the startup configuration file. However, you can configure the router to load all or part of its configuration from a remote server via TFTP. This feature does not prevent the router from loading its startup configuration from NVRAM. In fact, the router will load its local startup file before proceeding to the TFTP server files.

Uses for this feature vary, although most people who implement it do so because their configuration file has grown too large for their NVRAM to handle. It can also be a useful way of keeping an access list that is shared by a number of routers centralized and up-to-date. We have sometimes used it as a temporary measure when the NVRAM in a router is damaged.

However, we consider this feature to be highly risky and recommend avoiding it in most cases. If the problem is simply one of NVRAM capacity, Recipe 1.4 shows how to compress the startup configuration file to help fit more information into your existing NVRAM. Also, since routers can operate for years without reloading, using this feature to keep your routers up-to-date seems pointless.

If you choose to implement remote configuration despite these cautions, you need to understand how the boot process works. When you enable the service config option, the router attempts to load a network file, then a host file. The router assumes that network files are common to all routers, while the host file contains router-specific information. If it can't find these files, the router will generate the following error messages:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Your configuration file has become larger than the router's available NVRAM.

You can compress your router's configuration file before saving it to NVRAM to allow you to save more configuration information. The command service compress-config will compress the configuration information when the router saves the file, and uncompress it when it is required:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#service compress-config 
Router1(config)#end                     
Router1#

Cisco generally ships its routers with more than enough NVRAM to store an average configuration file. However, there are times when configuration files exceed the available NVRAM. For instance, some routers contain large access lists that are hundreds of lines in length. When configuration files grow beyond the finite amount of NVRAM you will begin to have problems.

The first sign of serious problems with an overly large configuration file is usually when the router refuses to save its configuration because of size. This is a dangerous situation because the router can no longer keep a copy of the whole running-configuration file in its NVRAM storage, and it is difficult to predict how much of your configuration will be lost if you were to reload the router.

Turning on compression roughly doubles the size of the configuration file you can store. You must put the command service compress-config into the configuration with a configure terminal. Then, for this command to take effect, you need to copy the running configuration file to NVRAM:

Router1#copy running-config startup-config
Destination filename [startup-config]? <enter>
Building configuration...
Compressed configuration from 9664 bytes to 4903 bytes[OK]
Router1#

In this case, you can see that the compression reduced the configuration file to less than half of its original size. This compression algorithm will not attempt to compress a file that is three times larger than the available NVRAM space. Although this limit exists, we have never seen a router approach a 3 to 1 ratio in practice.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to clear an old configuration out of your router and return it to a factory default configuration.

You can delete the current startup configuration files and return the router to its factory default settings with the erase nvram: command:

Router1#erase nvram:
Erasing the nvram filesystem will remove all files! Continue? [confirm] <enter>
[OK]
Erase of nvram: complete
Router1#reload
                  
System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm] <enter>

You can achieve the same result with the erase startup-config command:

Router1#erase startup-config 
Erasing the nvram filesystem will remove all files! Continue? [confirm] <enter>
[OK]
Erase of nvram: complete
Router1#reload
Proceed with reload? [confirm] <enter>

Before you redeploy an old router that you have previously used for another purpose, it is a good idea to completely erase the old configuration. This ensures that the router starts with a clean configuration. However, if you did this on a production router, it would wipe out the configuration and disable all of the interfaces. Fortunately, completely deleting your configuration requires two steps: you must erase the startup configuration, then reload the router.

After you erase your startup configuration file and reload, the router will enter its configuration dialog mode. Most experienced Cisco engineers prefer to skip this mode:

--- System Configuration Dialog ---
   
Would you like to enter the initial configuration dialog? [yes/no]: no
   
Would you like to terminate autoinstall? [yes]: yes
   
Press RETURN to get started!
Router>

At this point, the router's configuration has been returned to the factory defaults:

Router#show running-config
Building configuration...
   
Current configuration : 431 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router
!
!
ip subnet-zero
!
!
!
!
interface Ethernet0
 no ip address
 shutdown
!
interface Ethernet1
 no ip address
 shutdown
!
interface Serial0
 no ip address
 shutdown
!
interface Serial1
 no ip address
 shutdown
!
ip classless
ip http server
ip pim bidir-enable
!
!
line con 0
line aux 0
line vty 0 4
!
end
   
Router#

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to upgrade the IOS image that your router uses.

The copy tftp command allows you to use TFTP to download a new IOS version into the router's Flash memory:

Router1#tftp://172.25.1.1/c2600-ik9o3s-mz.122-12a.bin
Destination filename [c2600-ik9o3s-mz.122-12a.bin]? <enter>
Accessing tftp://172.25.1.1/c2600-ik9o3s-mz.122-12a.bin...
Erase flash: before copying? [confirm] <enter>
Erasing the flash filesystem will remove all files! Continue? [confirm] <enter>
Erasing
device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...
erased
Erase of flash: complete
Loading c2600-ik9o3s-mz.122-12a.bin from 172.25.1.1 (via FastEthernet0/0.1): 
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 11135588 bytes]
   
Verifying checksum...  OK (0xE643)
11135588 bytes copied in 82.236 secs (135410 bytes/sec)
Router1# reload
Proceed with reload? [confirm] <enter>

Sooner or later you will need to upgrade your router's IOS image. Common reasons for upgrading the IOS include new features, bug fixes, and security vulnerabilities. Before you attempt to upgrade your IOS, you should save a backup copy of your current IOS to your TFTP server, as discussed in Recipe 1.9.

You should always start by analyzing how much free space is available in your router's flash to ensure that there is enough room to load the new IOS image. If there isn't enough, then you may have to erase existing image(s) from flash—as we did in our example. In some cases, you may not have enough flash to load the new image at all. You can use the show flash command to see how much flash memory is available:

Router1#show flash

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to boot using an alternate IOS image.

To specify which IOS image the router should load next time it reboots, use the boot system command:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#flash:c3620-jk9o3s-mz.122-7a.bin
Router1(config)#flash:c3620-jos56i-l.120-11.bin
Router1(config)#slot0:c3620-ik9s-mz.122-13.bin
Router1(config)#boot system rom
Router1(config)#end

The sequence of the boot system commands is extremely important, as the router will attempt to load the IOS images in the order that they appear in the configuration file.

The router can store as many IOS images in its flash memory as there is space to hold. If there is only one file, it can safely assume that this must be the IOS image to load. However, if the router has several images in its flash storage, you need to specify which one it should load, or the router will simply select one. This is particularly true on routers that have additional flash memory in the form of PCMCIA cards, which can hold many files—not all of them are necessarily IOS images.

With the default configuration register settings, the router will attempt to load the first accessible IOS image it finds in its flash storage. However, loading the first available image might not be appropriate. For instance, in our last recipe we showed that if you have space, you can download a new IOS image without erasing old images. In this case, you probably want the router to load the newer IOS image. It would be better still if the router tried the new image first, then reverted to the old image if the new one failed to load correctly for any reason. The boot system command allows you to specify not only which IOS images to boot from, but also the order in which to try them if the router has trouble booting.

In the example, this router tries a succession of three different IOS images. If they all fail, it resorts to using its boot ROM image.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to load an IOS image that is too large to store on your router's local flash.

You can load an IOS image that is larger than your router's flash by configuring the router to use TFTP to download the image before booting:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#c2500-io-l.122-7a.bin 172.25.1.1
Router1(config)#boot system flash
Router1(config)#end
Router1#

We mentioned in Recipe 1.7 that it is possible to load IOS images over the network at boot time. However, booting from remote IOS images presents some unique challenges. This is why we have dedicated an entire recipe to remote booting.

One of the most important advantages of booting an IOS image over the network is that it allows you to use images that are larger than your router's flash. Like any other software, each new IOS image tends to be slightly larger than the previous versions. It is relatively common to discover that you can't load the latest IOS version because it is too big to fit in an older router's flash.

Booting over the network also provides a way of loading a backup IOS image if the primary image fails. As we discussed Recipe 1.7, it's a good idea to configure your router with at least one backup IOS image to load in case the primary fails for any reason. Even if you have a lot of flash storage, you may find that you can't store two IOS images at once. So booting over the network is actually a reasonable way of providing a backup image.

Booting over the network also poses an important security problem because, as we discussed in Recipe 1.2, it's virtually impossible to secure a UDP-based service like TFTP. In addition, it makes the router dependent on the TFTP server for its boot images. Network booting also has performance issues. Loading an IOS over the network can significantly increase the time it takes your router to reload, particularly if it has to traverse slower WAN links. We certainly do not recommend relying solely on remote booting in a production environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to save a backup copy of your IOS image on a TFTP server.

You can upload a copy of your router's IOS image to a TFTP server with the following set of commands:

Freebsd% /tftpboot/c2600-ik9o3s-mz.122-12a.bin
Freebsd% /tftpboot/c2600-ik9o3s-mz.122-12a.bin
Freebsd% Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.
   
User Access Verification
   
Password: <vtypassword>
 
Router1>en
Password: <enablepassword>
Router1#flash:c2600-ik9o3s-mz.122-12a.bin  
               tftp
Address or name of remote host [  ]? 172.25.1.1
Destination filename [c2600-ik9o3s-mz.122-12a.bin]? <enter>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
11135588 bytes copied in 52.588 secs (211752 bytes/sec)
Router1#

It's a good idea to save a copy of the current IOS image before attempting to upgrade the IOS version of a router. This way, if an upgrade fails or if you have problems with the new IOS version, you can revert back to the old proven IOS version. The procedure to copy an IOS image to a TFTP server is very similar to the way we backed up a configuration file in Recipe 1.2. The only real difference is the size of the file involved—IOS images are quite a bit larger than configuration files.

As we mentioned in Recipe 1.2, you have to verify the file permissions on your TFTP server. The transfer will fail if this file isn't world writable. We highly recommend that you remove the world writable attribute on this file after uploading it. On Unix systems, you can use the chmodcommand to change the file attributes. This will ensure that the file isn't accidentally overwritten. Unlike configuration files (which you should never store in your TFTP directory),

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to load an IOS image into your router through a serial connection to the console or AUX ports.

You can use the following set of commands to copy an IOS image onto a router through the console or the AUX port:

Router1#copy xmodem: slot1:      
                        **** WARNING ****
x/ymodem is a slow transfer protocol limited to the current speed
settings of the auxiliary/console ports. The use of the auxilary
port for this download is strongly recommended.
During the course of the download no exec input/output will be
available.
                        ---- ******* ----
   
Proceed? [confirm] <enter>
Destination filename [  ]? c3620-ik9s-mz.122-12a.bin
Erase slot1: before copying? [confirm] <enter>
Use crc block checksumming? [confirm] <enter>
Max Retry Count [10]: <enter>
Perform image validation checks? [confirm] <enter>
Xmodem download using crc checksumming with image validation
Continue? [confirm]  <enter>
Ready to receive file...........CC  <start xmodem file transfer here>
4294967295 bytes copied in 1450.848 secs (1271445669961 bytes/sec)
Router1#

Cisco highly recommends using the AUX port for this procedure rather than the console port because the AUX port supports hardware flow control.

It can be quite useful to be able to load an IOS image through a serial connection, particularly if you don't have access to a TFTP server, or if the router doesn't have any accessible LAN interfaces. Although this feature is rarely used, Cisco supports xmodem and ymodem file transfers through a serial connection.

We also recommend enabling the CRC checksum feature when you use xmodem to download an IOS image through a serial connection. This will help to ensure the integrity of the file transfer.

We should stress that this process can be extremely slow. Don't even attempt to download an IOS image at the default speed of 9600bps unless you have an entire day to kill. We highly recommend increasing the speed to the highest value that your terminal emulation package will support. We have found that 115200bps provides the maximum throughput with the greatest reliability. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to erase files from your router's flash.

To delete all of the files from your router's flash memory, use the erase command:

Router1#erase slot1:
Erasing the slot1 filesystem will remove all files! Continue? [confirm] <enter>
Erasing device...
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased
Erase of slot1: complete
Router1#

Not all router types support the erase command.

You can remove individual files from the router's flash memory with the delete command:

Router1#delete slot1:c3620-ik9s-mz.122-13.bin
Delete filename [c3620-ik9s-mz.122-13.bin]? <enter> 
Delete slot1:c3620-ik9s-mz.122-13.bin? [confirm] <enter>
Router1#

As we have indicated, there are two ways to delete files from flash, depending on the type of router. The difference arose because Cisco routers use three different kinds of filesystems, called Class A, Class B, and Class C. Table 1-2 shows the filesystems that Cisco's most common routers use.

Table 1-2: Supported filesystems of common Cisco routers
Router type	Filesystem type
7000(RSP)	Class A
7500(RSP2,4, & 8)	Class A
12000	Class A
Route Switch Module (RSM)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to change how your router's flash memory is partitioned.

The partition command allows you to create a partition in the router's flash memory:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#2 8 8 
Router1(config)#end
Router1#

As we discussed in Recipe 1.11, the erase command deletes the entire contents of a flash device. On routers that don't support the delete and squeeze commands, there is no way to delete an individual file from flash without erasing all of the files in the flash device. Fortunately, you can use the partition command on flash devices to shelter some files from the effects of the erase command.

After you have partitioned a flash device, the erase command only affects one partition at a time. This command doesn't affect any of the other partitions on the same flash device. You can use this to allow you to delete individual files without having to wipe out the entire flash device.

In the next example, we partitioned a flash device into two equal parts. We then stored an IOS image on each of the partitions. You can see the partitions and their contents with the following command:

Router1#show slot1:
   
PCMCIA Slot1 flash directory, partition 1:
File  Length   Name/status
  1   7723664  c3620-ajs56i-mz.120-25.bin  
[7723728 bytes used, 664880 available, 8388608 total]
8192K bytes of processor board PCMCIA Slot1 flash (Read/Write)
   
PCMCIA Slot1 flash directory, partition 2:
File  Length   Name/status
  1   7723664  c3620-ajs56i-mz.120-25.bin  
[7723728 bytes used, 402736 available, 8126464 total]
8192K bytes of processor board PCMCIA Slot1 flash (Read/Write)
   
Router1#

Note that the router treats the two partitions as if they were separate flash devices. You can erase the contents of a particular partition by specifying the flash device name followed by the partition number and a colon:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to configure your router to act as a TFTP server.

The tftp-server command configures the router to act as a TFTP server:

Router1#configure terminal                          
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#flash:c2600-ik9o3s-mz.122-12a.bin
Router1(config)#end
Router1#

The ability to use a router as a TFTP server can be quite useful. We have often used this feature to upgrade several routers that are separated from the TFTP server by slow WAN connections. In situations like this, you can upgrade one of the remote routers using TFTP over the slow WAN connection as we described in Recipe 1.6. Then you can configure this router to act as a TFTP server, and use it to upgrade the remaining routers over high-speed local links.

However, the router is not a fully functional TFTP server. It can only serve files for download. You cannot use this feature to upload files into the serving router's local flash. The router is not limited to just serving IOS images: you can use your router's flash to store configuration files and make them available for download via TFTP as well. You can even use it to hold configuration files for non-Cisco equipment.

Security is a concern whenever you enable services on a router. Every extra service you enable provides the wily hacker with a new potential avenue to exploit against your network. Therefore, we don't recommend using the TFTP server feature on routers facing the public Internet or other potentially unfriendly networks. However, for internal use, we believe it is reasonably safe. You can increase the security of the router's TFTP server by using an access list like this:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#99
Router1(config)#99
Router1(config)#flash:c2600-ik9o3s-mz.122-12a.bin 99
Router1(config)#end

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to use FTP directly from your router to download configuration or IOS files.

The copy ftp: command lets the router exchange files using FTP:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ijbrown
Router1(config)#ianpassword
Router1(config)#end
Router1#copy ftp: running-config
Address or name of remote host [172.25.1.1]? 172.25.1.1
Source filename [  ]? test
Destination filename [running-config]? <enter>
Accessing ftp://172.25.1.1/test...
Loading /test 
[OK - 24/4096 bytes]
   
24 bytes copied in 0.276 secs (87 bytes/sec)
Router1#

We explicitly defined a username and password in this example. If you don't specify a username, the router will try to connect to the server's anonymous FTP service.

Several recipes in this chapter show how to transfer files between your router and server using TFTP. However, Cisco routers also support FTP, which is better suited for transferring files over busy and congested links. While TFTP file transfers tend to abort if they encounter persistent congestion, FTP appears to be more resilient.

FTP is also somewhat more secure than TFTP because it uses usernames and passwords. TFTP has no user level security features. However, FTP sends its passwords across the network in unencrypted cleartext, so it is still not highly secure.

In the example we explicitly configured a FTP username and password on the router. Once this information is defined, using FTP is as easy as using TFTP. You can also override the username and password settings defined in the configuration file by including them on the command line:

Router1#ftp://ijbrown:ianpassword@172.25.1.1/c3620-ik9s-mz.122-10a.bin
Destination filename [c3620-ik9s-mz.122-10a.bin]? <enter>
Accessing ftp://ijbrown:ianpassword@172.25.1.1/c3620-ik9s-mz.122-10a.bin...
Loading pub/c3620-ik9s-mz.122-10a.bin !!!!
Erase slot1: before copying? [confirm]

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You need to generate hundreds of router configuration files for a big network rollout.

When building a large WAN, you will usually configure the remote branch routers similarly according to a template. This is a good basic design principle, but it also makes it relatively easy to create the router configuration files. Example 1-1 uses a Perl script to merge a CSV file containing basic router information with a standard template file. It takes the CSV file as input on STDIN.

Example 1-1. create-configs.pl

#!/usr/local/bin/perl
#
$template_file_name="rtr-template.txt";
while(<>) {
   
   ($location, $name, $lo0ip, $frameip, $framedlci, $eth0ip, $x) 
       = split (/,/);
   
   open(TFILE, "< $template_file_name") || die "config template file $template_file_name: 
$!\n";
   $ofile_name = $name . ".txt";
   open(OFILE, "> $ofile_name") || die "output config file $ofile_name: $!\n";
   
   while (<TFILE>) {
   
     s/##location##/$location/;
     s/##rtrname##/$name/;
     s/##eth0-ip##/$eth0ip/;
     s/##loop0-ip##/$lo0ip/;
     s/##frame-ip##/$frameip/;
     s/##frame-DLCI##/$framedlci/;
   
     printf OFILE $_;
   }
}

This Perl script is a simplified version of much longer scripts that we have used to create the configuration files for some very large networks. After loading these configuration files into the routers, we shipped them to the remote locations along with a hard copy of the configuration in case there were problems during shipment. The technician installing the router could then simply connect the appropriate cables and power on the router. He wouldn't even need to log on to the router's console unless there were unexpected problems. This methodology can save hundreds of hours in a network installation project.

The script does a relatively simple merge function and expects the input data in CSV format on STDIN. For an input file named RTR-DATA.CSV

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to make a configuration change to a large number of routers.

The Expect script in Example 1-2 makes the same configuration changes to a list of routers using Telnet. When it finishes running, the script produces a status report that identifies which devices, if any, failed to update properly. No arguments are required or expected.

Example 1-2. rtrchg.exp

#!/usr/local/bin/expect
#
#    rtrcfg.exp -- a script to perform mass configuration changes to  
#                  a list of routers using Telnet and Expect       
#
#
# Set Behavior
set tftp "172.25.1.1"
set workingdir /home/cisco/rtr
#
puts stdout "Enter user name:"
gets stdin userid
system stty -echo
puts stdout "Enter login password:"
gets stdin vtypasswd
puts stdout "\nEnter enable password:"
gets stdin enablepwd
system stty echo
system "cp $workingdir/NEWCONFIG /tftpboot/NEWCONFIG"
set RTR [open "$workingdir/RTR_LIST" r]
set LOG [open "$workingdir/RESULT" w]
while {[gets $RTR router] != -1} {
   if {[ string range $router 0 0 ] != "#"} {
     set timeout 10
     spawn telnet; expect "telnet>"; send "open $router\n"
     expect {
              {Username}   { send "$userid\r"
                             expect {
                                       {*Password*} { send "$vtypasswd\r" }
                                    }
                           }
              {Password}   { send "$vtypasswd\r" }
              timeout      { puts $LOG "$router - telnet failed"
                             close; wait; continue
                           }
            }
   
     expect {
              {Password}   { puts $LOG "$router - vty login failed"
                             close; wait; continue
                           }
              {Username}   { puts $LOG "$router - vty login failed"
                             close; wait; continue
                           }
              {>}          { puts $LOG "$router - vty login ok" }
   
              timeout      { puts $LOG "$router - vty login failed"
                             close; wait; continue
                           }
            }
   
      send "enable\r"
      expect "Password"
      send "$enablepwd\r"
      #
      expect {
               {*#}        { puts $LOG "$router - enable login ok" }
   
               {*>}        { puts $LOG "$router - enable login failed"
                             close; wait; continue
                           }
   
              timeout      { puts $LOG "$router - enable login failed"
                             close; wait; continue
                           }
             }
     # CMDs
     set timeout 30
     send "copy tftp://$tftp/NEWCONFIG running-config\r"
     expect "running-config"
     send "\r"
     expect  {
               {OK}        { puts $LOG "$router - TFTP successful"}
               timeout     { puts $LOG "$router - TFTP failed"
                             close; wait; continue }
             }
     send "copy running-config startup-config\r\r\r"
     expect  {
               {OK}        { puts $LOG "$router - config saved"}
               timeout     { puts $LOG "$router - config failed"
                             close; wait; continue }
             }
     #CMDs
     send "exit\r"; close; wait
    }
}
close $RTR; close $LOG
system "rm /tftpboot/NEWCONFIG"

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You need an up-to-date list of the hardware configurations and IOS levels of all of your routers.

The Bourne shell script in Example 1-3 uses SNMP to extract useful version information from a list of routers. By default, the script stores this data in CSV format so that you can easily import it into a spreadsheet for analysis. No arguments are required or expected.

Example 1-3. inventory.sh

#!/bin/sh
#
#    inventory.sh -- a script to extract valuable information
#                    from a list of routers. (Name, Type, IOS version)       
#
#
# Set behaviour
public="ORARO"
workingdir="/home/cisco"
#
LOG=$workingdir/RESULT.csv
infile=$workingdir/RTR_LIST
snmp="/usr/local/bin/snmpget -v1 -c $public"
#
while read device
do
  $snmp $device sysName.0 > /dev/null
  if [ "$?" = "0" ] ; then
    rtr=`$snmp $device .1.3.6.1.4.1.9.2.1.3.0 | cut -f2 -d\" `
    type2=`$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.3 | cut -f2 -d$ `
    ios=`$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.5 | cut -f2 -d$ `
    prot=`$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.4 | cut -f2 -d$ `
    echo "$device, $rtr, $type2, $ios, $prot" >> $LOG                 
  fi
done < $infile

The inventory.sh script extracts hardware and IOS version information directly from the routers using SNMP. This ensures that the data is up-to-date. You can even automate this script to run periodically, ensuring that your inventory information is always accurate. In a large network, this is much easier than keeping track of this information manually.

By default, the script captures the device name, router type, IOS version, and IOS feature set from each router. It stores this gathered information in a CSV format file called RESULT.csv.

This script requires NET-SNMP to gather the information via SNMP. You can use a different SNMP package if you prefer, but then you will need to modify the syntax appropriately. The script expects to find the executable

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You need to download all of the active router configurations to see what has changed recently.

The Perl script in Example 1-4 will automatically retrieve and store router configuration files on a nightly basis. By default, it will retain these configuration files for 30 days. The script should be run through the Unix cronutility to get the automatic nightly updates, but you can also run it manually if required. No arguments are required or expected.

Example 1-4. backup.pl

#!/usr/local/bin/perl
#
#       backup.pl -- a script to automatically backup a list of 
#                    router configuration files on a nightly basis.
#
#
# Set behaviour
$workingdir="/home/cisco/bkup"; 
$snmprw="ORARW"; 
$ipaddress="172.25.1.1";
$days="30";
#
#
$rtrlist="$workingdir/RTR_LIST";
$storage="$workingdir/storage";
$latest="$storage/LATEST";
$prev="$storage/PREV";
if (! -d $storage) {mkdir ($storage, 0755)};
if (! -d $prev) {mkdir ($prev, 0755)};
if (! -d $latest) {mkdir ($latest, 0755)};
($sec, $min, $hr, $mday, $mon, $year, @etc) = localtime(time);
$mon++; $year=$year+1900;
$today1=sprintf("%.4d_%.2d_%.2d", $year, $mon, $mday);
$today="$storage/$today1";
system("cp -p $latest/* $prev/");
unlink <$latest/*>;
mkdir ($today, 0755);
   
open (RTR, "$rtrlist") || die "Can't open $rtrlist file";
open (LOG, ">$workingdir/RESULT") || die "Can't open $workingdir/RESULT file";
print LOG "Router Configuration Backup Report for $year/$mon/$mday\n";
print LOG "= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =\n";
print LOG "Device Name                        Status\n";
print LOG "= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =\n";
while (<RTR>) {
  chomp($rtr="$_");
  $oid=".1.3.6.1.4.1.9.2.1.55.$ipaddress";
  $snmpset ="/usr/local/bin/snmpset -v1 -c $snmprw -t60 -r2 $rtr";
  $rtrfile="/tftpboot/$rtr.cfg";
  unlink $rtrfile;
  open (CFG, ">$rtrfile"); print CFG " ";close CFG;
  chmod 0666, $rtrfile;
  chop ($status=`$snmpset $oid s $rtr.cfg`);
  $status=~/.+ = "(.+)".*$/;
  if($1 eq "$rtr.cfg") {
     if( -z "$rtrfile" ) {
        $result="not ok (File empty)";
        unlink $rtrfile; 
     }
     else {
        $result="ok";
        chmod 0444, $rtrfile;
        system("mv $rtrfile $latest");
     }
  }
  else {
     $result="not ok";
     unlink $rtrfile;
  }
   
printf LOG ("%-28s       %-28s\n", $rtr,$result); 
   
}
system ("cp -p $latest/*cfg $today");
$time=$days*86400;
print "$time\n";
($sec, $min, $hr, $mday, $mon, $year, @etc) = localtime(time-$time);
$mon++; $year=$year+1900;
$rmdir=sprintf("%s/%.4d_%.2d_%.2d",$configs, $year, $mon, $mday);
system ("rm -r -f $storage/$rmdir");

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Like the previous chapter, this chapter also looks at system management issues on the router. So far we've looked primarily at general system administration issues such as filesystem management, but here we will discuss management and tuning issues related to router performance. You'll also learn some of the techniques needed to deal with disaster scenarios, such as how to create exception dumps.

Cisco's IOS supports a variety of special purpose protocols and services. Some of these are useful for network management and administration, while others are more useful for testing purposes. One of the handiest features is the Cisco Discovery Protocol (CDP), which allows you to see useful information about the Layer 2 connections between Cisco devices. This chapter shows how to use CDP and covers some of its well-known security problems.

Disabling is often the best strategy for several other services. Some, like the HTTP management interface and various test protocols (lumped together under the title of the TCP and UDP "small servers"), serve no real purpose in most production networks and are disabled by default. Others, like DNS, do have useful functions and are enabled by default.

We will discuss several important administrative features such as different methods for handling the hostnames of other network devices and command aliases to make complex commands easier to remember and type. The chapter concludes with a set of four useful scripts for gathering important information from your network devices.

You want to create aliases for commonly-used or complex commands.

You can create command aliases on your router with the alias command:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#rt
Router1(config)#on
Router1(config)#end
Router1#

Unix system administrators have been using command aliases for many years to help reduce typing and save time. These shortcut commands allow you to reduce long or complex command sequences down to a few simple characters. This is most useful for extremely common commands, or for those that are complex or difficult to remember. You can create an alias for any command, including some or all of its associated keywords or variables.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Like the previous chapter, this chapter also looks at system management issues on the router. So far we've looked primarily at general system administration issues such as filesystem management, but here we will discuss management and tuning issues related to router performance. You'll also learn some of the techniques needed to deal with disaster scenarios, such as how to create exception dumps.

Cisco's IOS supports a variety of special purpose protocols and services. Some of these are useful for network management and administration, while others are more useful for testing purposes. One of the handiest features is the Cisco Discovery Protocol (CDP), which allows you to see useful information about the Layer 2 connections between Cisco devices. This chapter shows how to use CDP and covers some of its well-known security problems.

Disabling is often the best strategy for several other services. Some, like the HTTP management interface and various test protocols (lumped together under the title of the TCP and UDP "small servers"), serve no real purpose in most production networks and are disabled by default. Others, like DNS, do have useful functions and are enabled by default.

We will discuss several important administrative features such as different methods for handling the hostnames of other network devices and command aliases to make complex commands easier to remember and type. The chapter concludes with a set of four useful scripts for gathering important information from your network devices.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to create aliases for commonly-used or complex commands.

You can create command aliases on your router with the alias command:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#rt
Router1(config)#on
Router1(config)#end
Router1#

Unix system administrators have been using command aliases for many years to help reduce typing and save time. These shortcut commands allow you to reduce long or complex command sequences down to a few simple characters. This is most useful for extremely common commands, or for those that are complex or difficult to remember. You can create an alias for any command, including some or all of its associated keywords or variables.

Here we have created the alias rt for one of the most common commands that we use every day, show ip route:

Router1(config)#rt

We can now use this simple two-letter command to display the routing table, saving time and typing:

Router1#rt
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
   
Gateway of last resort is 172.25.1.1 to network 0.0.0.0
   
S    192.168.10.0/24 [1/0] via 172.22.1.4
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.2.0 is directly connected, FastEthernet0/0.2
     172.20.0.0/16 is variably subnetted, 3 subnets, 3 masks
O       172.20.10.0/24 [110/74] via 172.20.1.2, 00:52:55, Serial0/0.2
C       172.20.1.0/30 is directly connected, Serial0/0.2
O       172.20.100.1/32 [110/65] via 172.20.1.2, 00:52:55, Serial0/0.2
     172.22.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       172.22.0.0/16 is a summary, 20:31:03, Null0
C       172.22.1.0/24 is directly connected, FastEthernet0/1
Router1#

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to adjust the ARP table timeout value.

To modify the ARP timeout value, use the arp timeout configuration command:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#Ethernet0
Router1(config-if)#600     
Router1(config-if)#end                 
Router1#

Every LAN device has an Address Resolution Protocol (ARP) cache. This is a table that the device uses to map Layer 2 MAC addresses to Layer 3 IP addresses. Without this mapping, the device could build its IP packets, but not the Layer 2 frames to carry them.

Devices discover the information in the ARP cache dynamically. If a device needs to send a packet to an IP destination, and it doesn't have a corresponding MAC address, it sends out a broadcast ARP request packet. This packet reaches every device on the LAN segment. The device that "owns" the IP address in question sends back an ARP response packet to complete the process.

Many LAN devices also automatically send a gratuitous ARP packet when they first connect to the network. A gratuitous ARP is a broadcast packet that is effectively an unsolicited ARP response. Every device on the LAN segment will receive this packet so that it can update its ARP cache in case there is ever a need to talk to this new device.

The ARP request and response process obviously takes time to complete, introducing a delay in packet processing. Furthermore, because the ARP request packets are broadcasts, they go to every device on the LAN segment and interrupt whatever that device was doing. If there are too many of these packets on the segment, it can cause traffic congestion and CPU loading on the connected devices.

To keep the ARP traffic down, all IP devices maintain a cache of these ARP entries. Old entries that are no longer valid need to be periodically removed. The router needs to flush out old ARP cache entries faster in environments where devices frequently change their address, such as when there are very short DHCP lease times. In some cases there are so many devices that the ARP cache table becomes unwieldy, taking up too much memory or too much CPU time to support. Maintaining a balance between removing old invalid entries and keeping the amount of ARP traffic down is crucial.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to change your default buffer allocations to improve router efficiency.

The router maintains two different sets of buffers; public buffers and interface buffers. The router uses these as temporary storage while processing packet data. You can tune the public buffer pools as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#100
Router1(config)#200
Router1(config)#50
Router1(config)#50
Router1(config)#end
Router1#

And you can adjust the interface buffer pools using a similar set of commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#Ethernet0
Router1(config)#Ethernet0
Router1(config)#Ethernet0
Router1(config)#Ethernet0
Router1(config)#end
Router1#

Before we start this discussion, we have three notes of caution on tuning buffers. First, adjusting your router's buffers is usually not necessary. Second, a poor set of buffer parameters can cause serious performance problems on your router and for traffic passing through the router. Third, if you do find that you need to adjust these parameters, the necessary adjustments will be unique to your network, and perhaps even to each router. Unfortunately, we can only offer general guidance.

The router maintains two different sets of buffers: public pools that the router can use for anything, and interface specific pools that it can only use for processing packets on that interface.

The public buffers fall into several different pools, according to their size. These are shown in Table 2-1.

Table 2-1: Public buffer pools
Buffer size

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

You want to see summary information about what is connected to your router's interfaces.

You can selectively enable or disable Cisco Discovery Protocol (CDP) on the entire router, or on individual interfaces:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#cdp run
Router1(config)#Se

Table of Contents