Downloading and Installing Software Upgrades

This appendix describes how to locate, download, and install software updates for the switch. Because software updates are stored in the switch file system, this appendix includes a section on browsing the file system. This appendix includes the following sections:

Upgrade Process Overview

This appendix provides a series of quickstart procedures that describe how to perform graceful and non-graceful upgrades to the switch. To perform a graceful upgrade on a switch card, the card must be operating in redundant mode with another switch card of the same type. When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

Note Graceful upgrades to Release 4.0 are supported from Release 3.0 and Release 3.0.20. If you are running a release prior to Release 4.0, you must upgrade to Release 3.0 or Release 3.0.20 before you can upgrade to Release 4.0.

When a card to be upgraded is not operating in redundant mode, you must complete a non-graceful upgrade, which disrupts all traffic that passes through the card. For PXM cards, an ungraceful upgrade interrupts all traffic passing through the switch. For all other types of cards, an ungraceful upgrade affects only the traffic that passes through that card.

When you upgrade the software in a switch, you should refer to the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00 for the latest information. Each type of switch card runs boot and runtime software. The recommended sequence for upgrading the software on switch cards is as follows:

Typically, the boot software requires less frequent upgrades. Some upgrades might only require updates to one type of switch card. The Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00 should explain which software components require upgrading.

•

For additional information on a task within a quickstart procedure, see the appendix section to which the procedure refers

The next section presents the quickstart procedure for switch card software upgrades.

Quickstart Procedures for Software Upgrades

The following sections provide quickstart procedures for the following upgrades:

Graceful PXM Boot Upgrades from Releases Prior to Release 3.0.20

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

All releases up prior Release 3.0.20 require entry into shellcon mode to complete a PXM boot upgrade. The PXM boot upgrade takes a little more time and a few more commands for these early releases.

Note This quickstart applies only if you are upgrading from a release prior to release 3.0.20. If you are upgrading from Release 3.0.20 or later, use the quickstart procedure in the " Graceful PXM Boot Upgrades from Release 3.0.20 and Later" section later in this chapter.

When a boot software upgrade is required, the procedure for upgrading redundant PXM cards is as follows:

After the standby card becomes the active card, manually upgrade the non-active card.

This process ensures a smooth transition to the new software and preserves all established calls. During the short period when the roles of the active and standby cards are switched, all calls that are not established are lost.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	username password saveallcnf	If you want to save the configuration before the upgrade, establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges. This optional step saves the current configuration to the hard disk. see the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 3	username password	Establish a CLI session with the standby PXM card using the CP port on the PXM-UI-S3 or PXM-UI-S3/B back card and a user name with CISCO_GP privileges.
Step 4	sh sysBackupBoot <Return> (3.0 and earlier)	Change to the PXM Backup Boot mode. Note that the software versions 3.0 and earlier require you to press Return during the reboot sequence to enter backup boot mode. See the " Changing to PXM Backup Boot Mode" section in "PXM Backup Boot Procedures."
Step 5	sysPxmRemove	At the backup boot prompt, enter the sysPxmRemove command: This step prevents the active card from resetting the standby card while you are working with it.
Step 6	sysFlashBootBurn "path/filename" reboot username password dspcd	Burn the boot code. Remember to enter quotation marks before and after the boot software filename, and specify the complete path. For example: `sysFlashBootBurn "C:FW/pxm1e_004.000.000.201_bt.fw"` Caution If the card is removed or reset, or if switch power is interrupted during the boot software upgrade, the upgrade will not complete, the card will not operate, and the card must be returned to Cisco for repair. Note Remember to enter quotation marks before and after the boot software filename. The filename you use depends on the release to which you are upgrading. For more information, refer to the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00. See the " Upgrading PXM Boot Software from Releases Prior to 3.0.20" section later in this appendix.
Step 7	username password	Establish a CLI session with the active PXM card (which is the non-upgraded card). Use the CP port on the PXM-UI-S3 or PXM-UI-S3/B back card and a user name with CISCO_GP privileges.
Step 8	switchcc y	Switch the roles of the active and standby cards so you can upgrade the non-upgraded card in standby mode.
Step 9	sh sysBackupBoot <Return> (3.0 and earlier)	Change to the PXM Backup Boot mode. Note that the software versions 3.0 and earlier require you to press Return during the reboot sequence to enter backup boot mode. See the " Changing to PXM Backup Boot Mode" section in "PXM Backup Boot Procedures.".
Step 10	sysPxmRemove	At the backup boot prompt, enter the sysPxmRemove command. This step prevents the active card from resetting the standby card while you are working with it.
Step 11	sysFlashBootBurn "path/filename" reboot username password dspcd	Burn the boot code. For example, `sysFlashBootBurn "C:FW/pxm1e_004.000.000.201_bt.fw"` Note Remember to enter quotation marks before and after the boot software filename. The filename you use depends on the release to which you are upgrading. For more information, refer to the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00. See the " Upgrading PXM Boot Software from Releases Prior to 3.0.20" section later in this appendix. Both active and standby cards should now be upgraded. The card that was active before the upgrade is now operating in standby mode.

Graceful PXM Boot Upgrades from Release 3.0.20 and Later

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

Beginning with Release 3.0.20, the Cisco MGX software supports the burnboot command for PXM boot software upgrades. If you are upgrading a Release 3.0.20 or later switch, you no longer have to enter shellcon to complete the boot upgrade. The boot upgrade is simpler and quicker in Release 3.0.20 and later.

Note This quickstart applies only if you are upgrading from Release 3.0.20 or a later release. If you are upgrading from a release prior to 3.0.20, use the quickstart procedure in the " Graceful PXM Boot Upgrades from Releases Prior to Release 3.0.20" section earlier in this chapter.

When a boot software upgrade is required, the procedure for upgrading redundant PXM card is as follows:

After the standby card becomes the active card, manually upgrade the non-active card.

Note Avoid making configuration changes while upgrading PXM software. Configuration changes can be lost when the PXM is reset during the upgrade.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section, which appears later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges or higher.
Step 3	saveallcnf	This optional step saves the current configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 4	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the standby PXM card by specifying the slot number of the standby card. For example: `M8850_LA.7.PXM.a > burnboot 8 4.0(0.201)` Caution If the card is removed or reset, or if switch power is interrupted during the boot software upgrade, the upgrade will not complete, the card will not operate, and the card must be returned to Cisco for repair. See the " Upgrading PXM Boot Software from Release 3.0.20 and Later" section, which appears later in this appendix.
Step 5	switchcc	Activate the upgraded card and place the non-upgraded card in standby mode.
Step 6	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the non-upgraded, standby PXM card by specifying the slot number of the standby card. See the " Upgrading PXM Boot Software from Releases Prior to 3.0.20" section, which appears later in this appendix.

Non-Graceful PXM Boot Upgrades

Non-graceful upgrades disrupt all switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. The quickstart procedure provides an overview and quick reference for those who have already performed ungraceful upgrades on the switch.

Note Avoid making configuration changes while upgrading PXM software. Configuration changes can be lost when the PXM is reset during the upgrade.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using the CP port on the PXM-UI-S3 or PXM-UI-S3/B back card and a user name with CISCO_GP privileges.
Step 3	saveallcnf	This optional step saves the current configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 4	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the standalone PXM card by specifying the appropriate slot number. For example: `M8850_LA.7.PXM.a > burnboot 7 4.0(0.201)` Caution If the card is removed or reset, or if switch power is interrupted during the boot software upgrade, the upgrade will not complete, the card will not operate, and the card must be returned to Cisco for repair. See the " Upgrading PXM Boot Software from Release 3.0.20 and Later" section, which appears later in this appendix.

Graceful PXM and Service Module Runtime Software Upgrades

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections.

This quickstart procedure applies to PXM1E, PXM45 and to all service module cards except the RPM family of cards. The quickstart procedure provides more detail, but the overall procedure is as follows:

Note If you plan to upgrade PXM cards and service modules, upgrade the PXM cards first. Wait until the PXM cards are operating in active and standby modes with the correct software before upgrading service modules. The software version used by the PXM cards should be equal to or later than the version used on the service modules. When service module boot software is to be upgraded, it should be upgraded before upgrading the runtime software.

Note Cisco Systems recommends that you upgrade software on one service module at a time within a switch. Wait until each service module upgrade is complete before starting an upgrade on another service module.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section, which appears later in this appendix.
Step 2		If the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00 call for a boot software upgrade, upgrade the boot software for the card you are upgrading. Note PXM cards should be upgraded first. For instructions on upgrading service module boot software, see the " Graceful Service Module Boot Software Upgrades" section, which appears later in this appendix.
Step 3	username password	Establish a CLI session with the active PXM45 card using a user name with SERVICE_GP privileges.
Step 4	saveallcnf	This optional step saves the current switch configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 5	dspcd commitrev <slot> <revision>	Verify that all previous upgrades have been committed. If a previous upgrade is not committed, commit to the new upgrade. See the " Committing to a Runtime Software Upgrade" section, which appears later in this appendix.
Step 6	loadrev <slot> <revision> dspcd	Load the new runtime software on the standby PXM or service module.
Step 7	runrev <slot> <revision> dspcd dspcd <slot>	Switch over to the standby PXM or service module and load the new runtime software on the new standby (non-upgraded) card.
Step 8	commitrev <slot> <revision>	This command prevents an accidental switch back to a previous software revision if someone enters the abortrev command. Enter the commitrev command after the former active PXM45 comes up in the standby-U state. Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands. See the " Aborting a Runtime Software Upgrade" section and the " Committing to a Runtime Software Upgrade" section, both of which appear later in this appendix.

Non-Graceful PXM and Service Module Runtime Software Upgrades

Non-graceful upgrades disrupt switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. The quickstart procedure provides an overview and quick reference for those who have already performed ungraceful upgrades on the switch.

Note Avoid making configuration changes while upgrading PXM software. Configuration changes can be lost when the PXM is reset during the upgrade.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch"section, which appears later in this appendix.
Step 2		If the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00 call for a boot software upgrade, upgrade the boot software as described in the " Graceful PXM Boot Upgrades from Release 3.0.20 and Later" section, which appears earlier in this appendix, or the " Non-Graceful Service Module Boot Software Upgrades" section, which appears later in this appendix.
Step 3	username password	Establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges.
Step 4	saveallcnf	This optional step saves the current configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 5	dspcd commitrev <slot> <revision>	Verify that all previous upgrades are committed. If a previous upgrade is not committed, commit to the new upgrade. See the " Committing to a Runtime Software Upgrade" section, which appears later in this appendix.
Step 6	loadrev <slot> <revision> dspcd	Define the new software version to be used.
Step 7	runrev <slot> <revision> dspcd	Reset the card and run the new software version.
Step 8	commitrev <slot> <revision>	This command prevents an accidental switch back to a previous software revision if someone enters the abortrev command. Enter the commitrev command after the upgraded card reaches the active state. Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands. See the " Aborting a Runtime Software Upgrade" section and the " Committing to a Runtime Software Upgrade" section, both of which appear later in this appendix.

Graceful Service Module Boot Software Upgrades

When performed properly, graceful upgrades have minimal impact on connections in progress and do not interrupt any established connections. This quickstart procedure applies to all service modules except the RPM family of cards and provides an overview and quick reference for those who have already performed graceful boot software upgrades on the switch.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section, which appears later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges or higher.
Step 3	saveallcnf	This optional step saves the current configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 4	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the standby service module by specifying the slot number of the standby card. For example: `M8850_LA.7.PXM.a > burnboot 1 4.0(0.0)` Caution If the card is removed or reset, or if switch power is interrupted during the boot software upgrade, the upgrade will not complete, the card will not operate, and the card must be returned to Cisco for repair. See the " Upgrading Boot Software on a Service Module" section, which appears later in this appendix.
Step 5	switchredcd <fromSlot> <toSlot>	Activate the upgraded card and place the non-upgraded card in standby mode.
Step 6	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the non-upgraded, standby service module by specifying the slot number of the standby card. See the " Upgrading Boot Software on a Service Module" section, which appears later in this appendix.

Non-Graceful Service Module Boot Software Upgrades

Non-graceful upgrades disrupt all switch traffic and are usually used in lab installations where the use of standalone cards provides no opportunity for a graceful upgrade. This quickstart procedure applies to all service modules except the RPM family of cards and provides an overview and a quick reference for those who have already performed ungraceful upgrades on the switch.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch. See the " Copying Software Files to the Switch" section, which appears later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges or higher.
Step 3	saveallcnf	This optional step saves the current configuration to the hard disk. See the " Saving a Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 4	burnboot <slot> <revision> dspcd <slot>	Burn the boot software on the standalone service module. For example: `M8850_LA.7.PXM.a > burnboot 1 4.0(0.0)` Caution If the card is removed or reset, or if switch power is interrupted during the boot software upgrade, the upgrade will not complete, the card will not operate, and the card must be returned to Cisco for repair. See the " Upgrading Boot Software on a Service Module" section, which appears later in this appendix.

Graceful RPM Boot and Runtime Software Upgrades

The RPM cards support graceful boot software upgrades when 1:N redundancy is established in the switch between RPM cards. Boot software is generally upgraded less often than runtime software, so be sure to compare the recommended boot software version with the boot software running on your RPMs before starting an upgrade. The correct boot software might already be installed.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

The following quickstart procedure describes how to upgrade boot and runtime software in one operation on redundant RPM cards.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch (E:RPM). See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	copy	Optional: Copy and rename the runtime file to a generic name for easy updates. See the " Upgrading RPM Runtime Software" section later in this chapter. Note If you have already configured the RPM to use a generic name and you perform this step, you can skip Steps 11 through 18.
Step 3	username password	Establish a CLI session with the active PXM card using a user name at any access level.
Step 4	cc <primarySlot>	Select the slot in which the primary RPM card is installed.
Step 5	enable password	Enter Enable mode for the router.
Step 6	dir e:	Verify router access to the PXM hard disk and the boot upgrade software.
Step 7	show flash:	Display current contents of bootflash.
Step 8	copy filename bootflash: dir bootflash:	Copy the upgrade boot software to flash. For example: `copy e:rpm-boot-mz_002.001.060.000 bootflash:`
Step 9	config terminal boot bootldr bootflash:filename ^Z show bootvar	Configure the BOOTLDR variable to specify the new boot software.
Step 10	copy bootflash:filename c:filename del bootflash:filename show flash: squeeze flash:	Reorganize files in bootflash. The switch always attempts to load the first bootable file in bootflash. If the BOOTLDR variable is not set, the new boot software must be the first file listed in the show flash: display. Copy files you want to save to the c: directory and delete all files that appear before the new boot software. Files are marked with the del command and actually deleted with the squeeze flash: command. Caution Verify that at least one valid boot or runtime image will not be deleted. If all boot and runtime images are deleted from bootflash, the RPM card must be returned to the factory for repair.
Step 11	show bootvar	Display the current runtime software filename.
Step 12	config terminal	Enter the router global configuration mode.
Step 13	no boot system	Remove the entire boot list. To remove a single file from the boot list, include a filename. For example: `Router(config)# no boot system c:rpm-js-mz_122-4.T`
Step 14	boot system e:filename	Add the new router runtime image to the boot list. For example: `Router(config)# boot system c:rpm-js-mz_122-4.T`
Step 15	boot config e:auto_config_RPM-PR_slot#	Configure the RPM card to store its configuration on the PXM hard disk. Note This step only needs to be performed once. If this command is already in the startup configuration file, you do not need to enter it again.
Step 16	^Z	Exit global configuration mode.
Step 17	copy run start	Save the new configuration. Note If you omit this step, the RPM card will continue to use the previous version of software.
Step 18	show bootvar	Verify the change in the runtime software filename.
Step 19	switchredcd <primarySlot> <secondarySlot>	This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded boot and runtime software.
Step 20	cc <secondarySlot>	Select the slot in which the secondary RPM card is installed.
Step 21	enable password dir e: show flash: copy filename bootflash: dir bootflash: config terminal boot bootldr bootflash:filename ^Z show bootvar copy bootflash:filename c:filename del bootflash:filename show flash: squeeze flash:	Repeat Steps 5 through 10 to move the upgraded boot software into bootflash.
Step 22	switchredcd <secondarySlot> <primarySlot>	This step makes the upgraded primary card active and resets the secondary RPM card. When the secondary card resets, it loads the upgraded boot software from bootflash. Both primary and secondary cards should now be using upgraded boot software. Note You do not need to upgrade runtime software on a secondary card. When a secondary card goes active, it loads the runtime software and configuration defined for the primary card.
Step 23	—	If there are other primary RPM cards that need upgrading, repeat the part of this procedure that upgrades the primary card, then enter the switchredcd command once to reload the primary card. Finally, enter the switchredcd command a second time to make the upgraded primary card active.

Graceful RPM Boot Software Upgrades

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

The following quickstart procedure describes how to upgrade redundant RPM cards.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch (E:RPM). See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using a user name at any access level.
Step 3	cc <primarySlot>	Select the slot in which the primary RPM card is installed.
Step 4	enable password	Enter Enable mode for the router.
Step 5	dir e:	Verify router access to the PXM hard disk and the boot upgrade software.
Step 6	show flash:	Display current contents of bootflash.
Step 7	copy filename bootflash: dir bootflash:	Copy the upgrade boot software to flash. For example: `copy e:rpm-boot-mz_002.001.060.000 bootflash:`
Step 8	config terminal boot bootldr bootflash:filename ^Z show bootvar	Configure the BOOTLDR variable to specify the new boot software.
Step 9	copy bootflash:filename c:filename del bootflash:filename show flash: squeeze flash:	Reorganize files in bootflash. The switch always attempts to load the first bootable file in bootflash. If the BOOTLDR variable is not set, the new boot software must be the first file listed in the show flash: display. Copy files you want to save to the c: directory and delete all files that appear before the new boot software. Files are marked with the del command and actually deleted with the squeeze flash: command. Caution Verify that at least one valid boot or runtime image will not be deleted. If all boot and runtime images are deleted from bootflash, the RPM card must be returned to the factory for repair.
Step 10	switchredcd <primarySlot> <secondarySlot>	This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded boot software from bootflash.
Step 11	cc <secondarySlot>	Select the slot in which the secondary RPM card is installed.
Step 12	enable password dir e: show flash: copy filename bootflash: dir bootflash: config terminal boot bootldr bootflash:filename ^Z show bootvar copy bootflash:filename c:filename del bootflash:filename show flash: squeeze flash:	Repeat Steps 4 through 9 to move the upgraded boot software into bootflash.
Step 13	switchredcd <secondarySlot> <primarySlot>	This step makes the upgraded primary card active and resets the secondary RPM card. When the secondary card resets, it loads the upgraded boot software from bootflash. Both primary and secondary cards should now be using upgraded boot software.
Step 14	—	If there are other primary RPM cards that need upgrading, repeat the part of this procedure that upgrades the primary card, then enter the switchredcd command once to reload the primary card. Finally, enter the switchredcd command a second time to make the upgraded primary card active.

Graceful RPM Runtime Software Upgrades

The RPM cards support graceful upgrades when 1:N redundancy is established in the switch between RPM cards.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

The following quickstart procedure describes how to gracefully upgrade runtime software on redundant RPM cards.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch (E:RPM). See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	copy	Optional: Copy and rename the runtime file to a generic name for easy updates. See the " Upgrading RPM Runtime Software" section later in this chapter. Note If you have already configured the RPM to use a generic name, you can skip to Step 12.
Step 3	username password	Establish a CLI session with the active PXM card using a user name at any access level.
Step 4	cc <primarySlot>	Select the slot in which the primary RPM card is installed.
Step 5	enable password	Enter Enable mode for the router.
Step 6	show bootvar	Display the current runtime software filename.
Step 7	config terminal	Enter the router global configuration mode.
Step 8	no boot system	Remove the entire boot list. To remove a single file from the boot list, include a filename. For example: `Router(config)# no boot system c:rpm-js-mz_122-4.T`
Step 9	boot system e:filename	Add the new router runtime image to the boot list. For example: `Router(config)# boot system c:rpm-js-mz_122-4.T`
Step 10	boot config e:auto_config_RPM-PR_slot#	Configure the RPM card to store its configuration on the PXM hard disk. Note This step only needs to be performed once. If this command is already in the startup configuration file, you do not need to enter it again.
Step 11	^Z	Exit global configuration mode.
Step 12	copy run start	Save the new configuration. Note If you omit this step, the RPM card will continue to use the previous version of software.
Step 13	show bootvar	Verify the change in the runtime software filename.
Step 14	switchredcd <primarySlot> <secondarySlot>	This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded boot software from bootflash.
Step 15	switchredcd <secondarySlot> <primarySlot>	This step makes the upgraded primary card active and resets the secondary RPM-PR card. When the secondary card resets, it loads the upgraded boot software from bootflash. Both primary and secondary cards should now be using upgraded runtime software.
Step 16		If there are other primary RPM cards that need upgrading, repeat the part of this procedure that upgrades the primary card, and then enter the switchredcd command once to reload the primary card. Finally, enter the switchredcd command a second time to make the upgraded primary card active.

Non-Graceful RPM Boot Software Upgrades

Use the non-graceful upgrade procedure in this section when you need to upgrade RPM boot software and the RPM is operating in standalone mode. Non-graceful upgrades terminate all connections and disrupt service until the upgrade procedure is complete.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

Note If the RPM is operating in 1:N redundancy mode with another RPM, upgrade the cards as described in the " Graceful RPM Boot Software Upgrades"section earlier in this chapter.

The following quickstart procedure provides an overview and quick reference for those who have already performed RPM upgrades on the switch. For detailed instructions, see the " Upgrade Procedures for RPM-PR and RPM-XF Cards" section which appears later in this appendix.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch (E:RPM). See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM card using a user name at any access level.
Step 3	cc <RPM_Slot>	Select the slot in which the RPM card is installed.
Step 4	enable password	Enter Enable mode for the router.
Step 5	dir e:	Verify router access to the hard disk and the boot upgrade software.
Step 6	show flash:	Display current contents of bootflash.
Step 7	copy filename bootflash: dir bootflash:	Copy the upgrade boot software to flash. For example: `copy e:rpm-boot-mz_002.001.000.000 bootflash:`
Step 8	config terminal boot bootldr bootflash:filename ^Z show bootvar	Configure the BOOTLDR variable to specify the new boot software.
Step 9	copy bootflash:filename c:filename del bootflash:filename show flash: squeeze flash:	Reorganize files in bootflash. The switch always attempts to load the first bootable file in bootflash. If the BOOTLDR variable is not set, the new boot software must be the first file listed in the show flash: display. Copy files you want to save to the c: directory and delete all files that appear before the new boot software. Files are marked with the del command and actually deleted with the squeeze flash: command. Caution Verify that at least one valid boot or runtime image will not be deleted. If all boot and runtime images are deleted from bootflash and the card is reset, the RPM card must be returned to the factory for repair.
Step 10	cc <active_PXM_slot> resetcd <RPM_Slot>	This command sequence restarts the RPM card with the new boot image.

Non-Graceful RPM Runtime Software Upgrades

Use the non-graceful upgrade procedure in this section when you need to upgrade RPM runtime software and the RPM is operating in standalone mode. Non-graceful upgrades terminate all connections and disrupt service until the upgrade procedure is complete.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

Note If the RPM is operating in 1:N redundancy mode with another RPM upgrade the cards as described in " Graceful RPM Runtime Software Upgrades," which appears earlier in this chapter.

The following quickstart procedure provides an overview and quick reference for those who have already performed RPM upgrades on the switch. For detailed instructions, see " Upgrade Procedures for RPM-PR and RPM-XF Cards," which appears later in this appendix.


	Command	Purpose
Step 1	ftp	Copy the boot and runtime files you want to use to the switch (E:RPM). See the " Copying Software Files to the Switch" section later in this appendix.
Step 2	copy	Copy and rename the runtime file to a generic name for easy updates. See the " Non-Graceful RPM Runtime Software Upgrades" section later in this chapter. Note If you have already configured the RPM to use a generic name, you can skip to Step 12.
Step 3	username password	Establish a CLI session with the active PXM card using a user name at any access level.
Step 4	cc <RPM_Slot>	Select the slot in which the RPM card is installed.
Step 5	enable password	Enter Enable mode for the router.
Step 6	show bootvar	Display the current runtime software filename.
Step 7	config terminal	Enter the router global configuration mode.
Step 8	no boot system	Remove the entire boot list. To remove a single file from the boot list, include a filename. For example: `Router(config)# no boot system c:rpm-js-mz_122-4.T`
Step 9	boot system e:filename	Add the new router runtime image to the boot list. For example: `Router(config)# boot system e:rpm-js-mz.122-4.T`
Step 10	boot config e:auto_config_RPM_slot#	Configure the RPM card to store its configuration on the PXM hard disk. Note This step only needs to be performed once. If this command is already in the startup configuration file, you do not need to enter it again.
Step 11	^Z copy run start	Exit global configuration mode and save the new configuration.
Step 12	show bootvar	Verify the change in the runtime software filename.
Step 13	cc <active_PXM_slot> resetcd <RPM_Slot>	This command sequence selects the active PXM card and restarts the RPM card with the new runtime image.
Step 14	dspcds dspcd <RPMR_Slot> cc <RPM_Slot>	Verify router reboot is complete.

Installing SCT Files

Use the procedure in this section when you need to manually install or upgrade SCT files. SCTs are available for PXM1E, AXSM, AXSME, and FRSM12 cards.

If you are using CWM to install or upgrade SCT files in your network, see the Cisco WAN Manager User's Guide, Release 12.

Note The following quickstart procedure is provided as an overview and as a quick reference for those who have already performed SCT upgrades on the switch. For detailed instructions, see the "Downloading and Installing SCT Files" section later in this appendix.


	Command	Purpose
Step 1	ftp	Copy the new SCT files you want to use to the appropriate C:/SCT/TEMP directory. For example, copy new PXM1E SCT files to the C:SCT\PXM directory. See the "Copying SCT Files to the Switch" section later in this appendix.
Step 2	username password	Establish a CLI session with the active PXM, AXSM, or FRSM12 card using a user name at any access level.
Step 3	dspsctchksum	Display the checksum of the SCT file you want to apply to the card.
Step 4	addsct <oprtions>	Copy the new SCT files you want to use to the appropriate C:/SCT/<card_type> directory. For example, copy new PXM1E SCT files to the C:SCT\PXM directory.
Step 5	cc	If you are applying the new SCT to a card other than the PXM1E, enter the cc command to change to that card.
Step 6	cnfcdsct	Apply the SCT to the appropriate card.
Step 7	dspscts	Verify that the new SCT is applied to the appropriate card.

Quickstart Procedures for Software Downgrades

Cisco Systems, Inc., recommends that you avoid software downgrades, which replace a current software release with another that has a lower version number. However, there are some situations in which you might want to downgrade the software. For example, if you have been testing pre-release software in a lab, the software version number can be higher than a later official software release. Any time the software version number to which you are changing is lower than the current software version, the change is a downgrade, regardless of when the software versions are released.

The following sections provide quickstart procedures for the following downgrades:

PXM and AXSM Boot Downgrades

When redundant cards are used and the downgrade software is compatible with the existing runtime software, boot software downgrades can be graceful. To perform a graceful downgrade of boot software, follow the instructions for the appropriate graceful software upgrade:

Non-Graceful PXM Runtime Software Downgrades

To downgrade PXM runtime software, you must clear the entire switch configuration. All traffic is disrupted until the switch downgrade is complete and the configuration has been re-entered. The following quickstart procedure is provided as an overview for PXM runtime software downgrades.

Note The switch does not support a configuration restore to a downgraded software version. When you downgrade the PXM runtime software, you must re-enter the configuration.


	Command	Purpose
Step 1	username password	Establish a CLI session with the active PXM card using a user name with SERVICE_GP privileges.
Step 2	saveallcnf y	Save the current switch configuration. See the " Saving a Configuration"section in Chapter 13, "Switch Operating Procedures." This step gives you the option to upgrade to the software version from which you are downgrading and use the former configuration.
Step 3	ftp	Copy the boot and runtime files you want to use to the switch. Also copy the saved configuration file from the C:CNF directory to a remote workstation so you have a backup file if something happens to the hard disk. See the " Copying Software Files to the Switch" section later in this appendix.
Step 4	clrallcnf y	Clear the current configuration. See the " Clearing a Switch Configuration" section in Chapter 13, "Switch Operating Procedures."
Step 5	sysVersionSet "version" reboot	Select the runtime firmware version the switch will use on the PXM card and restart the switch with that firmware. For example: `sysVersionSet "002.001.000.000"` Note that these commands must be entered at the PXM backup boot prompt: pxmbkup>. See the " Initializing the Switch" section in Chapter 3, "Configuring General Switch Features.".
Step 6		Reconfigure the PXM cards as described in the " Configuration Quickstart" section in Chapter 3, "Configuring General Switch Features."

Non-Graceful AXSM Runtime Software Downgrades

AXSM runtime software downgrades are always non-graceful when the PXM45 runtime software is also downgraded (because the PXM45 downgrade requires a clearing of the configuration). The quickstart procedure is provided as an overview of how to downgrade the AXSM software after the PXM45 runtime software has been downgraded.

Browsing the File System

The PXM hard disk stores log files, configuration files, and boot and runtime software. The switch operating system supports a set of UNIX-like commands that you can use to locate log files or manage software updates. Table A-1 lists commands that you can use to browse the file system.

Note File and directory names in the switch file system are case sensitive. Also, some of the commands listed in Table A-1 are not available at all administrator access levels.

Table A-1 File System Commands at Switch Prompt
Command	Description
cd	Change directories. Access level required: ANYUSER or above.
copy	Copies a file from one location to another. Syntax: copy <source file name> <destination file name> Access level required: GROUP1 or above.
del	Deletes a file. Syntax: del <file name> Access level required: GROUP1 or above.
ll	List directory contents using long format, which includes the name, size, modification date, and modification time for each file. This command also displays the total disk space and free disk space. Syntax: ll Access level required: ANYUSER or above.
ls	List directory contents using the short format, which displays filenames, total disk space, and free disk space. Syntax: ls Access level required: ANYUSER or above.
pwd	Display the present working directory. Syntax: pwd Access level required: ANYUSER or above.
rename	Renames a file. Syntax: rename <old file name> <new file name> Access level required: GROUP1 or above.
whoami	Lists the login name for the current session. Syntax: whoami Access level required: ANYUSER or above.

Locating Software Updates

For information on locating software updates, see the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00.

Copying Software Files to the Switch

This section describes how to copy software files to a Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8830, or Cisco MGX 8950 switch. The switch cards use boot software and runtime software. Each card uses the boot software to define communications between the card components and to enable cards to start up. The runtime software defines how the card operates after startup. RPM cards function on the runtime software and use the boot software only when they cannot load the runtime software.

Note The boot and runtime software are installed on the switch at the factory. Before you copy new files to the switch, verify that you need to update them by comparing the file versions on the disk to those recommended in the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00.

Cisco MGX switches provide a File Transfer Protocol (FTP) service to support file transfers to the switch. If you have FTP client software and network connectivity to both the switch and the server where the software files are stored, you can use FTP to transfer files directly from the server to the switch.

Note The following procedure describes how to copy files to the switch when the runtime software is up and running (showing the node name switch prompt). When the runtime software cannot load, copy the software files to the switch as described in the " Transferring Software Files to and from the Switch" section in "PXM Backup Boot Procedures."

Step 1

Refer to the Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830, Software Version 4.0.00 to locate a server from which you can download the files.

Step 2

Using a workstation with FTP client software, transfer PXM files from the server to the switch directory C:/FW.

The procedure you use for transferring the files depends on the FTP client software you are using. When initiating the FTP connection, remember the following:

•

When prompted for a username and password, enter the username and password you use when managing the switch.

•

When configuring file transfer options, select binary mode for the file transfer.

Step 3

To verify that the new PXM files have been transferred to the switch, log into the switch and display the contents of the C:/FW directory.

Step 4

Using a workstation with FTP client software, transfer RPM files from the server to the switch directory E:/RPM.

Note

You must use a capital E when referencing the E drive in switch commands.

Step 5

To verify that the new RPM files have been transferred to the switch, log into the switch and display the contents of the E:/RPM directory.

For more information on browsing the switch file system, see the " " section earlier in this appendix.

Upgrade Procedures for PXM Cards and Service Modules

The following sections describe procedures that support upgrades to PXM cards and service modules. For complete upgrade procedures, see the " Quickstart Procedures for Software Upgrades" section earlier in this appendix. The procedures in this section detail some of the tasks listed in the quickstart procedures.

Upgrading PXM Boot Software from Releases Prior to 3.0.20

This section describes how to upgrade the PXM boot software on a single PXM card running a release prior to Release 3.0.20. If you are performing a graceful upgrade, use the quickstart procedure described in " Graceful PXM Boot Upgrades from Releases Prior to Release 3.0.20," which appears earlier in this appendix. The following procedure provides detailed information on the upgrade task within the quickstart procedure.

Step 1

If you have not done so already, establish a CLI session with the PXM card using the CP port on the PXM-UI-S3 or PXM-UI-S3/B back card and a user name with CISCO_GP privileges.

Step 3

To burn the boot software on the PXM, enter the sysFlashBootBurn command as follows:

Replace filename with the complete path to the boot file on the PXM45 hard drive. For example:

Step 4

When the switch prompts you to confirm this action, type y and press Return.

When the boot code burning process is complete, the switch displays a message similar to the following example:

Step 5

When the boot code has been burned, reset the card with the reboot command. For example:

Step 6

When the Login prompt appears, log in to the switch as you do at the beginning of a CLI session. The switch prompt should appear.

Step 7

To confirm that the PXM card is now using the correct boot code, enter the dspcd command.

The Boot FW Rev row in the display should show the new revision as shown in the following example:

After you confirm the upgrade to the PXM card, the boot software upgrade for that card is complete.

Upgrading PXM Boot Software from Release 3.0.20 and Later

The upgrade procedure for the boot software on a single PXM card is the same for graceful and non-graceful upgrades. The difference between the graceful and non-graceful upgrades is the sequence of commands before and after the upgrade on a single card. For information on the proper sequence, see the " Graceful PXM Boot Upgrades from Release 3.0.20 and Later" section earlier in this appendix.

Note For PXM cards, this procedure applies only if you are upgrading from Release 3.0.20 or later. If you are upgrading from a release prior to Release 3.0.20, you need to follow the procedure in the " Upgrading PXM Boot Software from Releases Prior to 3.0.20" section earlier in this appendix.

Step 1

Copy the new boot software files for the PXM card to the switch as described in the " Copying Software Files to the Switch" section, which appears earlier in this appendix.

Step 2

Establish a CLI session with the switch using a user name with SERVICE_GP privileges or higher.

Step 3

To burn the new PXM boot code, enter the burnboot command as follows:

Replace <slot> with the slot number of a standalone PXM card, or a PXM card operating in standby mode. Replace <revision> with the software revision number to which you are upgrading. For example:

After you confirm the upgrade, the new boot code is burned into the PXM and the card is reset. Be patient, the card reset takes some time. You can enter the dspcds command to display the status of the PXM card. At first, the status may show that the card slot is empty or the card is rebooting. Reenter the command periodically to see the current status of the card. When the card status returns to active or standby, you are ready to continue.

Step 5

To confirm that the PXM card is now using the correct boot code, enter the dspcd <slot> command. The Boot FW Rev row in the display should show the new revision as shown in the following example:

After you confirm the upgrade to the PXM card, the boot software upgrade for that card is complete.

Loading the Runtime Upgrade Software

This section describes how to load the runtime upgrade software in preparation for running it. Production switches should have redundant cards installed, so that upgrades can occur without interrupting traffic. For graceful upgrades, the upgrade software is loaded on the standby card first, and then the control is switched to upgraded card so that the other card can be upgraded. The best way to assess the upgrade status of a card is to enter the dspcd <slot> command. For example:

The primary (Prim SW Rev), secondary (Sec SW Rev), and current (Cur SW Rev) software revision labels indicate the status of an upgrade. In this example, these numbers match because the runtime software upgrade has not started. (Note that the boot software has been upgraded as indicated by the Boot FW Rev label.)

The primary software revision indicates which revision a card will run if it becomes active, and the secondary revision indicates an alternate revision that the card will use if the abortrev command is entered. (For more information on aborting an upgrade, see the " Aborting a Runtime Software Upgrade" section later in this appendix.) The current software revision represents the software the active card is using.

The normal sequence of commands for a runtime software upgrade is loadrev, runrev, and commitrev. Table A-2 shows how the software revision levels change during a graceful runtime software upgrade.

Table A-2 Software Versions Reported During Graceful Upgrades
Software Revision		Before Upgrade		After loadrev		After runrev		After commitrev
	MGX 8850	Slot 7	Slot 8	Slot 7	Slot 8	Slot 7	Slot 8	Slot 7	Slot 8
	MGX 8830	Slot 1	Slot 2	Slot 1	Slot2	Slot 1	Slot 2	Slot 1	Slot 2
		Active	Standby	Active	Standby	Standby	Active	Active	Standby
Primary		3.0(0)	3.0(0)	3.0(0)	3.0(0)	4.0(0.0)	4.0(0.0)	4.0(0.0)	4.0(0.0)
Secondary		3.0(0.0)	3.0(0.0)	4.0(0.0)	4.0(0.0)	3.0(0.0)	3.0(0.0)	4.0(0.0)	4.0(0.0)
Current		3.0(0.0)	3.0(0.0)	3.0(0.0)	4.0(0.0)	4.0(0.0)	4.0(0.0)	4.0(0.0)	4.0(0.0)

For non-graceful upgrades, the load process defines the software version to which the switch is about to be upgraded. Table A-3 shows how the revision levels change during a non-graceful upgrade.

Table A-3 Software Versions Reported During Non-Graceful Upgrades
Software Revision	Before Upgrade	After loadrev	After runrev	After commitrev
Primary	3.0(0.0)	3.0(0.0)	4.0(0.0)	4.0(0.0)
Secondary	3.0(0.0)	4.0(0.0)	3.0(0.0)	4.0(0.0)
Current	3.0(0.0)	3.0(0.0)	4.0(0.0)	4.0(0.0)

If you are performing a graceful upgrade, use the quickstart procedure described in the " Graceful PXM and Service Module Runtime Software Upgrades" section earlier in this appendix. The following procedure provides detailed information on the load task within the quickstart procedure.

Step 1

To load the upgrade runtime software version on a PXM card or service module, enter the following command:

Replace <slot> with the card slot number for the card to be upgraded, and replace <revision> with the software version number for the update. For graceful upgrades, you can specify either the active or the standby card. The switch software will automatically load the upgrade software on the standby card when it is installed. The following example shows how to enter this command:

After you enter the loadrev command, the standby card comes up in the standby-U state.

Step 2

When prompted to confirm the command, type y and press Return to continue.

Step 3

To verify that the load command was processed correctly, enter the dspcd <slot> command and check the status of the software revision levels. You can also view the revision levels with the dsprevs command.

Note In a standalone configuration, the switch does not start the upgraded software until the runrev command is entered. In a redundant configuration, the switch starts the upgraded software on the standby card. The standby card does not become active until the runrev command is entered.

Starting the Upgrade Software

After you load the runtime upgrade software for a PXM or service module, enter the runrev command to start using the software. The version levels for graceful and non-graceful upgrades change as shown earlier in Table A-2 and Table A-3. The following procedure describes how to start the upgrade software.

Step 1

To start using the new runtime software version on a PXM card or service module card, enter the following command:

Replace <slot> with the card slot number, and replace <revision> with the software version number specified with the loadrev command. For graceful upgrades, you can specify either the active or the standby card. The switch software will automatically run the upgrade software on the standby card when it is installed. The following example shows how to enter this command:

The active card is reset, and the former standby card comes up in the active-U state.

Step 2

When prompted to confirm the command, type y and press Return to continue.

Step 3

Step 4

When the former active card comes up in the standby-U state, enter the commitrev command to commit to that software version. This step is optional.

After the runrev command is entered, the switch starts running the new software revision. The secondary software revision shows that a previous revision is still available. Whenever the secondary software revision is different from the primary and current software revisions, you can revert back to the secondary software revision as described in the " Aborting a Runtime Software Upgrade" section later in this appendix.

Upgrading Boot Software on a Service Module

The upgrade procedure for the boot software on a single service module is the same for graceful and non-graceful upgrades. The difference between the graceful and non-graceful upgrades is the sequence of commands before and after the upgrade on a single card. For information on the proper sequence see the " Graceful Service Module Boot Software Upgrades" section or the " Non-Graceful Service Module Boot Software Upgrades" section, both of which appear earlier in this appendix.

Note The boot upgrade procedures in this section apply to the FRSM, AUSM, CESM, and VISM service modules.

Step 1

Copy the new boot software files for the service module to the switch as described in the " Copying Software Files to the Switch" section, which appears earlier in this appendix.

Step 2

Establish a CLI session with the switch using a user name with SERVICE_GP privileges or higher.

Step 3

To burn the new service module boot code, enter the burnboot command as follows:

Replace <slot> with the slot number of a standalone service module, or a service module card operating in standby mode. Replace <revision> with the software revision number to which you are upgrading. For example:

After you confirm the upgrade, the new boot code is burned into the service module and the card is reset. Be patient, the card reset takes some time. You can enter the dspcds command to display the status of the service module. At first, the status may show that the card slot is empty or the card is rebooting. Reenter the command periodically to see the current status of the card. When the card status returns to active or standby, you are ready to continue.

Step 5

To confirm that the service module is now using the correct boot code, enter the dspcd <slot> command. The Boot FW Rev row in the display should show the new revision as shown in the following example:

After you confirm the upgrade to the service module, the boot software upgrade for that card is complete.

Aborting a Runtime Software Upgrade

After upgrading PXM or service module runtime software, you can revert to the previously used version of software at any time, as long as you have not committed to the new software version with the commitrev command (which is described in the next section).

Keep the following in mind when you use the abortrev command to abort the new runtime software during an upgrade:

•

If you enter the abortrev command on a redundant card set after the loadrev command was entered, and while the cards are in the Loadrev Done-U state, only the standby card will be reset.

•

If you enter the abortrev command on a redundant card set after you entered the runrev command, while the cards are in the Runrev Done-U state, both the active and standby cards will be reset.

•

If you enter the abortrev command on a single card, after you entered the loadrev command and the card is in the Loadrev Done-U state, the card will not be reset.

•

If you enter the abortrev command on a single card, after you entered the runrev command and the card is in the Runrev Done-U state, will be reset.

To display the current state of the card, enter the dsprevs -sl command. The card state appears under the Rev Chg Status column. In the following example, the PXM cards in slot 7 and 8 are in the Loadrev Done-U state.

To revert to the previously used runtime software version, use the following procedure.

Step 1

Establish a configuration session using a user name with SERVICE_GP privileges or higher.

Step 2

To display the software revisions known to the switch, enter the dspcd <slot> command. (You can also view the revision levels with the dsprevs command.)

Replace slot with the slot number of the active card. To complete the next step, you need to know the secondary software revision shown in the display.

Note

If the primary and secondary software revisions are the same, there is no other revision level to revert back to.

Step 3

To abort use of the primary software revision and revert back to the secondary software revision, enter the following command:

Replace <slot> with the card slot number for the active card, and replace <revision> with the software version number for the secondary software revision.

Step 4

To verify that the standby card is running the previously used software version, enter the dspcd <slot> command to view the software version in use. You can also view the revision levels with the dsprevs command.

Committing to a Runtime Software Upgrade

•

Disables use of the abortrev command to revert back to the previously used version of software

Once you are sure that an upgrade is stable, you can use the commitrev command commit to that software version. Committing to the current software version prevents other administrators from inadvertently reverting to the previous version. You must also commit to the current software version before you can upgrade to another software version.

To commit to the currently running runtime software version, use the following procedure.

Step 1

Establish a configuration session using a user name with SERVICE_GP privileges or higher.

Check the dspcd command report to see if the same software revision is listed for the Primary Software Revision (Prim SW Rev), Secondary Software Revision (Sec SW Rev), and Current Software Revision (Curr SW Rev).

If all version numbers are identical, the runtime software can be upgraded. There is no need to commit to the current software revision.

Replace <slot> with the card slot number for the active card, and replace <revision> with the software version number for the currently used software version. To display the software version number, use the dspcd <slot> command to view the software version in use. You can also view the revision levels with the dsprevs command.

Note

Cisco Systems recommends that you avoid configuration changes until after you have run the commitrev or abortrev commands.

Saving The Current Software Configuration on your Switch

To ensure that you can revert to a previous switch configuration after you have upgraded to a newer software release, Cisco recommends that you use the saveallcnf command before performing any upgrades on the switch.

Once you run the saveallcnf command, the switch saves the current configuration in a zip file in the C:CNF directory on the active PXM. The file name contains the name of the switch, the year, and a number that identifies the file. The most recent file is the first one listed in the CNF directory on PXM card.

Note

The CNF directory contains only the two most recently saved files. If there are two files in the CNF directory and you enter the saveallcnf command again, the current switch configuration file replaces the oldest configuration file.

Use the following procedure to save the switch current configuration in the CNF directory and view the contents of the CNF directory.

Step 1

At the active PXM, enter the saveallcnf command to save the current configuration of your switch to a zip file in the CNF directory on the active PXM.

Step 2

The saveallcnf command's screen output warns you that the process can be time consuming, and prompts you to answer whether or not you want to proceed. When prompted, enter y, and press Enter.

Note

After you enter the saveallcnf command, it takes several minutes for the switch to save the current configuration. The saveallcnf command saves the configuration in the CNF directory of the active PXM.

Step 3

Once the switch has finished saving the current configuration, the screen output confirms that the configuration was saved to the CNF directory, and lists the files that were zipped, as shown in the following example.

Step 4

At the active PXM switch prompt, enter the cd C:CNF/ command to go to the CNF directory and verify that the file was saved.

Note Once you have saved a file to the CNF directory, Cisco recommends that you ftp this file to another storage media to ensure that it is not accidentally deleted from the CNF directory, in case the original file becomes corrupted.

Reverting to a Previous Switch Configuration

Once you have saved a configuration file with the saveallcnf command, you can revert back to that former configuration by entering the restoreallcnf -f <FILENAME> command. Replace <FILENAME> with the name of the saved switch configuration file you want to revert to, as shown in the following example:

Note The restoreallcnf command works only if you enter the saveallcnf command while the switch was running the software configuration you want to revert to.

Installing SCT Files

The following procedure describes in detail how to install SCT files onto your network through the CLI.

Step 1

FTP the new SCT file to the C:SCT/TEMP folder, as described in the " Copying Software Files to the Switch" section earlier in this appendix.

Step 3

At the PXM prompt, Enter the dspsctchksum <pathname> command to retrieve the checksum of the SCT file you want to apply to the card. Replace <pathname> with C:SCT/TEMP/<SCT_name>, as shown in the example that follows.

Step 4

Enter the addsct command to move the SCT file to the F:/SCT/<card_name> directory.

You must enter this command once for each new SCT, or for each new major and minor version of a pre-existing SCT.

Table A-4 addsct Command Parameters
Option	Description
card type	Identifies the type of card the SCT runs on. The possible cards are AXSM, AXSME, AXSM-XG, PXM (for PXM1E only), or HSFR. Note MGX 8850 (PXM1E) and MGX 8830 switches support only PXM (for PXM1E).
sct type	Determines whether the SCT is a port SCT or a card SCT.
sct id	Number between 1 and 65335 which identifies an SCT.
major ver	Major version number of a file. This number changes when a new parameter is added to a MIB. Only Cisco can generate a new major version of a file.
checksum	SCT identification number that comes from Cisco and is published in the release notes. The checksum number can be from 1 to 132 characters, but cannot included space characters.

Step 5

Enter the cd F:SCT/<card_name> command to change to the directory to which you added the new SCT file in Step 4. In the following example, the user moves into the PXM directory.

Step 6

Enter the ls command to list all the files in the F:SCT/<card_name> directory, and verify that the new SCT file is there.

Step 7

Enter the cnfsct <sctID> command to apply the new SCT to the appropriate card. Replace <sctID> with the SCT file ID number. In the following example, the SCT with the ID 5 is applied to the PXM1E card.

Step 8

Enter the dspscts command to ensure that the latest SCT version was registered on your network.

The status of the SCT would be marked as "failed" if the file does not exist or does not match the major and minor versions.

Upgrade Procedures for RPM-PR and RPM-XF Cards

The following sections describe how to upgrade boot and runtime software on RPM-PR and RPM-XF cards.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

Upgrading RPM Boot Software

At the factory, a boot file is installed in the bootflash on the RPM card and is used to boot the card. The runtime software is updated more frequently than the boot software. However, the boot software is updated occasionally. When you are updating runtime software, check the release notes that accompany the runtime software to see if a boot software upgrade is required.

The boot software is stored in bootflash memory on the RPM card. To manage the software in bootflash, you access it as if it were a hard disk. For example, in copy and delete file commands, files are identified as bootflash:filename (which is similar to e:filename).

Note Although you can display directory contents with the dir bootflash: command, the show flash: command provides more detail. Although bootflash and flash are separate entities on other Cisco Routers, both terms refer to the same entity on the RPM.

In the example above, the numbers in the left column indicate the order in which the RPM will try to load software. The second column shows that the first two files are marked for deletion (D). The last column lists the names of the files stored in bootflash.

•

If the BOOTLDR variable is set and the RPM card is reset, the RPM card attempts to load the boot software specified.

•

If the BOOTLDR variable is not set and the RPM card is reset, the RPM card tries to load the first bootable image in bootflash. The first bootable image is the image that appears first in the show flash: command display, and this is usually the oldest file in bootflash. Therefore, if you do not use the BOOTLDR variable, the bootflash contents must be reorganized each time you upgrade boot software.

•

The RPM card will not attempt to boot from automatic configuration files, which are named using the format auto_config_slotnn, where nn represents a slot in which an RPM card is installed.

•

If the image that RPM tries to load does not load, you can reset the RPM from the active PXM card using the resetcd <slot> command.

•

Files are not removed from bootflash until the squeeze flash: command is entered. If you delete a file and do not enter squeeze flash:, the RPM card will still attempt to boot from the first image it finds, whether it is marked for deletion or not.

If you do need to upgrade the boot software, you can copy the new boot file to the PXM disk, and then copy it to the bootflash. The following procedure describes how to upgrade the boot software.

Step 1

Copy the new boot software file for the RPM card to the switch (E:RPM) as described in the " Copying Software Files to the Switch" section earlier in this appendix.

The switch displays the Cisco IOS prompt for the router on the RPM card. From this point on, all commands are Cisco IOS commands.

Note

This procedure assumes that you are familiar with Cisco IOS commands (which is a topic that is beyond the scope of this book). This procedure details only those commands that are unique to setting up RPM on the switch. For general Cisco IOS commands, examples are given to show how to complete the task.

Step 5

To verify router access to the PXM hard disk and display the boot file name, enter dir e: command.

Step 6

To display the files in the bootflash, enter the show flash: command.

Step 7

To copy new boot software to the bootflash, enter the copy command.

Tip

When prompted for the destination filename, press enter to use the source filename shown in the prompt. To change the destination filename, type a new filename after the prompt.

Step 8

To verify that the file was copied, enter the show flash: command.

Step 9

To set the BOOTLDR variable to specify the new boot software, complete the following steps:

Step 10

To reorganize the bootflash so that the new boot software is loaded first when the BOOTLDR variable is not set, complete the following steps:

Because all files that precede the new boot image in bootflash have to be deleted, copy bootflash files you want to save to the PXM hard disk using the following command.

Mark all the files that precede the new boot image in bootflash using the del bootflash: command as shown in the following example:

Tip

To unmark a bootflash file so that it won't be deleted when the squeeze flash: command is run, enter the undelete <number> command, where number is the file number displayed in the left-most column of the show flash: command display.

To delete all files that are marked for deletion from bootflash, enter the squeeze flash: command as shown in the following example:

Copy any previously saved bootflash files you want to use from the PXM hard disk using the following command:

You might want to copy previously saved configuration files back to bootflash, or you might want to copy an older boot image to be used if the newer version becomes corrupt.

Enter the show flash: command to verify that the bootflash files are as you want them. The preferred boot software should appear first in the list.

Tip

If the show flash: command does not display a bootable image, copy a bootable image to bootflash as described earlier in this procedure. You can continue to manage the bootflash, even when there are no files in bootflash, until the router is restarted.

Step 11

When you are sure the bootflash is ready for use, you can enter the reload command to restart the RPM card, or you can upgrade the runtime software as described in the next section.

Tip

If the bootflash contains bootable images and the sequence is such that the card will not start, you can enter rommon mode and load the bootable image. To get into rommon mode, establish a console connection to the RPM card, reset the RPM card using the resetcd <slot> command from the active PXM card, then quickly enter the CTRL-[, Break sequence at the RPM console. The command to send a Break depends on the computer platform and software you are using. It may take a couple of attempts to successfully get into rommon mode. When you are in rommon mode, the RPM card displays the rommon 1 > prompt.

Once in rommon mode, you can enter the dir bootflash: command to display the images in bootflash. To boot one of the images, enter a boot command using the following format: boot bootflash:filename.

Upgrading RPM Runtime Software

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

Cisco Systems recommends that you configure the RPM card to load from the E:RPM directory on the PXM hard disk. Note that images will load much faster from bootflash, but if you are using multiple RPM cards, it takes longer to complete an upgrade because the runtime software must be copied to each RPM card's bootflash instead of to a single location.

At startup, the RPM card attempts to load the software in the order listed in the startup-config file. The following example shows an excerpt from a startup-config file:

In the startup-config file example, the RPM card attempts to load the runtime software from the PXM card (e:rpm-js-mz_122-4.T) first, and if that fails, it attempts to load the image copy stored in bootflash. This configuration takes longer to upgrade, but it assures the card can reboot if someone accidentally removes the file on the PXM hard disk.

To configure the RPM to load upgraded runtime software from the PXM hard disk, you need to do the following:

•

Update the boot system variable in the router startup-config file to load the new file.

RPM cards can be configured for 1:N redundancy as well as for non-redundant configurations. The procedures for both types of configuration are in the sections that follow.

Tip

To simplify runtime software updates, copy the runtime file in the E:RPM directory and rename it to a generic name such as rpm-js-mz. The production runtime filenames have version numbers appended to them, but you can change this. This approach allows you to perform future upgrades by copying the file to the hard disk, renaming a copy of the file to your generic name, and resetting each card. The approach eliminates the need to reconfigure Cisco IOS commands on each card to recognize the new filename.

Upgrading RPM Runtime Software for 1:N Redundancy

Redundancy must be established before you use the procedure in this section. If redundancy has not been established, upgrade each RPM card using the procedure in the next section, "Upgrading Without Redundancy".

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

To upgrade the RPM runtime software for 1:N redundancy, use the following procedure.

Step 1

Copy the new runtime software file for the RPM card to the switch (E:RPM) as described in the " Copying Software Files to the Switch" section earlier in this appendix.

Step 2

If you are using a generic filename for your runtime images, copy the file on the PXM hard disk and rename the copy. For example:

Step 4

If your RPM is already configured to use a file with a generic name, skip to Step 13.

The switch displays the Cisco IOS prompt for the router on the RPM card. From this point on, all commands are Cisco IOS commands.

Note

Step 7

Display the startup runtime software filename by entering the show bootvar command.

In the example above, the startup runtime software file is c:rpm-js-mz_122-4.T, and it has a version number attached to it. Another way to view the boot list is to enter the show startup-config command and look for the boot system commands.

Step 9

If you need to change the boot system filenames, remove the existing boot list using the boot system command as follows:

Step 10

Create a new boot list by entering one or more boot system commands as follows:

Replace the filename variable with the name of the new runtime file that was previously transferred to the E:RPM directory on the switch. For example:

If you want to enter additional boot system commands, enter them in the order in which you want the RPM card to use them. The following example adds a statement to load from bootflash if the runtime file is not found on the PXM hard disk:

Note

Before the RPM card can load runtime software from bootflash, you must copy the runtime software to the bootflash. The procedure for copying files from the PXM hard disk to bootflash is described in the previous section.

Step 12

To verify the change, enter the show bootvar or show run commands.

Step 14

Switch to the secondary card using the switchredcd command as follows:

Replace <fromSlot> with the slot number of the primary card. Replace <toSlot> with the slot number of the secondary card.

This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded software.

Step 15

Switch back to the primary card using the switchredcd command as follows:

Replace <fromSlot> with the slot number of the secondary card. Replace <toSlot> with the slot number of the primary card.

This step makes the primary card active and resets the secondary RPM card. When the reset is complete, the secondary card is ready to run the upgraded software.

Step 16

To verify that the router reboot is complete, enter the dspcds or dspcd <slot> commands. The reboot is complete when the card state displays as Active. Another way to verify router operation is to enter the cc slot command. If you can access the router from the switch prompt, the router reboot is complete.

Step 17

If there are other primary cards with redundant (secondary) cards, repeat this procedure for each primary card.

Upgrading RPM Runtime Software for Non-Redundant Cards

To upgrade the RPM runtime software for nonredundant cards, use the following procedure.

Note In this document, the general term "RPM" refers to RPM-PR and RPM-XF cards. If a step or procedure is specific to only one of the RPM cards, it will be called out in the text.

Step 1

Copy the new runtime software file for the RPM card to the switch (E:RPM) as described in the " Copying Software Files to the Switch" section earlier in this appendix.

Step 2

If you are using a generic filename for your runtime images, copy the file on the PXM hard disk and rename the copy. For example:

Step 4

If your RPM is already configured to use a file with a generic name, skip to Step 13.

The switch displays the Cisco IOS prompt for the router on the RPM card. From this point on, all commands are Cisco IOS commands.

Note

Step 6

Configure the RPM card to store its configuration on the PXM hard disk by entering the following command:

Step 8

Display the startup runtime software filename by entering the show bootvar command.

Step 10

If you need to change the boot system filenames, remove the existing boot list using the boot system command as follows:

Step 11

Create a new boot list by entering one or more boot system commands as follows:

Replace the filename variable with the name of the new runtime file that was previously transferred to the E:RPM directory on the switch. For example:

Note

Step 13

To verify the change, enter the show bootvar or show run commands.

Upgrading SCT Files

Once you have installed the SCT files on your network, you can enter the cnfsct command to overwrite them with new files with the same major version. To replace an SCT file with a new file of the same major version, use the following procedure:

Step 1

FTP the new SCT file to the C:SCT/TEMP folder, as described in the " Copying Software Files to the Switch" section earlier in this appendix.

Step 3

At the active PXM switch prompt, enter the command dspsctchksum <absolute path of file> command to display the checksum number of the SCT you want to upgrade to. Replace <absolute path of file> with the path of the latest SCT file.

Step 4

Enter the cnfsct <options> command at the active PXM switch prompt.

In the following example, the user overwrites and old PXM1E card SCT with a new one:

Table A-5 cnfsct Command Parameters
Parameter	Description
card type	Identifies the type of card the SCT runs on. The possible cards are AXSM, AXSME, PXM (for PXM1E only), or HSFR. Note MGX 8850 (PXM1E) and MGX 8830 switches support only PXM (for PXM1E).
SCT type	Determines whether the SCT is a port SCT or a card SCT.
SCT id	Number between 1 and 65335 which identifies an SCT.
major ver	Major version number of a file. This number changes when a new parameter is added to a MIB. Only Cisco can generate a new major version of a file.
checksum	SCT identification number that comes from Cisco and is published in the release notes. The checksum number can be from 1 to 132 characters, but cannot included space characters.
description	Describes the SCT file.

Step 5

Enter the dspscts command to ensure that the latest SCT version was registered on your network. The status of the SCT would be marked as "failed" if the file does not exist or does not match the major and minor versions.

Troubleshooting Upgrade Problems

Table A-6 lists symptoms of upgrade problems and suggestion on how to correct them.

Tip

When troubleshooting problems on standby PXM cards or cards that do not start up to the active state, establish communications through the boot IP address or through the console port.

Table A-6 Troubleshooting Upgrade Problems
Primary Symptom	Secondary Symptom	Suggested Action
loadrev or runrev command fails	—	The loadrev command is blocked when a previous upgrade has not been completed with the commitrev command. Enter the dsprevs command to locate the cards that are still being upgraded. For more information on a particular card, enter the dspcd <slot> command and verify that the current, primary, and secondary software revision numbers are identical. If the numbers are not identical, issue the commitrev <slot> command. Enter the dspcds and verify that the standby card is in standby state. Also look for a -U or -D in the dspcds command display, which indicates that the card is in the process of being upgraded (-U) or downgraded (-D). The loadrev and runrev commands are blocked whenever the standby card is not in standby state or an upgrade or downgrade is in progress.
After restart, the switch stops displaying messages and does not display a prompt.	—	Press Return to display the prompt.
After restart, switch stops at backup boot prompt: pxm1ebkup> or pxm45bkup>. (Use a console port connection to see this. If you missed the startup messages, enter the reboot command.)	The switch displays the following message: Can not open file C:/version.	The version file is probably missing. Create the version file as described in the " Initializing the Switch" section in Chapter 3, "Configuring General Switch Features."
	The switch displays the following message: Unable to determine size of C:/FW/filename.	The version recorded in the version file doesn't match software installed in the C:FW directory. Enter the sysVersionShow command to see which file the PXM is trying to load. Verify that the correct software is installed on the switch using the commands described in the " Browsing the File System in Backup Boot Mode" section in "PXM Backup Boot Procedures." If the runtime software is not on the hard disk, copy it to the hard disk as described in the " Transferring Software Files to and from the Switch" section in "PXM Backup Boot Procedures." If a typo is entered when initializing the switch, re-enter the sysVersionSet command, enter the sysVersionShow command to verify the correct setting, and then reboot the switch with the reboot command.
	The switch displays the following message: Please run sysDiskCfgCreate.	The hard disk is formatted, but not ready for operation. Enter the sysDiskCfgCreate command. For more information, see the " Initializing the PXM Hard Disk" section in "PXM Backup Boot Procedures."
Standby PXM continually reboots. You can view the rebooting process through the console port.	—	The active PXM card cannot bring up the standby card. The following procedure assumes that this card has just been installed in the switch and that you have given the standby card sufficient time to synchronize with the Active card. Interrupt the boot cycle by pressing Return. Timing is important, so you might have to press Return multiple times. When the pxm1ebkup or pxm45bkup prompt appears, immediately enter the sysPxmRemove command to prevent the Active card from rebooting the standby card while you are working on it. Enter the sysChangeEnet command and verify that the inet on ethernet (e) and gateway inet (g) values are set to the boot and gateway IP address set with the bootChange command on the active card. Also, verify that the boot device is set to lnPci. The sysChangeEnet command works like the bootChange command, which is described in the " Setting the Boot IP Address" section in Chapter 3, "Configuring General Switch Features." Enter the sysClrallcnf command to clear any configuration data on the standby card set. This command does not clear the boot IP address set with the sysChangeEnet command.
After restart, the switch stops at shell prompt: pxm1e> or pxm45>.	—	If the Return key is pressed at one of the auto-boot prompts during start up, the switch stops in shell mode. Enter the reboot command to restart the switch and avoid pressing the Return key.
The non-active PXM will not transition out of the active init state.	One or more non-standby PXM cards are in a transitional state.	A non-standby PXM card is a standalone PXM card or the card within a redundant PXM pair that is trying to go active. When a non-standby PXM card is in a transitional state, such as the init state, the PXM cannot transition to the standby state. When all non-standby cards have reached a steady (non-transitional) state, the PXM will transition to a steady state. Steady states are as follows: active ready, failed, mismatch, empty, empty reserved, and standby ready. Note When either card in a redundant PXM pair is active, that PXM pair is not preventing the standby PXM from transitioning to a steady state. The standby PXM is only affected when both cards in a redundant pair are in a transitional state.

Table Of Contents

2