Installing and Configuring Cisco IOS Software Modularity

Last Updated: December 11, 2012

Cisco IOS Software Modularity that runs on the renewed infrastructure microkernel and new Cisco IOS processes that are modified to make use of the new microkernel constitute enhancements to the Cisco IOS infrastructure. These enhancements increase system availability through fault containment, process restartability, event management, and modular software delivery. Cisco IOS Software Modularity is also referred to as Software Modularity, and the shorter form will be used, where appropriate, in this module.

This module describes the installation and basic configuration of Software Modularity images.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

Effective in releases following Cisco IOS 12.2(33)SXI3, Software Modularity Installer and patching are no longer supported. If the image is run in the installed mode, warning messages are displayed at startup immediately after the image is decompressed and at the very end of a showversion command. Effective in releases following Cisco IOS 12.2(33)SXI3, the install commands are no longer supported.

Effective in releases following Cisco IOS 12.2(33)SXI3, run the image using the normal Cisco IOS load and boot process.

The Software Modularity Installer manages all file copying, moving, and deletion in the system directory. Do not manipulate any files in the installed software directory that is specified when you install the software. You may manipulate files in other directories.

If you are running an installed image, you must leave the flash card in the router. Do not remove the flash card while the router is running.

When adding patches or maintenance packs, be aware that the patch functionality is available only when the router is running installed code where you have performed the install process and the bind process and you have reloaded a base image.

In Modular IOS, you cannot restart a process on the standby router. The standby router console is disabled by default. If you enable the standby router console and then enter theprocessrestart command to restart a process, the standby console will reload and display one of the following error messages:

Standby process exited, rebooting.

or

This process is not known to sysmgr.

Your system must be running a noninstalled Software Modularity image to install a base Software Modularity image. The installfile command is available only in Software Modularity images. For initial installation, the Software Modularity image is typically booted and run in a noninstalled mode, just as any other Cisco IOS image would be loaded and booted. After this has been done, the installfile command can be used to fully install the image on the file system.

Prior to Cisco IOS Release 12.2(33)SXH, Software Modularity supported directory operations, such as the creation and deletion of directories, on bootflash: and slot0: flash file systems. This was done initially to allow the installer in Software Modularity to use the flash file systems if needed. But, because Software Modularity images are too large for linear flash and the Software Modularity Installer works on compact flash, these directory commands are no longer supported. This change takes effect in Cisco IOS Release 12.2(33)SXH.

Cisco IOS Software Modularity Processes

A Posix process is a collection of code and data that resides in a single address space. Posix processes contain one or more threads of execution named Posix pthreads. A Posix pthread cannot access data outside the address space of the process (except when shared-memory application programming interfaces [APIs] are used). Residing in an individual address space, a Posix process cannot corrupt the data of another Posix process. Each Posix pthread has its own stack but shares all the process code and data.

Cisco IOS style processes contain code and data with one sequence of execution (thread) and one stack. The thread and the stack of a Cisco IOS style process are contained within one address space. The entity commonly known in Cisco IOS software as a process has been renamed as a task in Cisco IOS Software Modularity. Related tasks have been grouped in separate Cisco IOS style processes to achieve modularity.

Cisco IOS Software Modularity Installer

Software Modularity introduces the concept of installed software, which is different from just booting an image on the networking device. Software Modularity images can be saved into the flash file system and booted like a Cisco IOS image, but this is referred to as uninstalled software. To gain the benefits of the Software Modularity Installer and permit patch files to be installed, use the installfile command to write the software to flash. Installation and activation are now separate processes. The installbind command is used to bind Software Modularity base images system-wide. The installactivate command must be entered to activate a patch. Some patches require a reload to be performed, and a message appears on the console after the installactivate command has been entered to note the current state of the patch. The figure below shows a flowchart of the install activation and rollback processes.

Figure 1

Patch State Flowchart

The table below shows whether the patch code is running in the various patch states. The table starts from the Pending Install state as shown at the top of the figure above.

Table 1

Patch State Descriptions

State

State Description

Is Patch Code Running?

PendInst

Pending installation activation

No processes are running the patch code.

InstPRel

Installation activation pending reload

No processes are running the patch code until a card reload is performed.

IPRPndRo

Installation activation pending reload pending rollback

No processes are running the patch code until a card reload is performed.

PendRoll

Pending rollback

Some processes are running the patch code.

RollPRel

Rollback pending reload

Some processes are running the patch code.

RPRPndIn

Rollback pending reload pending installation activation

Some processes are running the patch code.

Active

Patch is active

Some processes are running the patch code.

Pruned

Patch is removed

No processes are running the patch code.

The Software Modularity Installer provides the ability to install, track, and manage system software. Cisco IOS Software Modularity system software includes executables, patches, shared objects, data files, and scripts. Installation of patch files--created to fix bugs or security issues--does not always require the system to be rebooted. Installable entities are checked by the Software Modularity Installer for compatibility with the currently installed system before being installed.

Note

The Software Modularity Installer manages all file copying, moving, and deletion in the system directory. Do not manipulate any files in the installed software directory that is specified when you install the software. You may manipulate files in other directories.

Cisco IOS Software Modularity Rollback Using Tags

Similar to the idea of a database rollback, Software Modularity can roll back to a set of installed files defined by a tag. The installed system is captured at a point in time by defining a tag. If a subsequent installation of a patch file adversely affects the installed system, a rollback can be performed using the defined tag. All installation actions performed since the tag was defined are deleted, and the processes affected by the rollback of installed software are restarted. After the restart, these processes use the software that was present at the time the tag was created. Tags can be deleted, and the system will remove all installation files, which will now never be used because the tag has been removed.

Cisco IOS Software Modularity Patching

When an installed Software Modularity image is running, you can add to or update portions of the software by installing a patch file. When adding patch images, be aware that the patch functionality is available only when the router is running installed code where you have performed the install process, the bind process, and reloaded a base image. Patching involves the replacement of one or more Software Modularity subsystems with an updated or corrected version. Adding a patch can usually be done with minimal impact on the operation of the system. Patching allows the delivery of specific bug fixes instead of an entire new image with many bug fixes. Fixing only specific issues allows faster deployment and minimizes the chance of unrelated bug fixes affecting other features. The Software Modularity rollback facility ensures that a patch can be removed and the system restored to a known state. When some of the Embedded Event Manager features are used, the rollback can occur without manual intervention. For more details about using Embedded Event Manager, see the "Embedded Event Manager Overview" module.

Patches are bundled into maintenance packs that may contain a collection of patches, including a specific fix plus any other dependent patches. The Software Modularity Installer verifies that the patch is compatible with the currently installed software before installing the patch. During the installation of a patch, Software Modularity can determine which subsystems are affected by the patch. Depending on the state of the patch and the relevant conditions when it is installed and activated, some processes that use the subsystems may be restarted.

Information about patches is maintained in the Patch Navigator system, which performs a similar function as the Download Software Area tool. To access Patch Navigator, go to http://www.cisco.com/go/pn . You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.

There are three ways to search for patches using the Patch Navigator tool:

Search by Software Modularity image or DDTS ID

Search by platform and base release

Search by patch ID

Each search displays a list of patches with a headline and DDTS ID for each patch. To search for more information on the specified patch, click the patch ID link. If you are searching by patch ID, detailed patch information is displayed. To download a patch, click the download patch link displayed on the listing or detail screens. The download link uses the CCO Software Center, where your username is authenticated and you are asked to provide CCO account information before being allowed to download the patch.

Cisco IOS Software Modularity Installation Repackage Creation

To allow for easier deployment of a base image and several patches to multiple routers, an installable bundled image, referred to as a repackage, can be created. While the image repackage is being created, the Software Modularity Installer saves everything in the installed state including rollback tags. An initial boot must be performed on the device on which the repackage image is to be installed. The ability to create a repackage allows standard installations to be performed across the network and saves installation time.

Cisco IOS Software Modularity Restartability

In the images that do not contain Software Modularity, if a Cisco IOS process fails, the entire system fails. Cisco IOS Software Modularity provides fault containment by isolating groups of functionality into processes. Each process runs in its own address space. A fault that causes a crash in one process will not have an adverse effect on other processes. A process can crash without causing the networking device to crash. The process will be restarted after it has crashed, and the process will return to performing its intended function. The particular services offered by the process that crashes may be interrupted during the process restart, but other services in the networking device should not be affected.

Installing Cisco IOS Software Modularity Base Images on a Single RP

Perform this task to install a Software Modularity base image and save the configuration to the running configuration file. Step 5 is an optional step included to allow you to remove all existing software bindings before you bind the software. Remember that installing a base Software Modularity image is different from copying the base image to the disk and performing a reload. The install process allows access to the patching functionality.

Depending on the feature set that you want to run, you need a minimum of 256 MB of compact flash memory and we recommend that you have 512 MB of compact flash memory. If you are installing the 512 MB compact flash memory, you must reformat the flash disk before starting a Software Modularity base image installation.

Before You Begin

Your system must be running a noninstalled Software Modularity image to perform this task because the installfile command is available only in Software Modularity images. For initial installation, the Software Modularity image is typically booted and run in a noninstalled mode, just as any other Cisco IOS image would be loaded and booted. After this has been done, the installfile command can be used to fully install the image on the file system.

To boot a Software Modularity image, follow the same procedure as when booting a Cisco IOS image.

For more information about booting Cisco IOS images, see the " Loading and Managing System Images " section of the
Cisco IOS Configuration Fundamentals Configuration Guide.

Note

In this task you remove all the existingbootsystem commands before entering a new bootsystemcommand for the new installed image. We recommend that you run the showstartup-config command and note all your existing bootsystem commands to determine which of them must be reentered and in which order.

Use the nobootsystemcommand without any arguments to remove all bootsystem commands from the startup configuration file.

Step 6

installbindsearch-root-directory[prepend]

Example:

Router(config)# install bind disk0:/sys

Binds the software by generating a bootsystem command in the configuration file that defines a location from which the software will run.

Remember that bootsystem commands in the startup configuration file are executed in the order in which they were configured.

Use the optional prepend keyword to move the latest bootsystem statement to the top of the boot variable, which makes that statement the primary image to boot.

If you know the complete directory path and image name, you can use the bootsystem command instead of the installbind command. For more details, see the Binding Cisco IOS Software Modularity task.

Step 7

bootsystem {file-url | filename}

Example:

Router(config)# boot system disk0:/sys/s72033-entservicesk9_wan-mz

Adds a bootsystem command to the configuration file.

Use the file-urlor filename argument to specify the directory path and image name.

Use this command to provide a bootsystem command for a backup image.

Note

Only one form of the bootsystem command syntax is shown. For more details, see the Cisco IOS Configuration Fundamentals Command Reference.

Step 8

Repeat Step 7 for each bootsystem command to be added to the configuration file.

--

Step 9

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 10

copyrunning-configstartup-config

Example:

Router# copy running-config startup-config

Copies the running configuration file to the startup configuration file.

Step 11

reload

Example:

Router# reload

(Optional) Reloads the operating system.

Perform this step when you are ready to run the base image that was installed in this task. After the reload, the base image becomes an installed image on which patch files can be activated.

Examples

The following partial sample output from the showinstall privileged EXEC command shows the output for the base file s72033-adventerprisek9_wan_dbg-vm after the installfile command has been performed. The state of PendInst means that the file is set to be made available to run on the system after the next activation.

Router# show install disk0:/sys
B/P C State Filename
--- - -------- --------
B PendInst disk0:/sys/s72033/base/s72033-adventerprisek9_wan_dbg-vm(12.2(99)SX1010)
.
.
.
LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
installation. On reload, this file will not run and will move to
PendInst state. If 'install activate' is done before reload, pending
removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
If the card reloads, it will be active on the system pending a rollback
If 'install activate' is done before a reload, the pending install and
removal with cancel each other and the file will simply be removed.

Installing Cisco IOS Software Modularity Patch Files on a Single RP

Perform this task to install one or more Software Modularity patches on a device that is running a single Route Processor (RP). After the initial install step, there are additional steps required to activate the patch file to implement the changes in the software.

Use this command only if a reload is required after the installactivate command in Step 5.

Examples

The following is sample output from theshowinstallrunningcommand when the installfile and installactivate commands have been entered on a single RP device but a reload has not been performed. In this example, the latest change state, InstPRel, is displayed. This change state means that the software is installed and pending a reload.

Router# show install running
Software running on card installed at location s72033 - Slot 5 :
B/P C State Filename
--- - -------- --------
B InstPRel disk0:/sys/s72033/base/s72033-adventerprisek9_wan_dbg-vm(12.2(99)SX1010)
Software running on card installed at location s72033_rp - Slot 5 :
B/P C State Filename
--- - -------- --------
B InstPRel disk0:/sys/s72033_rp/base/DRACO2_MP
LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
installation. On reload, this file will not run and will move to
PendInst state. If 'install activate' is done before reload, pending
removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
If the card reloads, it will be active on the system pending a rollback
If 'install activate' is done before a reload, the pending install and
removal with cancel each other and the file will simply be removed.

The following is sample output from the showinstallrunning command after a reload has been performed. This command displays the latest change state to be active (Active).

Router# show install running
Software running on card installed at location s72033 - Slot 5 :
B/P C State Filename
--- - -------- --------
B Active disk0:/sys/s72033/base/s72033-adventerprisek9_wan_dbg-vm(12.2(99)SX1010)
MP MAINTENANCE PACK MA0005
P Active disk0:/sys/s72033_rp/patch/s72033-AMA0001-patch
Software running on card installed at location s72033_rp - Slot 5 :
B/P C State Filename
--- - -------- --------
B Active disk0:/sys/s72033_rp/base/DRACO2_MP
MP MAINTENANCE PACK MA0005
P Active disk0:/sys/s72033_rp/patch/s72033-AMA0001-patch
LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
installation. On reload, this file will not run and will move to
PendInst state. If 'install activate' is done before reload, pending
removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
If the card reloads, it will be active on the system pending a rollback
If 'install activate' is done before a reload, the pending install and
removal with cancel each other and the file will simply be removed.

Installing Cisco IOS Software Modularity Base Images on a Dual RP

Perform this task to install a Software Modularity base image on a dual RP device and save the configuration to the running configuration file. Step 6 is an optional step included to allow you to remove all existing software binds before you bind the software. Remember that installing a base Software Modularity image is different from copying the base image to the disk and performing a reload. The install process allows access to the patching functionality.

Depending on the feature set that you want to run, you need a minimum of 256 MB of compact flash memory and we recommend that you have 512 MB of compact flash memory. If you are installing the 512 MB compact flash memory, you must reformat the flash disk before starting a Software Modularity base image installation.

Before You Begin

Your system must be running a noninstalled Software Modularity image to perform this task because the installfile command is available only in Software Modularity images. For initial installation, the Software Modularity image is typically booted and run in a noninstalled mode, just as any other Cisco IOS image would be loaded and booted. After this has been done, the installfile command can be used to fully install the image on the file system.

To boot a Software Modularity image, follow the same procedure as when booting a Cisco IOS image.

For more information about booting Cisco IOS images, see the " Loading and Managing System Images " section of the Cisco IOS Configuration Fundamentals Configuration Guide at the following URL:

In this task you remove all the existingbootsystem commands before entering a new bootsystemcommand for the new installed image. We recommend that you run the showstartup-config command and note all your existing bootsystem commands to determine which of them must be reentered, and in which order.

Installs a Software Modularity base image file from the specified path for the source into the specified local directory for the destination on the standby RP.

This step is performed to install a file in the standby RP where the destination is a slave device that exists on the standby RP.

Use the destination-directory argument to specify the slave destination equivalent to the destination on the active RP in Step 2. In this example, the destination is disk0: for the active RP and slavedisk0: for the standby RP.

The optional interactive keyword displays more detailed output.

Note

This example shows how to use the remote copy protocol (rcp) to source the file, but any URL that can be used as the source of the copy command can be used as the source of the installfile command.

Step 4

showinstallsearch-root-directory [detailed|pending]

Example:

Router# show install disk0:/sys

(Optional) Displays information about the installed software.

The search-root-directoryargument displays information about the software installed at the specified location.

The optional detailed keyword displays more detailed information about the installed software.

Use the nobootsystemcommand without any arguments to remove all bootsystem commands from the startup configuration file.

Step 7

installbindsearch-root-directory[prepend]

Example:

Router(config)# install bind disk0:/sys

Binds the software by generating a bootsystem command in the configuration file that defines a location from which the software will run.

Remember that bootsystem commands in the startup configuration file are executed in the order in which they were configured.

Use the optional prepend keyword to move the latest bootsystem statement to the top of the boot variable, which makes that statement the primary image to boot.

If you know the complete directory path and image name, you can use the bootsystem command instead of the installbind command. For more details, see the Binding Cisco IOS Software Modularity task.

Step 8

bootsystem {file-url | filename}

Example:

Router(config)# boot system disk0:/sys/s72033-entservicesk9_wan-mz

Adds a bootsystem command to the configuration file.

Use the file-urlor filename argument to specify the directory path and image name.

Use this command to provide a bootsystem command for a backup image.

Note

Only one form of the bootsystem command syntax is shown. For more details, see the Cisco IOS Configuration Fundamentals Command Reference.

Step 9

Repeat Step 8 foreach bootsystem command to be added to the configuration file.

--

Step 10

exit

Example:

Router(config)# exit

Exits global configuration mode and returns to privileged EXEC mode.

Step 11

copyrunning-configstartup-config

Example:

Router# copy running-config startup-config

Copies the running configuration file to the startup configuration file.

Step 12

hw-modulemodulemodule-numberreset

Example:

Router# hw-module module 6 reset

Resets the standby RP, which will reboot and start running the installed code.

Use the module-number argument to specify the module number of the standby RP.

After entering this command, wait until the standby RP has rebooted fully before performing the next step.

Step 13

redundancyforce-switchover

Example:

Router# redundancy force-switchover

Conducts a manual switchover to the redundant supervisor engine for a dual processor redundant system.

The redundant supervisor engine becomes the new active supervisor engine running the new Software Modularity image. The modules are reloaded, and the module software is downloaded from the new active supervisor engine.

The old active supervisor engine reboots with the new image and becomes the redundant supervisor engine.

Installing Cisco IOS Software Modularity Patch Files on a Dual RP

Perform this task to install one or more Software Modularity patch files on a device running dual RPs. Although this task is similar to the task for a single RP, there are additional steps to install and activate the patch file on a dual RP device.

The steps required to activate a Software Modularity patch file are more complex on a dual RP device than on a single RP device. After a patch file is installed on both active and standby RPs, a process restart may be performed if the patch file does not require a reload. The first instance of the installactivate command causes the standby RP to reset and renegotiate the high availability (HA) mode for the activated patch files. When the standby RP comes back up, if the set of patches that are in an active state is different from the set of patches currently running on the active RP, the standby RP comes up in route processor redundancy (RPR) mode. If a reload is required to activate the patch file, a message is displayed, but no reset is performed.

The second instance of the installactivate command causes a process restart on the active RP followed by another reset of the standby RP and a renegotiation of the high availability (HA) mode for the activated patch files. At this point both the active and standby RPs should have the same set of patch files in the active state causing the standby RP to come up in the highest HA mode that you have configured. Only the standby RP is being reset so no outage should occur. If a reload is required, the software does not perform a reset.

If a reload is not required for the patch files, the showinstallrunning command will display the patches in an active state and the task is complete. If a reload is required by the patch files, the display will show the patches in an installed and pending a reload (InstPRel) change state. Use the hw-modulemodulereset command for the standby RP module to reset the standby RP and activate the patches on the standby RP. In a similar process to the installactivate command, the standby RP may come up in RPR mode if the patches are different between the active and standby RP. The redundancyforce-switchover command is then entered, and the previous active RP resets while the previous standby RP becomes the active RP. If the system is in RPR mode, the switchover causes an outage. After the switchover is complete and the set of patches in an active state is the same on both the active and standby RPs, the software will come up in the highest HA mode that you have configured. Use the showinstallrunning command to view the state of the patches after the patch file activation is complete.

If the patch file does not require a reload, a process restart may be performed. The standby RP is reset to renegotiate the high availability (HA) mode for the activated patch files. When the standby RP comes back up, if the set of patches that are in an active state is different from the set of patches currently on the active RP, the standby RP comes up in RPR mode. If a reload is required, a message is displayed, but no reset is performed.

The optional reload keyword treats the patch to be activated as a reload patch, thereby bypassing a time-consuming process restart.

Step 7

installactivatesearch-root-directory[reload]

Example:

Router(config)# install activate disk0:/sys

Activates the current pending change set on the active RP.

The search-root-directory here is for the active RP.

Enter Y when prompted for confirmation.

Note

This second instance of the installactivate command causes a process restart on the active RP, followed by another reset of the standby RP and a renegotiation of the high availability (HA) mode for the activated patch files. At this point both the active and standby RPs should have the same set of patch files in the active state, causing the standby RP to come up in the highest HA mode that you have configured. Only the standby RP is being reset, so no outage should occur. If a reload is required, the software does not perform a reset.

Step 8

showinstallrunning [detailed|pending]

Example:

Router# show install running

(Optional) Displays information about the software that is currently running on each location in the system.

The optional detailed keyword displays more detailed information about the installed software.

If a reload is not required for the patch files, the display shows the patches in an active state and the task is complete.

If a reload is required by the patch files, the display shows the patches in an InstPRel change state. This change state means that the software is installed and pending a reload.

Note

If the patch does not require a reload, the task is complete and Step 9 through Step 11 are not required.

Step 9

hw-modulemodulemodule-numberreset

Example:

Router# hw-module module 6 reset

(Optional) Resets the standby RP, which will reboot and start running the installed code.

Use this command only if a reload is required after the installactivate command in Step 7.

Use the module-number argument to specify the module number of the standby RP.

After entering this command, wait until the standby RP has rebooted fully before performing the next step.

Note

This command resets the standby RP and activates the patches on the standby RP. In a similar process to the installactivate command, the standby RP may come up in RPR mode if the patches are different between the active and standby RP.

Step 10

redundancyforce-switchover

Example:

Router# redundancy force-switchover

(Optional) Conducts a manual switchover to the redundant supervisor engine for a dual processor redundant system.

Use this command only if a reload is required after the installactivate command in Step 7.

The redundant supervisor engine becomes the new active supervisor engine running the new Software Modularity image. The modules are reloaded, and the module software is downloaded from the new active supervisor engine.

The old active supervisor engine reboots with the new image and becomes the redundant supervisor engine.

Note

This command resets the previous active RP while the previous standby RP becomes the active RP. If the system is in RPR mode, the switchover causes an outage. After the switchover is complete and the set of patches in an active state is the same on both the active and standby RPs, the software will come up in the highest HA mode that you have configured.

Step 11

showinstallrunning [detailed|pending]

Example:

Router# show install running

(Optional) Displays information about the software that is currently running on each location in the system.

The optional detailed keyword displays more detailed information about the installed software.

Examples

The following is sample output from the showinstallrunning command when the installfile and installactivate commands have been entered on a dual RP device, but a reload has not been performed:

Router# show install running
Software running on card installed at location s72033 - Slot 5 :
B/P C State Filename
--- - -------- --------
B Active disk0:/sys/s72033/base/s72033-adventerprisek9_wan_dbg-vm(12.2(99)SX1010)
Software running on card installed at location s72033_rp - Slot 5 :
B/P C State Filename
--- - -------- --------
B Active disk0:/sys/s72033_rp/base/DRACO2_MP
Software running on card installed at location s72033 - Slot 6 :
B/P C State Filename
--- - -------- --------
B Active slavedisk0:/sys/s72033/base/s72033-adventerprisek9_wan_dbg-vm(12.2(99)SX1010)
Software running on card installed at location s72033_rp - Slot 6 :
B/P C State Filename
--- - -------- --------
B Active slavedisk0:/sys/s72033_rp/base/DRACO2_MP
LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
installation. On reload, this file will not run and will move to
PendInst state. If 'install activate' is done before reload, pending
removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
If the card reloads, it will be active on the system pending a rollback
If 'install activate' is done before a reload, the pending install and
removal with cancel each other and the file will simply be removed.

Cisco IOS Software Modularity images cannot be installed directly on a device that is currently running a Cisco IOS software image. Cisco IOS Software Modularity uses the installfile privileged EXEC command to install new images. Cisco IOS images do not recognize commands that are specific to Software Modularity, so the installfile command is not present in Cisco IOS images. Therefore, you must perform the following task to install the first Software Modularity image on a device that is currently running a Cisco IOS image.

You can use a TAR file created from a system that is running a Cisco IOS Software Modularity image to extract that configuration onto a system that is running a Cisco IOS software image. This enables you to upgrade a system that is running a Cisco IOS image to a Software Modularity image without the need for multiple system reloads.

Display the list of files on the system to ensure that there is enough space in the boot disk to create a TAR file of the configuration.

Step 3

archivetar/createdestination-urlflash:/file-url

Example:

Switch# archive tar /create disk0:ion_tar flash:/sys

Creates a TAR file.

Fordestination-url, specify the destination URL alias for the local or network file system and the name of the TAR file to create.

For flash:/file-url, specify the location on the local flash file system from which the new TAR file is created. You can also specify an optional list of files or directories within the source directory to write to the new TAR file. If none are specified, all files and directories at this level are written to the newly created TAR file.

Step 4

Do one of the following:

copysystem:running-configtftp:[[[//location]/directory]/filename]

copynvram:startup-configtftp:[[[/location]/directory/]filename

Example:

Switch# copy system:running-config tftp://172.16.2.155/ion_tar

Example:

.

Example:

.

Example:

.

Example:

Write file ion_tar on host 172.16.2.155? [confirm] y

Uploads the file to the TFTP server.

Specify the IP address or hostname of the TFTP server and the destination filename.

Reloads the operating system to load the Software Modularity image that has been extracted from the TAR file.

Upgrading a Cisco IOS Software Modularity Image

Perform this task to upgrade between Software Modularity images, to upgrade to an installed Software Modularity image, and to save the configuration to the running configuration file. Your system must already be running a Software Modularity image to perform this task.

Installing a base Software Modularity image can be achieved by copying the image onto the flash disk and performing a system reload. This brings the system up in non-installed or single binary file mode. Patching is not available when the system is brought up in single binary file mode. To install a base Software Modularity image so that the system is in installed mode and can perform patching, install the Software Modularity image on the flash disk and reload the system.

To successfully boot an image from ROMMON, the boot device (for example, disk0:) must have a MONLIB file present. The MONLIB file is the ROMMON library used by ROMMON to access files in the flash file system. To verify that a MONLIB file is present, use the showfile-systemsystem command. If no MONLIB file is present, you must format the disk before the installation can be performed. To format the disk, use the format command in privileged EXEC mode.

Note

In this task you remove all the existing bootsystemcommands before entering a newbootsystemcommand for the upgraded image. We recommend that you run the showstartup-config command and note all your existing bootsystem commands to determine which of them must be reentered and in which order.

Use the installclear command with caution because the command cannot be reversed. After an installation is cleared, it cannot be undone. Software that is currently running or that has been bound to run cannot be cleared. For bound software, you must remove the binding with thenoinstallbindcommand before using the installclear command.

Examples

The following sample output from the showinstallrunning privileged EXEC command shows the output for the base file s72033-lpservicesk9-vm after the installclear command has been performed. The Active state means that the file is active in the system.

Router# show install running
B/P C State Filename
--- - ----- --------
Software running on card installed at location c2_lc - Slot 1 :
B Active disk0:/sys/c2_lc/base/C2LC
Software running on card installed at location s72033_rp - Slot 6 :
B Active disk0:/sys/s72033_rp/base/DRACO2_MP
Software running on card installed at location s72033 - Slot 6 :
B Active disk0:/sys/s72033/base/s72033-lpservicesk9-vm - Version 12.2(33)SXH
Software running on card installed at location c2_lc - Slot 8:
B Active disk0:/sys/c2_lc/base/C2LC
LEGEND:
-------:
B/P/MP - (B)ase image, (P)atch, or (M)aintenance (P)ack
'C' - (C)ommitted
Pruned - This file has been pruned from the system
Active - This file is active in the system
PendInst - This file is set to be made available to run on the
system after next activation.
PendRoll - This file is set to be rolled back after next activation.
InstPRel - This file will run on the system after next reload
RollPRel - This file will be removed from the system after next reload
RPRPndIn - This file is both rolled back pending a reload, and pending
installation. On the reload, this file will not run and will move to
PendInst state. If 'install activate' is done before reload, pending
removal and install cancel each other and file simply remains active
IPRPndRo - This file is both installed pending a reload, and pending rollback.
If the card reloads, it will be active on the system pending a rollback
If 'install activate' is done before a reload, the pending install and
removal will cancel each other and the file will simply be removed
Occluded - This file has been occluded from the system,
a newer version of itself has superseded it.

Binding Cisco IOS Software Modularity

Perform this task to bind the Software Modularity image system-wide or on just one specified node. This task can be useful if you want to change the software to run when you have several installed systems. The installbind command generates a bootsystem command, but the installbind command is not inserted into the configuration. The benefit of using the installbind command is that you just specify the search root directory, which is the destination directory used in the installfile command, and the software will determine the directory structure and image file. If you use the bootsystem command, you must enter the complete directory path and image name.

Each instance of the bootsystem command generated by an installbind command is saved in the configuration file in the order in which it was configured; the normal behavior for bootsystemcommands. To configure a system to have the newly installed Software Modularity image as the primary image to boot, you must remove all previous bootsystem commands in the configuration and enter them in the order in which you want them to run. Alternatively, you can download the startup configuration to a text file, insert the new installbind or bootsystem command, and copy the changes back into the startup configuration.

To remove all bootsystem commands from the configuration file, use the no form of the command without any arguments. Using the no form of the installbind command will remove only the bootsystemcommands for installed software, and leaving other bootsystem commands.

Note

Performing this task to bind one or more Software Modularity images changes the startup configuration file, but an image reload or switchover must be performed before the installed and bound image is actually running on the device.

Note

In this task you remove all the existingbootsystem commands before entering a new bootsystemcommand for the new installed image. We recommend that you run the showstartup-config command and note all your existing bootsystem commands to determine which of them must be reentered, and in which order.

SUMMARY STEPS

1.enable

2.showstartup-config

3.configureterminal

4.nobootsystem[file-url | filename]

5.installbindsearch-root-directory[prepend

6. Repeat Step 5 , if required, to bind each system in order of priority.

7.bootsystem {file-url | filename}

8. Repeat Step 7 for each boot system command to be added to the configuration file.

Perform this task to create a tag to define an installation that was set at a point in time. If a subsequent installation of a patch file adversely affects the installed system, a rollback can be performed using the defined tag.

There are three Cisco-defined rollback tags:

CISCO_BASE--This tag is defined as the base image with no patches or other tags. Using this tag with the installrollback command takes you back to the installed base image.

CISCO_LATEST--This tag is defined as removing one level of install file. Using this tag with the installrollback command removes the set of files that were added with the last installfile command entry. Effectively, the software rolls back the most recently installed patch whether active or not. If the patch is in an active state, it will set the patch to a PendRoll state, meaning that the changes will not take place until the installactivate command is entered. If the patch has been installed but is not activated, the installrollback command removes the installed patch.

CISCO_LATEST_ACTIVATE--This tag is defined as removing one level of install activation. Using this tag with the installrollback command removes the set of files that were most recently activated by the installactivate command.

Do not use these tag names for your tags. If you do not create any tags, these tags are defined by default and can be used with the installrollback command.

Defines a tag name for a set of software files installed at the root directory specified in the installfile command.

Step 3

installprunesearch-root-directorytag-name [files]

Example:

Router# install prune disk0:/sys tag1

(Optional) Removes a previously defined tag or unused files from the installed software.

All files no longer required by the system as a result of the tag removal are deleted.

The optional files keyword removes all of the tags from the base image to the tag specified except for the specified tag. After this command is entered with the optional files keyword, rollback cannot be done to any tag beyond the specified tag; rollback can be performed to the base image only.

Using Tags to Roll Back the Cisco IOS Software Modularity Installation

Perform this task to roll back the Software Modularity installation using tags that define an installation that was set at a point in time. All installation actions performed since the tag was defined are deleted, and the processes affected by the rollback of installed software are restarted. After the restart, these processes use the software that was present at the time at which the tag was created.

The following is sample output from the showinstallrunningdetailedcommand after the installrollback command has been entered to roll back the software from the MA0005 tag back to the base tag and after the installactivate command has been entered:

Creating a Repackage of a Cisco IOS Software Modularity Installation

Perform this task to create a repackage (replication) of a Software Modularity image and related patches for installation on multiple routers. While the image repackage is being created, the Software Modularity Installer saves everything in the installed state, including rollback tags. An initial boot must be performed on the device on which the repackaged image is to be installed.

In the following example, the Software Modularity Installer is used to install a Software Modularity image and then bind the image directory. A tag is created and the installation is replicated to create a repackage file. After a patch file is installed and the pending change state is activated, a decision is made to perform a roll back of the software to the point in time when tag1 was created. The processes affected by the roll back are then restarted and tag1 is deleted.

In the following example, the Software Modularity Installer is used to install a base Software Modularity image and a patch file on a dual RP device. The bootsystem commands are removed, a software bind is entered and followed by another bootsystem command for a backup image. A patch file is installed and the standby RP is activated. When the standby RP comes up, the active RP is activated. The configuration file is copied to the startup configuration file, and a switchover is performed.

Example Upgrading a Cisco IOS Software Modularity Image

In the following example, the Software Modularity Installer is used to upgrade a Software Modularity image and then bind the image to a new directory. Theinstallclearcommand is then used to remove the older Software Modularity image from its original directory.

RFCs

RFC

Title

No new or modified RFCs are supported, and support for existing RFCs has not been modified.

--

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

The installfile, installbind, showinstall, and installactivate commands have been enhanced to support the Software Modularity Installer, which is used to manage the installation of base images and patches on an Software Modularity system.

Process MIB Enhancements for Software Modularity

12.2(33)SXH

The CISCO-PROCESS-MIB has been enhanced to support Portable Operating System Interface (POSIX) operating systems such as Cisco Software Modularity. Cisco Software Modularity images have been updated to implement the enhanced CISCO-PROCESS-MIB.

To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.