Table Of Contents

Loading and Upgrading VXSM Code Images

Initial Considerations

Loading a VXSM Image for the First Time

Upgrade Procedure

Interrupted Procedure Recovery

Image Filenames and Revision Numbers

CALEA and Non-CALEA Image Numbering

Loading and Upgrading VXSM Code Images

---

The chapter describes the procedure for setting up the image on a Cisco VXSM for the first time and for upgrading VXSM cards from an earlier software image.

Initial Considerations

To upgrade the image on a VXSM card while preserving the call processing service:

1. The VXSM card must be one of a redundant pair of VXSM cards (in adjacent slots).

2. Only one pair of VXSM cards can be upgraded at a time.

3. After the upgrade procedure starts, no configuration changes can occur until after the upgrade is complete.

4. VXSM downgrades are not supported.

5. Only those upgrade paths (marked with X) shown in Table 7-1 are allowed. Only like-to-like images are allowed. This table applies to single card upgrades and redundant card pairs upgrades.

Table 7-1 Allowable VXSM Image Upgrades

To Version
		Non-CALEA H.248	Non-CALEA TGCP	Non-CALEA MGCP	CALEA TGCP	CALEA MGCP
From Version	Non-CALEA H.248	X
	Non-CALEA TGCP		X
	Non-CALEA MGCP			X
	CALEA, TGCP				X
	CALEA, MGCP					X

6. Before the upgrade procedure can start, the new VXSM image must reside on the hard disk of the PXM cards. Browse the VXSM disk to ascertain whether or not the image exists. At the PXM prompt, the PXM card responds to UNIX-like commands (for example, cd for change directory; ls for list short format) to allow the user to inspect the contents of the disk.

If the image does not exist, it must be downloaded from a workstation using the FTP protocol (refer to the PXM-45 Configuration Guide for more detailed information).

Check the release notes to see if the VXSM upgrade also requires an upgrade of the boot code image in addition to the runtime image. If it does, the boot code image must also reside on the PXM's hard disk.

---

Warning BEFORE YOU PERFORM THE PROCEDURES DESCRIBED IN THIS CHAPTER, READ ALL OF THIS WARNING!

Some commands for loading or upgrading boot and runtime images take several minutes to execute completely. If you resets or disturb the VXSM card during a loading or upgrading process, the card can easily be damaged to the extent that it must be returned to the factory for repair.

The reappearance of the command prompt after a command is entered does not indicate that the image load or upgrade is complete.

After the execution of the burnboot, clrsmcnf, loadrev, or setrev commands, you must execute either a dspcds or dsprev command periodically to verify that the state of the VXSM card being loaded or upgraded is either Active, Standby, or Failed.

Only after the card enters Active, Standby, or Failed is it safe to go to the next step.

---

Loading a VXSM Image for the First Time

The procedure for loading images onto a VXSM card the first time the card is as follows.

---

Note All the commands in the following procedure are performed on the gateway's active PXM card. Check the command prompt to verify that you are logged into the PXM card.

---

---

Step 1 Telnet to the media gateway. Check that you have the PXM card prompt. If necessary, check the location of the VXSM cards by using the dspcds command.

Step 2 Check the release notes to see if the VXSM boot code image needs upgrading. If it does, use the burnboot command to burn the boot code onto the desired VXSM card (otherwise, skip to step 4).

burnboot <slot> <revision>

For revision, use the revision number of the boot code image to be loaded (see later in this chapter for 
information on revision numbers).

Step 3 Periodically check that the burnboot process has ended. To do this, use the dspcds or dsprev command on the PXM. When the state of the VXSM card is displayed as either Active, Standby, or Failed, proceed to the next step.

Step 4 Use the clrsmcnf command to the clear the VXSM card's configuration. The format of this command is:

clrsmcnf <slot-id> [all]

Step 5 Periodically check that the clrsmcnf process has ended. To do this, use the dspcds or dsprev command on the PXM. When the state of the VXSM card is displayed as either Active, Standby, or Failed, proceed to the next step.

---

Note If the -all parameter is used in the clrsmcnf command, the VXSM card will come up in the failed state. This is normal and is expected.

---

Step 6 Use the setrev command. This command loads a VXSM image with the specified call control protocol and a DSP image with the specified Codec Template. The format of this command is:

setrev <slot> <primary revision> [-ccp <CallControlProtocol>] [-co <CodecTemplateNumber>]

Specify the gateway control protocol as either H.248, TGCP, or MGCP as appropriate.

Specify the codec template number as either TGW/Wireline (default) or Cable as appropriate.

Step 7 Periodically check that the setrev process has ended. To do this use the dspcds or dsprev command on the PXM. When the state of the VXSM card is displayed as either Active, Standby, or Failed, proceed to the next step.

Step 8 Repeat steps 2 and 7 for any other VXSM cards that need to be brought up for the first time.

Step 9 Use the addred command to set up VXSM redundant pairs. The format of this command is:

addred <redprimaryslotnum><redstandbyslotnum><redtype>

Step 10 Switch to the VXSM cards. Use their commands to configure the cards as necessary and bring them into service.

---

Upgrade Procedure

To upgrade the VXSM cards, use the following steps. This procedure is for VXSM cards that are in service and provides a graceful upgrade in which call processing continues during the upgrade. This procedure can also be performed on one VXSM card, but the service is not preserved during the upgrade.

---

Warning While upgrading a VXSM software image, it is extremely important to allow the following upgrade process to proceed without external user intervention other than the upgrade procedure. This applies to both the primary and secondary VXSM cards being upgraded and the gateway's PXM cards, External intervention may cause the VXSM cards to come up in the Failed state.

In particular:
Do not reset VXSM or PXM cards manually or through commands such as resetcd or resetsys.
Do not save all MGX configuration with commands such as the saveallcnf command.
Do not toggle primary/secondary cards through commands such as switchredcd or delred.
Do not change the name of software image before or during the upgrade.
Do not change any configuration of active primary card during the upgrade.

This warning applies to the upgrade procedure through the completion of the commitrev command in Step 6 (see below).

If the upgrade procedure is interrupted for reasons outside the control of the user (for example, a power outage), see "Interrupted Procedure Recovery" below for instructions.

---

Telnet to the media gateway.

---

Note All the commands in the following upgrade procedure are performed on the gateway's active PXM card. Check the command prompt to verify that you are logged in to the PXM card.

---

---

Step 1 Determine which set of redundant VXSM cards is to be upgraded. Use the dspcds command if necessary to locate the slot numbers of the VXSM cards. Determine which VXSM card slot in the set is primary (active) and which is secondary (standby).

Step 2 Check the release notes to see if the VXSM boot code image needs upgrading. If it does, perform the following substeps a, b, c, and d; otherwise skip these steps and go to step 3.

a. use the burnboot command to burn the boot code onto the standby card.

burnboot <slot> <revision>

---

Note Make sure that the slot number in the burnboot command is that of the standby VXSM card.

---

For revision, use the revision number of the boot code image to be loaded (see later in this chapter for information on revision numbers).

b. Periodically check that the burnboot process has ended. To do this, use the dspcds or dsprev command on the PXM. When the state of the VXSM card is either Active, Standby, or Failed, proceed to the next step.

c. Use the switchredcd command to switch the states of the active and standby VXSM cards. The format of this command is:

switchredcd <fromslot><toslot>

The fromslot parameter is the slot number of the active card in the VXSM redundant pair. The toslot parameter is the slot number of the standby card in the VXSM redundant pair.

When this command is executed, the active card becomes the standby card and vice versa.

d. Use the burnboot command again to burn the boot code onto the new standby card.

---

Note Make sure that the slot number in the burnboot command is that of the new standby VXSM card.

---

e. Periodically check that the burnboot process has ended. To do this use the dspcds or dsprev command on the PXM. When the state of the VXSM card is displayed as either Active, Standby, or Failed, proceed to the next step.

f. Use the switchredcd command again to return the VXSM cards to their original states (active and standby).

After this command is executed, the originally active VXSM card is again active and the original standby card is again in standby. Both VXSM cards in the redundant pair have upgraded boot code with their original runtime code.

Step 3 Load the new runtime image onto the standby VXSM card using the loadrev command as follows:

loadrev <slot> <revision>

For slot, the user can enter either the slot number of the active or standby VXSM. PXM automatically selects the standby to load the new image. For revision, use the revision number of the image to be loaded (see later in this chapter for information on revision numbers).

Step 4 Periodically check that the loadrev process has ended. To do this, use the dspcds or dsprev command on the PXM. When the state of the VXSM card is displayed as either Active, Standby, or Failed, proceed to the next step.

Step 5 Use the runrev command to cause the active and standby cards to switch roles. This results is the new runtime image becoming the active image. The new image is also loaded onto the (now) standby card so that both cards are upgraded. The format of the runrev command is:

runrev <slot> <revision>

Step 6 Both VXSM cards in the redundant set have upgraded boot code images (if required) and runtime images. Use the commitrev command to finalize the upgrade procedure. This command removes the old images from the cards:

commitrev <slot> <revision>

---

Note If you suspect that an error occurred during the upgrade process, use to abortrev command to restore the images to their state before the upgrade was started.

---

---

Interrupted Procedure Recovery

If a VXSM software upgrade procedure is interrupted (for example, power outage), and both primary and secondary remain in Failed-U state, perform the following procedure:

---

Step 1 Execute the abortrev command:

abortrev <PrimarySlot> <NewImageRevision>

Step 2 If the primary VXSM becomes Failed/Active (out of Failed-U/Active), then execute the resetcd command:

resetcd <PrimarySlot>

Step 3 If the secondary VXSM becomes Failed/Active (out of Failed-U/Active), execute the resetcd command:

resetcd <SecondarySlot>

Both primary and secondary VXSM cards should have their original software image and original DB.

---

Image Filenames and Revision Numbers

Images have both a filename and a revision number.

Filenames

Filenames are used to download the image to the PXM hard disk and when browsing the disc to examine its contents. Filenames have the following formats.

cardtype_version-element{_platform}.fw

where version-element is composed of:

major-release.minor-release.maintenance.patch-phase

An example of a filename for VXSM 5.0.02 boot code is:

vxsm_005.000.002.200_bt.fw

An example of a filename for VXSM 5.0.02 runtime code is:

vxsm_005.000.002.202.fw

Revision Numbers

Revision numbers are used to identify images in the burnboot, loadrev, runrev, commitrev, and abortrev commands. Revision numbers are derived from the filenames by:

•Using only the version-element portion of the filename (card type, platform, and the.fw extension are not used).

•Removing the leading zeroes from the major/minor/maintenance/patch numbers.

•Enclosing the maintenance.patch number in parentheses.

•Adding a phase identifier to the end.

Thus, revision numbers appear in the general format:

major-release.minor-release(maintenance.patch)phase

Using this process, the filename vxsm_005.000.002.202.fw converts to the version number of

5.0(2.202)

---

Note In this example, the phase identifier is omitted because the image is released. Phase identifiers are used only for images that are still under development.

---

---

Note For details on upgrading images, filenames, and revision numbers, refer to the Cisco MGX (PXM45/PXME1), MGX 9850, MGX 8830, and MGX 8880 Command Reference under the loadrev description.

---

CALEA and Non-CALEA Image Numbering

A numbering relationship between a VXSM CALEA image and its corresponding non-CALEA image applies to filenames and version numbers.

The relationship is as follows:

The value of the minor-release field for a non-CALEA release has 50 added to it to signify the corresponding CALEA release.

For example, if the filename and revision number for a non-CALEA VXSM release are:

filename = vxsm_005.000.002.202.fw

revision number = 5.0(2.202)

The filename and revision number for the corresponding CALEA release is:

filename = vxsm_005.050.002.202.fw

revision number = 5.50(2.202)