By Kevin Dooley, Ian J. Brown
Book Price: $59.99 USD
£42.50 GBP
PDF Price: $47.99

Cover | Table of Contents

Table of Contents

Chapter 1: Router Configuration and File Management

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Internet Protocol (IP) seemed ubiquitous three years ago when we wrote the first edition of this book. It was then, as it still is today, the basis of the public Internet as well as nearly all corporate, institutional, educational, and home networks. But somehow it has managed to take on an even more important role than it ever had before.

It now seems almost quaint to find a cellphone that doesn’t have its own web browser, for example. And while the delivery method of choice for WANs was Frame Relay and ATM when we wrote the first edition, it is now MPLS, an IP protocol.

For its part, Cisco has continued to be the dominant network hardware vendor in all but a few niches, and has even edged out a few of its competitors. This has been partly due to excellent marketing, but we see a large part of its success in the Internetwork Operating System (IOS) that runs on most of their routers and switches. Cisco has done a great job of producing new IOS versions with new features, and in keeping this software relatively stable and bug free through frequent incremental software releases.

Of course, these new features and new software versions mean that writing books like this one is a little bit like running a dairy; nobody wants last week’s product. Keeping up with Cisco is hard work, but we think that this new edition has captured many of the most important and useful new IOS features.

Our benchmark software version for this edition is 12.4. The vast majority of the recipes in the book will in fact run on earlier versions, and we have noted version numbers when features have been introduced recently. Many of the recipes in this edition were also present in the previous edition, but we have reviewed and updated every chapter. We also added 89 new recipes throughout the book.

Many people wrote to us after the first edition with comments and suggestions. We have been able to include just about all of these suggestions in the current edition, and we sincerely hope that you will find this new edition as useful as the previous one.

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

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Internet Protocol (IP) seemed ubiquitous three years ago when we wrote the first edition of this book. It was then, as it still is today, the basis of the public Internet as well as nearly all corporate, institutional, educational, and home networks. But somehow it has managed to take on an even more important role than it ever had before.

It now seems almost quaint to find a cellphone that doesn’t have its own web browser, for example. And while the delivery method of choice for WANs was Frame Relay and ATM when we wrote the first edition, it is now MPLS, an IP protocol.

For its part, Cisco has continued to be the dominant network hardware vendor in all but a few niches, and has even edged out a few of its competitors. This has been partly due to excellent marketing, but we see a large part of its success in the Internetwork Operating System (IOS) that runs on most of their routers and switches. Cisco has done a great job of producing new IOS versions with new features, and in keeping this software relatively stable and bug free through frequent incremental software releases.

Of course, these new features and new software versions mean that writing books like this one is a little bit like running a dairy; nobody wants last week’s product. Keeping up with Cisco is hard work, but we think that this new edition has captured many of the most important and useful new IOS features.

Our benchmark software version for this edition is 12.4. The vast majority of the recipes in the book will in fact run on earlier versions, and we have noted version numbers when features have been introduced recently. Many of the recipes in this edition were also present in the previous edition, but we have reviewed and updated every chapter. We also added 89 new recipes throughout the book.

Many people wrote to us after the first edition with comments and suggestions. We have been able to include just about all of these suggestions in the current edition, and we sincerely hope that you will find this new edition as useful as the previous one.

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

Configuring the Router via TFTP

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to load configuration commands via TFTP.

You can use the copy tftp: command to configure the router via the Trivial File Transfer Protocol (TFTP):

Router1#copy tftp://172.25.1.1/NEWCONFIG running-config
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 by 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 by using the Trivial File Transfer Protocol (TFTP). The router will copy the entire file via TFTP before entering the commands into the running configuration. This is extremely useful because sometimes 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 and not be able to continue. 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 at the end, which could break your session. However, entering commands by using TFTP avoids this problem.

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

Saving Router Configuration to Server

Content preview·Buy PDF of this chapter|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% touch /tftpboot/router1-confg
Freebsd% chmod 666 /tftpboot/router1-confg
Freebsd% telnet Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.

User Access Verification

Password: <vtypassword>
 
Router1>enable
Password: <enablepassword>
Router1#copy running-config 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 in a safe place. If you have a serious failure that damages a router’s hardware or software, the configuration will be destroyed. And anybody who has had to reconstruct a complex router configuration file from memory will 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 error is far more common than a device failure, and these human errors can result in complete or partial loss of the configuration file.

In the example, we created an empty backup configuration file on the TFTP server and 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 people 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!

Booting the Router Using a Remote Configuration File

Content preview·Buy PDF of this chapter|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)#boot network tftp Network-auto 172.25.1.1
Router1(config)#boot host tftp 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 Nonvolatile Random Access Memory (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 first 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. And 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, we should mention a few other items. First, the router will attempt to load a host and a network file. The router will assume that network files are common to all routers, while the host files contain router specific information. When you enable 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!

Storing Configuration Files Larger Than NVRAM

Content preview·Buy PDF of this chapter|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 could be hundreds of lines in length. Eventually, some configuration files will grow beyond the finite amount of NVRAM and 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 problem 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 have to 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 as follows:

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 anyway.

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

Clearing the Startup Configuration

Content preview·Buy PDF of this chapter|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 some other 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 leave it with all of its interfaces down. Fortunately, completely deleting your configuration requires two steps: erasing the startup configuration file, followed by a reload.

After you erase your startup configuration file and reload the router, it 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!

Loading a New IOS Image

Content preview·Buy PDF of this chapter|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#copy tftp://172.25.1.1/c2600-ik9o3s-mz.122-12a.bin flash:
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 space 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. And 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

System flash directory:
File  Length   Name/status
  1   11135588  c2600-ik9o3s-mz.122-12a.bin  
[11135652 bytes used, 5117276 available, 16252928 total]
16384K bytes of processor board System flash (Read/Write)

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!

Booting a Different IOS Image

Content preview·Buy PDF of this chapter|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)#boot system flash:c3620-jk9o3s-mz.122-7a.bin
Router1(config)#boot system flash:c3620-jos56i-l.120-11.bin
Router1(config)#boot system 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 which are even 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. And it would be better still if the router would try the new image first, and revert to the old image if the first 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 to try them in if it has trouble booting.

In the example, this router will try a succession of three different IOS images. If they all fail, it will resort 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!

Booting over the Network

Content preview·Buy PDF of this chapter|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 first use TFTP to download the image and before booting:

Router1#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#boot system tftp 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. Therefore, we decided to dedicate 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. So 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 is virtually impossible to secure a UDP-based service like TFTP. In addition, it makes the router dependant 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!

Copying an IOS Image to a Server

Content preview·Buy PDF of this chapter|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% touch /tftpboot/c2600-ik9o3s-mz.122-12a.bin
Freebsd% chmod 666 /tftpboot/c2600-ik9o3s-mz.122-12a.bin
Freebsd% telnet Router1
Trying 172.25.1.5...
Connected to Router1.
Escape character is '^]'.

User Access Verification

Password: <vtypassword>
 
Router1>enable
Password: <enablepassword>
Router1#copy 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#

Before attempting to upgrade the IOS version of a router it’s a good idea to save a copy of the current IOS image. 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, since IOS images are quite a bit larger than configuration files.

As we mentioned in Recipe 1.2, you have to watch out for 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 chmod command 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, IOS images pose no security concerns, as long as they are not world writeable.

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

Copying an IOS Image Through the Console

Content preview·Buy PDF of this chapter|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 either 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 does support 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 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 9,600 bps 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 115,200 bps provides the maximum throughput with the most 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!

Deleting Files from Flash

Content preview·Buy PDF of this chapter|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... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...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 : Supported filesystems of common Cisco routers

Router type	Filesystem type
7000 (RSP)	Class A
7500 (RSP 2 ,4, and 8)	Class A
12000	Class A
Route Switch Module (RSM)	Class A
1600	Class B
2500	Class B
3600	Class B
4000	Class B
AS5300	Class B
AS5800	Class C
7100	Class C
7200	Class C

Table 1-3 lists some of the different filesystem commands, their meanings, and the filesystems that they work with.

Table : Filesystem commands and their meanings

Command	Filesystem	Description
Delete	All	Marks the files as deleted, but does not permanently remove them from flash.
Squeeze	A	Permanently removes all files that have been marked as deleted.
Format	A and C	Erases the entire flash device.
Verify	All	Verifies that the IOS file’s checksum matches the value encoded in the 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!

Partitioning Flash

Content preview·Buy PDF of this chapter|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)#partition slot1: 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 it 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#

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

Router1#erase slot1:2:
Erasing the slot1:2 filesystem will remove all files! Continue? [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!

Using the Router as a TFTP Server

Content preview·Buy PDF of this chapter|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)#tftp-server 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 by using TFTP over the slow WAN connection as we described in Recipe 1.6. Then you can configure the first router to act as a TFTP server, and use it to upgrade the remaining routers over high-speed local links.

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. However, 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. Moreover, you can even use it to hold configuration files for nonCisco 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 certainly don’t recommend using the TFTP server feature on routers facing the public Internet or other 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)#access-list 99 permit 172.25.1.0 0.0.0.255
Router1(config)#access-list 99 deny any 
Router1(config)#tftp-server flash:c2600-ik9o3s-mz.122-12a.bin 99
Router1(config)#end
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!

Using FTP from the Router

Content preview·Buy PDF of this chapter|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)#ip ftp username ijbrown
Router1(config)#ip ftp password 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#

Notice that 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 have shown how to transfer files between your router and server by using TFTP. However, Cisco routers also support FTP. We find that FTP 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#copy ftp://ijbrown:ianpassword@172.25.1.1/c3620-ik9s-mz.122-10a.bin slot1:
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!

Generating Large Numbers of Router Configurations

Content preview·Buy PDF of this chapter|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. The Perl script in Example 1-1 merges a CSV file containing basic router information with a standard template file. It takes the CSV file as input on STDIN.

Example . 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 larger scripts that we have used to create the configuration files for some very large networks. We then loaded these configuration files into the routers and shipped them to the remote locations, along with a hard copy of the configuration, in case there were problems during shipment. The technician doing the router installation could then simply connect the appropriate cables and power on the router, and never need to even connect 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. It expects the input data in CSV format on STDIN. So if the input file is named RTR-DATA.CSV, you would run the script as follows:

Freebsd% create-configs.pl <

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

Changing the Configurations of Many Routers at Once

Content preview·Buy PDF of this chapter|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 by using Telnet. When it finishes running, the script produces a status report to identify which devices, if any, failed to update properly. No arguments are required or expected.

Example . 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!

Extracting Hardware Inventory Information

Content preview·Buy PDF of this chapter|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 will store this data in CSV format so you can easily import it into a spreadsheet for analysis. No arguments are required or expected.

Example . 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=\Q$snmp $device .1.3.6.1.4.1.9.2.1.3.0 | cut -f2 -d\" \Q
    type2=\Q$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.3 | cut -f2 -d$ \Q
    ios=\Q$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.5 | cut -f2 -d$ \Q
    prot=\Q$snmp $device .1.3.6.1.4.1.9.9.25.1.1.1.2.4 | cut -f2 -d$ \Q
    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 so it runs periodically to make sure 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 information gathered in a CSV format file called RESULT.csv.

This script requires NET-SNMP to gather the information via SNMP. You could 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 snmpget in the 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!

Backing Up Router Configurations

Content preview·Buy PDF of this chapter|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 automatically retrieves and stores router configuration files on a nightly basis. By default, it retains these configuration files for 30 days. The script should be run through the Unix cron utility to get the automatic nightly updates, but you can also run it manually if required. No arguments are required or expected.

Example . backup.pl

#!/usr/local/bin/perl
#
#       backup.pl -- a script to automatically backup a list of 
#                    router configuraton files on a nightly basis.
#
#
# Set behavior
$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=\Q$snmpset $oid s $rtr.cfg\Q);
  $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!

Warm Reload

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to reload the router with minimal service interruption.

To enable warm reload, use the warm-reboot command:

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

After enabling this feature, you must perform a cold reboot before it will take effect.

Beginning with IOS Version 12.3(2)T, Cisco introduced the ability to perform a warm reload of the router. The primary benefit of this feature is increased system availability, since the router is able to load the IOS version directly from memory without the need to copy the image from flash to RAM or wait for decompression of the IOS image. In addition, the router is able to reload without ROM monitor mode (ROMMON) intervention. This allows the router to complete its reload significantly quicker than a normal cold reload. For example, a cold reboot took more than four minutes longer than a warm reboot on our test router.

Although this feature requires addition memory to be consumed, its impact is minimized by the compressing of initialized variables store in RAM. To prevent corruption of the initial variables, they are marked “read-only.”

This feature not only allows you to perform manual warm reloads, but also allows the router to recover from software forced crashes. Since software forced crashes are unplanned outages, the ability to recover quickly is quite useful. By default, the router will allow five warm reboots due to software forced crashes before forcing the router to perform a cold reboot. In addition, by default the router must remain up and active for a minimum of five minutes before the next warm reboot is allowed due to software forced error. If a software forced error is experienced before the five minute period elapses then the router will perform a cold reboot.

The number of permitted warm reboots and the time duration are adjustable, as seen in the example:

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

Warm Upgrade

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to upgrade the router IOS version with minimal service interruption.

To perform a warm IOS upgrade, use the following commands:

Router1#configure  terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#warm-reboot
Router1(config)#end
Router1#reload warm file slot0:c3745-ipbasek9-mz.124-7.bin

In order to perform a warm IOS upgrade, you must enable the warm reboot feature. For more information regarding the warm reboot feature, please see the previous recipe.

Beginning with IOS Version 12.3(11)T, Cisco introduced the ability to perform warm IOS upgrades. The warm IOS upgrade feature allows the router to load a new IOS version into memory and decompress it before transferring control to the new image. Since the router continues to operate normally while the new image is loaded and decompressed, it greatly reduces service interruption.

The warm upgrade also can be used to downgrade an IOS version.

Before you can use the warm IOS upgrade feature, you must first enable the warm reboot feature and perform a cold reboot. For more information on enabling the warm reboot feature, please see the previous recipe, Recipe 1.19.

Once you’ve enable the warm reboot feature, you can perform a warm IOS upgrade by using the reload warm file command. Note that the command can load the new IOS image from a variety of locations including flash, slot0, slot1, a TFTP server, and so on:

Router1#reload warm file slot0:c3745-ipbasek9-mz.124-7.bin
Proceed with reload? [confirm] <enter>
Decompressing the image : ############################################################################################################################################################ [OK]
<Removed for brevity>

Once you issue the warm upgrade command and confirm it, the router will begin to load the image and decompress it. Once the image is loaded into memory, the router will transfer control to the new image. The overall down time is minimized.

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

Configuration Archiving

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to automatically maintain an archive of router configuration files.

To create an archive of old configuration files, use the following set of