Cisco IOS Image Concepts and Configuration
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Overview
An important skill for Cisco network engineers to have is the ability to correctly perform an image update/upgrade. Although many entry-level engineers might not have the chance to upgrade many production routers, it is a vital skill to have as a network engineer because it will eventually be called on (either when an upgrade is happening or when a router is being placed or replaced). This article covers the different image types that exist on most Cisco equipment, Cisco’s image-naming structure, and how to perform image updates/upgrades.
Cisco Image Types
On most Cisco platforms, two different images are held within a device. A boot image (also referred to as the xboot, rxboot, bootstrap, or bootloader) and the system image (the complete IOS image). The boot image is a subset of the Cisco IOS software that is used when network booting when loading IOS images onto a device or when the system image has been corrupted. Depending on the platform, the boot image can be contained within ROM or flash memory. The system image is used when the device is in a “normal” operating state and is typically contained within flash memory (regardless of flash location [device building flash, slot0, slot 1, and so on).
Cisco Image Naming
The Cisco IOS image-naming structure can be a confusing mess of different letters if the engineer is not familiar with the various feature sets from each platform. The structure of the IOS image is typically platform:featureset:type. The platform is usually a short representation of the model type; for example, the 7206 model is represented with a platform of c7200. The featureset represents what type of features are included in a specific image. (This can be a little confusing because the featuresets available change between platforms. For example, the 7206 Advanced Enterprise Services Image would have the image featureset representation of adventerprisek9, where “adventerprise” = Advanced Enterprise Services and “k9” = strong encryption). The type represents the characteristics of the image itself (for example, whether it is intended to be stored in flash, RAM, or ROM). The following table shows the different possibilities for type (for example, the same 7206 image has a type of mz, which means it is run from RAM and ZIP compressed).
Table 1 - Type Codes
| Letter | Description |
f |
The image runs in flash. |
m |
The image runs in RAM. |
r |
The image runs in ROM. |
l |
The image is relocatable. |
z |
The image is ZIP compressed. |
x |
The image is MZIP compressed. |
With some of the newer platforms, these different feature sets and different images are being replaced with a common universal image that contains the code for all features. The features that are provided will depend on those authorized by Cisco in the purchased license. Some engineers like this and some don’t, but it does add another thing for engineers to be familiar with.
Cisco Image Updating/Upgrading
Many methods that can be used to update/upgrade a Cisco image. This section reviews the most commonly taught methods; it is by no means a complete list of the possibilities. Generally, most engineers rely on a Trivial File Transfer Protocol (TFTP) server and client (the device) to do image updates/upgrades. However, you can update/upgrade images using the Remote Copy Protocol (RCP) or File Transfer Protocol (FTP). The process that needs to be followed with each is a little different, but the concept is generally the same: Copy an image either from the device to a remote location or from a remote location to a device. TFTP has traditionally been used because a TFTP server is so easy to set up and configure, and it is typically a very small standalone application.
Depending on the platform being used, there may or may not be enough space available to hold more than one IOS image. When there is not enough space, it is vital to ensure that the proper image has been received and that connectivity to the device will not be interrupted. This is vital because on these devices the existing image is erased as part of the copying process. If the wrong image is being used or if the connection is lost, the device will become a large brick without physical access. Although it is theoretically possible to recover these devices (with physical access using a serial connection), it is certainly not an optimal process.
Using TFTP
The most common of the methods used when transferring Cisco IOS images to and from devices is TFTP. The TFTP protocol is a skinny form of the FTP protocol that utilizes UDP (rather than TCP) and thus does not provide any type of retransmission or reordering; it is, however, generally faster.
The process to copy an image from a network TFTP server to a device is very simple, as shown in Table 2.
Table 2 - Copying from TFTP Server to Device
| 1 | Copy a file from a TFTP server to the device. |
router#copy tftp device-destination |
The typical device-destination of an image on a device is flash. This variable of the command can be altered to reflect the different potential destinations depending on the platform (for example, slot0:, disk0:).
The process to copy an image from a device to a TFTP server is just as simple, as shown in Table 3.
Table 3 - Copying from TFTP Server to Device
| 1 | Copy a file from a device to a TFTP server. |
router#copy device-destination tftp |
Using RCP
When you are using Remote Copy (RCP), a remote username is required to request a file from the server. Because of this, you have four options to obtain a username: Set the username before using the copy command, specify the RCP username as part of the interaction with the copy command, use the tty username, or use the device’s hostname (in this order). Table 4 shows the process of updating/upgrading using RCP.
Table 4 - Using a RCP Server for Image Management
| 1 | Enter global configuration mode. |
router#configure terminal |
2 |
Configure the RCP username (optional). |
router(config)#ip rcmd remote-username username |
3 |
Exit global configuration mode. |
router(config)#exit |
4 |
Copy a file from a RCP server to a device. Note: A username prompt will be part of this command. |
router#copy rcp device-destination |
|
Or |
|
4 |
Copy a file from a device to a RCP server. Note: A username prompt will be part of this command. |
router#copy device-destination rcp |
Using FTP
When using FTP, it is usual for both a username and a password to be used. You can, however, allow FTP to use an anonymous FTP user. The username and password combination that is used depends on the device configuration and on how the command is issued. The username/password combination that is going to be used can be specified using the copy command. If specified, they are used over any other option. If the username/password is not set with the copy command, any configured FTP username/password will be used. If these do not exist within the configuration, an anonymous connection is attempted. Table 5 shows the process of updating/upgrading using FTP.
Table 5 - Using a FTP Server for Image Management
| 1 | Enter global configuration mode. |
router#configure terminal |
2 |
Configure the FTP username (optional). |
router(config)#ip ftp username username |
3 |
Configure the FTP password (optional). Note: This is not encrypted in the configuration. |
router(config)#ip ftp password password |
3 |
Exit global configuration mode. |
router(config)#exit |
4 |
Copy a file from a FTP server to a device. |
router#copy ftp[://username:password@location] device-destination |
|
Or |
|
4 |
Copy a file from a device to a FTP server. |
router#copy device-destination ftp[://username:password@location] |
Summary
Updating and upgrading IOS devices is not overly complex, but it can become a quick nightmare if part of the process does not work correctly. This is especially true when a device has room for only a single image. Take care to ensure that a stable server platform exists before commencing any update/upgrade.