cc/td/doc/product/wanbu/mgx8220/rel40
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Firmware Upgrade
and Downgrade Procedures

Firmware Upgrade
and Downgrade Procedures

Introduction

This document describes the procedures for upgrading or downgrading from one MGX 8220 firmware revision to another firmware revision. Both the upgrading and downgrading of ASC and Service Module firmware and the upgrading and downgrading of Backup Boot Code are included.

Each procedure is characterized by:

To cover all the possible combinations, there are 25 specific procedures, all of which are described in this document. To determine which procedure to use in a particular situation, the user looks up a procedure number in one of a set of 8 tables (provided below) and follows that procedure described in the body of this document. The tables are identified as A through H.

The procedures themselves involve issuing a sequence of commands using the shelf Command Line Interface (CLI).

Definition of terms and descriptions of commands involved in the procedures are provided at the end of this document.

Using the Procedure Tables

Each of the 8 tables includes the procedure for a particular type of upgrade or downgrade and for a particular core card set. For example, one table shows the procedures for a graceful upgrade on a one core card set, another table shows the procedures of a standard downgrade for a two core card set.

The tables, A through H, are as follows:

Each row in a table corresponds to a particular "from" release and each column in a table corresponds to a particular "to" release.

By looking down to the appropriate row and across to the appropriate column, the cell (or position) in the table indicates the number of the procedure to be used. A blank position in a table indicates that no procedure supported for that particular upgrade or downgrade.

A

Std. Upgrade
1 Core Card Set

B

Std. Upgrade
2 Core Card Set

C

Std. Downgrade
1 Core Card Set

D

Std. Downgrade
2 Core Card Set

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

From Rel 2.x

1

1

5

3

3

6

2

4

From Rel. 3.x

1

5

3

6

2

2

4

4

From Rel. 4.x

9

10

7

7

11

8

8

12

E

Graceful. Upgrade
1 Core Card Set

F

Graceful Upgrade
2 Core Card Set

G

Graceful Downgrade
1 Core Card Set

H

Graceful Downgrade
2 Core Card Set

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

To 2.x

To 3.x

To 4.x

From Rel 2.x

13

15

15

14

16

From Rel. 3.x

17

19

21

18

20

From Rel. 4.x

22

23

24

25

Finding the right procedure

To determine which procedure to use:

    1. Determine whether the desired procedure is an upgrade or a downgrade and whether the MGX has a one core card set or a two core card set.

    Using this information look at the table headings to determine which table to use.

    For example, to perform a graceful upgrade on a two core card set, use table F.

    2. Look down the left side of the table to select the row for the appropriate "from" release.

    3. Look across the top of the table to select the column for the appropriate "to" release.

    4. Read the procedure number from the selected cell (position) in the table.

    5. Go the appropriate procedure in the section titled "Standard Upgrade and Downgrade Procedures" or "Graceful Upgrade and Downgrade Procedures"

    6. Perform the procedure.

Standard Upgrade and Downgrade Procedures

These procedures must be performed at a UNIX workstation which has an operational data path to the MGX 8220. The work station must be able to send MGX 8220 CLI commands and UNIX Trivial File Transfer Protocol (TFTP) downloads.

A StrataView Plus workstation attached to a BPX is one method in which MGX 8220 commands and TFTP commands can be executed on the MGS 8220 via an inband channel. The workstation can also be attached to the MGX 8220 through an Ethernet LAN or through a TCP/IP connection on the control port on the ASC.

Procedure 1, Std. upgrade, 1 core card set.

(used for 1.2.x to 2.y , 2.2.x to 3.y, and 3.3.x to 3.y )

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all primary and stand-alone SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs, set where in flash memory the firmware file will be written:

    7. For all primary and stand-alone SMs:

Procedure 2, Std. downgrade, 1 core card set.

(used for 1.2.y to 2.x , 2.3.y to 2.x, and 3.3.y to 3.x )

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Execute the dspadrxlat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    3. For all primary and stand-alone SMs:

    4. For all SMs:

    5. For all SMs:

    6. For all primary and stand-alone SMs:

Procedure 3, Std. upgrade, 2 core card set.

(used for 1.2.x to 2.y , 2.2.x to 3.x, and 3.3.x to 3.y )

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all stand-alone and primary SMs.

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs, set where in flash memory the firmware file will be written:

    7. For all primary and stand-alone SMs:

Procedure 4, Std. downgrade, 2 core card set.

(used for 1.2.y to 2.x , 2.3.y to 2.x, and 3.3.y to 3.x )

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    3. For all stand-alone and primary SMs.

    4. For all SMs, set where in flash memory the boot code file will be written:

    5. For all SMs, set where in flash memory the firmware file will be written:

    6. For all primary and stand-alone SMs:

Procedure 5, Std. upgrade, 1 core card set.

(used for 1.2.x to 4.y , 2.3.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all stand-alone and primary SMs.

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs:

    7. For all primary and stand-alone SMs:

Procedure 6, Std. upgrade, 2 core card set.

(used for 1.2.x to 4.y , 2.3.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all stand-alone and primary SMs.

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs

    7. For all primary and stand-alone SMs:

Procedure 7, Std. downgrade, 1 core card set.

(used for 1.4.y to 2.x , 2.4.y to 3.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    3. For all stand-alone and primary SMs.

    4. For all SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs:

Procedure 8, Std. downgrade, 2 core card set.

(used for 1.4.y to 2.x , 2.4.y to 3.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    3. For all stand-alone and primary SMs.

    4. For all SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs:

Procedure 9, Std. upgrade, 1 core card set.

(used for 1.4.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all stand-alone and primary SMs.

    5. For all SMs:

    6. For all SMs:

Procedure 10, Std. upgrade, 2 core card set.

(used for 1.4.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all stand-alone and primary SMs.

    5. For all SMs:

    6. For all SMs

    7. For all primary and stand-alone SMs:

Procedure 11, Std. upgrade, 1 core card set.

(used for 1.4.y to 4.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all stand-alone and primary SMs.

    6. For all SMs,

    7. For all primary and stand-alone SMs:

Procedure 12, Std. downgrade, 2 core card set.

(used for 1.4.y to 4.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all stand-alone and primary SMs.

    6. For all SMs,

    7. For all SMs

    8. For all primary and stand-alone SMs perform the dsptotals commands This step is to examine the number of lines, ports, and channels after the upgrade or downgrade. The values can be compared to those before the download and it can be established that the configuration has remained the same. Restore the ASC and SM configurations if necessary. Restore the ASC and SM configurations if necessary.

Graceful Upgrade and Downgrade Procedures

These procedures must be performed at a UNIX workstation which has an operating data path to the MGX 8220. The work station must be able to send MGX 8220 CLI commands and UNIX Trivial File Transfer Protocol (TFTP) downloads.

A StrataView Plus workstation attached to a BPX is one method in which MGX 8220 commands and TFTP commands can be executed on the MGS 8220 via an inband channel. The workstation can also be attached to the MGX 8220 through an Ethernet LAN or through a TCP/IP connection on the control port on the ASC.

Procedure 13, Graceful upgrade, 1 core card set (SM only).

(used for 1.2.x to 2.y )

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all SMs:

    5. For all SMs:

    6. For all SMs:

    7. For all SMs:

    8. For all SMs:

Procedure 14, Graceful downgrade, 1 core card set (SM only).

(used for 1.2.y to 2.x )

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all SMs:

    6. For all SMs, set where in flash memory the firmware file will be written

    7. For all SMs:

Procedure 15. Graceful upgrade, 2 core card set.

(used for 1.2.x to 2.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs, set where in flash memory the firmware file will be written:

    7. For all SMs:

    8. For all SMs:

Procedure 16. Graceful downgrade, 2 core card set.

(used for 1.2.x to 2.y)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all SMs:

    6. For all SMs, set where in flash memory the boot code file will be written

    7. For all SMs, set where in flash memory the firmware file will be written

    8. For all SMs:

    9. For all SMs:

Procedure 17, Graceful upgrade, 1 core card set (SM only).

(used for 1.3.x to 3.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. For all primary and stand-alone SMs
    Perform the dsptotals command. The configuration of the shelf should not be changed during the upgrade or downgrade process. This step is to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

    4. For all SMs, set where in flash memory the firmware file will be written:

    5. For all SMs:

    6. For all stand-alone SMs:

    7. For all primary SMs in all redundance groups:

    8. For all primary and stand-alone SMs in all redundancy groups:

Procedure 18, Graceful downgrade, 1 core card set (SM only).

(used for 1.3.y to 3.x )

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. For all primary and stand-alone SMs
    Perform the dsptotals command. The configuration of the shelf should not be changed during the upgrade or downgrade process. This step is to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

    5. For all SMs, set where in flash memory the firmware file will be written

    6. For all SMs

    7. For all stand-alone SMs:

    8. For all primary SMs in all redundancy groups:

    9. For all primary and stand-alone SMs in all redundancy group:

Procedure 19. Graceful upgrade, 2 core card set.

(used for 1.3.x to 3.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs, set where in flash memory the firmware file will be written:

    7. For all stand-alone SMs:

    8. For all primary SMs in all redundancy groups:

    9. For all SMs:

Procedure 20. Graceful upgrade, 2 core card set.

(used for 1.3.x to 3.y)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all SMs:

    6. For all SMs, set where in flash memory the boot code file will be written:

    7. For all SMs, set where in flash memory the firmware file will be written:

    8. For all stand-alone SMs:

    9. For all primary SMs in all redundancy groups:

    10. For all SMs:

Procedure 21. Graceful upgrade, 2 core card set.

(used for 1.3.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all primary and stand-alone SMs:

    5. For all SMs, set where in flash memory the boot code file will be written:

    6. For all SMs:

    7. For all stand-alone SMs:

    8. For all primary SMs in all redundancy groups:

    9. For all SMs:

Procedure 22, Graceful downgrade, 1 core card set (SM only).

(used for 1.4.y to 4.x)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. For all SMs:
    Perform the dsptotals command. The configuration of the shelf should not be changed during the upgrade or downgrade process. This step is to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

    4. For all SMs:

    5. For all SMs

    6. For all stand-alone SMs:

    7. For all primary SMs in all redundancy groups:

    8. For all SMs:

Procedure 23. Graceful upgrade, 2 core card set.

(used for 1.4.x to 4.y)

    1. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    2. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    3. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    4. For all primary and stand-alone SMs:

    5. For all SMs:

    6. For all SMs:

    7. For all stand-alone SMs:

    8. For all primary SMs in all redundancy groups:

    9. For all SMs:

Procedure 24, Graceful downgrade, 1 core card set (SM only).

(used for 1.4.y to 4.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. For all primary and stand-alone SMs
    Perform the dsptotals command. The configuration of the shelf should not be changed during the upgrade or downgrade process. This step is to examine the number of shelf connections. A similar step can be made to examine the same configuration parameters after the upgrade or downgrade and, therefore, it can be established that the configuration has remained the same.

    5. For all SMs, set where in flash memory the firmware file will be written

    1. For all SMs

    2. For all stand-alone SMs:

    3. For all primary SMs in all redundancy groups:

    4. For all primary and stand-alone SMs in all redundancy group:

Procedure 25. Graceful upgrade, 2 core card set.

(used for 1.4.y to 4.x)

    1. Check compatibility - With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

    2. Save the current ASC configuration. Perform this step for the ASC prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_ASC_ACTIVE.BR

    3. Save the current Service Module (SM) configuration for each primary and stand-alone SM. Perform this step for the SM prior to upgrading the firmware.

    First reset the card then use TFTP get to save the card's current configuration in the workstation.

    tftp shelf
    tftp> bin
    tftp> get AXIS_SM_1_<slot>.PRI.<service password>

    4. Execute the dspadrcxat command and note the value of the ConnNumOfValidEntries parameter. This indicates the number of connection, this command is executed again at the end of the procedure to ensure that the number of connections has not changed.

    5. For all primary and stand-alone SMs:

    6. For all SMs:

    7. For all SMs:

    8. For all stand-alone SMs:

    9. For all primary SMs in all redundancy groups:

    10. For all SMs:

Description of Upgrade/Downgrade Terminology

Standard

A standard upgrade/downgrade technique is the most simple and fastest technique for upgrading/downgrading between a pair of firmware and/or backup boot code releases. A standard technique trades traffic loss for simplicity and speed.

Graceful

A graceful upgrade/downgrade technique attempts to minimize traffic loss at the expense of added complexity and time. For example, the service module graceful upgrade from release 3.x to 3.y for a shelf with a 9:1 redundancy group will require 18 resetcd operations and may take 20 minutes. The average traffic loss per connection will be approximately 20 seconds. The service module standard upgrade from release 3.x to 3.y requires only a single resetsys command and may take 60 seconds, but the average traffic loss per connection may be over a minute.

1cc

One core card set (MGX 8220 Shelf Controller [ASC] Broadband Network Module [BNM] [SRM])

2cc

Two core card sets (ASC BNM [SRM])

chkflash

The MGX 8220 ASC and service module CLI command, chkflash, calculates and compares the flash checksum. In some releases, the chkflash command will report the firmware or backup boot code version as it resides in flash. In this case, the version reported by the chkflash command should be compared with the version of firmware or backup boot code which was TFTP-put.

example:

shelf.1.<slot>.<type>.<a|s>chkflash

version

The MGX 8220 ASC and service module (SM) CLI command, version, displays the backup boot code version that is currently stored in flash (not necessarily the version of backup boot code which is being executed) and the firmware version that is being executed

example:

shelf.1.<slot>.<type>.<a|s>version

tftp put

The UNIX TFTP (Trivial File Transfer Program) is used to write firmware or backup boot code to the ASC flash or disk and to the SM flash.

example:

tftp shelf

tftp> bin

tftp> put <file> AXIS_<FILE>.<EXTENSION>

tftp> quit

The number of bytes reported as being sent by the TFTP routine should be compared with the size of the firmware or backup boot code file.

example:

ls -l <file>

-rw-rw-rw- <size> <file>

tftp> put <file> AXIS_<FILE>.<EXTENSION>

Sent <size> bytes in <seconds>seconds

file size

The firmware file size tends to be rather unique. The firmware file size can be used to verify that the firmware file was successfully TFTP-put to the ASC disk.

example:

shelf.1.<3|4>.ASC.<a|s>shellConn

shelf.1.<3|4>.ASC.<a|s> cd "C:fw"

shelf.1.<3|4>.ASC.<a|s> ll

size

date

time

name

512

<date>

<time>

.

512

<date>

<time>

.

<size>

<date>

<time>

ASC.FW

dspfwrevs

The dspfwrevs was first introduced in 2.1.25 and 4.0.02 and later in release 3. Any time ASC firmware is TFTP put to an ASC card executing release 2.1.25 or 4.0.02 (or greater), the dwpfwrevs command can be used to ensure that the ASC firmware was successfully TFTP-put to the disk. Any time SM firmware is TFTP-put to an ASC card executing 4.0.02 (or greater), the dwpfwrevs command can be used to ensure that the SM firmware was successfully TFTP-put to the disk.

example:

shelf.1.<3|4>.ASC.<a|s> dspfwrevs

Config

File Name

Card Type

Version

n/a

asc fw

ASC

<version>

slot-specific versus card-type-specific SM firmware

MGX 8220 active ASC cards executing release 2 or 3 firmware support TFTP-putting slot-specific SM firmware. This means that firmware is TFTP-put to each SM slot individually. The SM firmware is written directly to the SM flash. Within the upgrade/downgrade techniques, this is denoted as:

example:

tftp put <SM_FW_file> AXIS_SM_1_$slot.FW

MGX 8220 active ASC cards executing release 4 firmware support TFTP-putting card-type-specific SM firmware (in addition to slot-specific SM firmware). In release 4, the SM firmware is written to the ASC disk instead of the SM flash as in release 2 and 3.

In release 4, a single SM firmware file can be TFTP put to the ASC disk for all SMs of a particular card type. This is denoted as:

tftp put <SM_FW_file> AXIS_SM_1_0.FW

Each time an SM is reset, it downloads the SM firmware file based on its card type. MGX 8220 active ASC cards executing release 4 firmware also support TFTP-putting slot-type-specific SM firmware. The SM firmware is still written to the ASC disk.

Slot-specific SM firmware takes precedence over card-type-specific firmware. That is, for a SM of a particular card type in a particular slot, if both card-type-specific and slot-specific firmware files exist, the slot-specific firmware will be downloaded to the SM.

A CONFIG.SYS file on the ASC disk keeps track of which SM firmware files are "in effect." If an SM firmware file (slot-specific or card-type-specific) is not contained within the CONFIG.SYS file, it will not be downloaded to an SM.

An SM firmware file is automatically added to the CONFIG.SYS file when it is TFTP-put to the active ASC disk and when the active ASC disk downloads the SM firmware file to the standby ASC disk. A SM firmware file can be removed from the CONFIG.SYS file using the delcfgsys command.

The dspfwrevs command can be used to list all of the SM firmware files on the active and standby ASC disks and identify which SM firmware files are contained within the CONFIG.SYS file.

flashStartAddr and flashEndAddr

The flashStartAddr and flashEndAddr are simply variables that determine where within flash memory a file will be written. The ASC flashStartAddr defaults to 0xbfc00000 (ASC backup boot code) and need never be changed (the ASC firmware resides on the ASC disk in release 2, 3 and 4). The ASC flashEndAddr defaults to 0xbfc80000.

In releases 2 and 3, the SM flashStartAddr defaults to 0xbfc40000 (SM firmware) after the SM is reset. The SM flashEndAddr defaults to 0xbfd00000.

In release 4, the SM flashStartAddr defaults to 0xbfc00000 (SM backup boot code) after the SM is reset. The SM flashEndAddr defaults to 0xbfc80000.

SM backup boot code (Release 2 and 3)

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc00000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc40000

SM backup boot code (Release 4)

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc00000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfc80000

SM firmware (Release 2 and 3)

shelf.1.<slot>.<type>.<a|s>shellConn

shelf.1.<slot>.<type>.<a|s>flashStartAddr = 0xbfc40000

shelf.1.<slot>.<type>.<a|s>flashEndAddr = 0xbfd00000

resetsys

The MGX 8220 active ASC CLI command, resetsys, is used to reset all the cards in the MGX 8220 shelf.

shelf.1.<3|4>.ASC.a > resetsys

The resetsys command will terminate all Telnet sessions. The user will have to re-initiate a Telnet session after an ASC card returns to the active state.

softswitch

The MGX 8220 active ASC CLI command, softswitch, is used to transfer traffic between a primary and secondary SM while greatly minimizing the traffic loss. The softswitch command is available in release 4.

shelf.1.<3|4>.ASC.a > softswitch <primary> <secondary>

shelf.1.<3|4>.ASC.a > softswitch <secondary> <primary>

dspadrxlat

Any upgrade that involves resetting the active ASC card and any downgrade in which the configuration is preserved should compare the number of shelf connections before and after the upgrade/downgrade. This is accomplished by performing the MGX 8220 ASC CLI command:

shelf.1.<3|4>.ASC.a > dspadrxlat

The only information that you are interested in is:

ConnNumOfValidEntries: <value>

A user should not make configuration changes to the shelf while an upgrade or downgrade is in progress. There is a chance that all or part of the configuration changes could be lost.

dsptotals

Any upgrade that involves resetting a stand-alone or primary service module should compare the total number of lines, ports and channels before and after the upgrade/downgrade. This is accomplished by performing this MGX 8220 SM CLI command:

shelf.1.<slot>.<type>.a > dsptotals

The only information that you are interested in is:

total active lines = <value>/<maximumlines>

total active ports = <value>/<maximumports>

total active chans = <value>/<maximumchannels>

A user should not make configuration changes to the shelf while an upgrade or downgrade is in progress. There is a chance that all or part of the configuration changes could be lost.

donotupdatestandby

The MGX 8220 active ASC CLI command, donotupdatestandby, is used as part of an ASC graceful firmware upgrade to prevent the active ASC card from downloading firmware or configuration information to a reset standby ASC card. Some ASC firmware releases include the MGX 8220 active ASC CLI command, updatestandby, which can be used to undo the effects of the donotupdatestandby command.

shelf.1.<3|4>.ASC.a > donotupdatestandby

Compatibility?

With any downgrade technique, there is always the issue of compatibility. Any release can be downgraded to any other release, but in many instances configuration information will be lost. Hardware incompatibilities may prevent some downgrades. For example, release 2 and 3 service modules require two flash chips. Release 4 SMs will be shipped with a single flash chip. A release 4 shelf containing BNM-E1 cards or Service Resource Module-3T3 cards cannot be downgraded to release 2 or 3. Check the Compatibility Matrix to determine if a particular downgrade is supported and with what consequences with respect to configuration loss.

clrallcnf

The MGX 8220 active ASC CLI command, clrallcnf, is used in place of the resetsys command as part of a downgrade in which the configuration information can not be maintained for compatibility reasons. The clrallcnf command will terminate all Telnet sessions. The user will have to reinitiate a Telnet session after an ASC card returns to the active state.

resetsys or clrallcnf

Some standard techniques may involve releases that support downgrade without configuration loss (compatible releases). For these releases, the resetsys command can be used. For releases that involve configuration loss, the clrallcnf command should be used.

save/restore ASC configuration?

The ASC card stores ASC configuration information in BRAM (Battery-Backed RAM). The BRAM contains a revision that identifies the format of the configuration information. The format can change from release to release. The newer version of firmware will always provide conversion routines which automatically reformat the configuration information as part of an upgrade. However, there is no support for reformatting as part of a firmware downgrade.

downgrade.

If the BRAM revision is different between the firmware revisions involved in an upgrade, the active ASC BRAM information should be saved prior to the upgrade using:

tftp shelf

tftp> bin

tftp> get AXIS_ASC_ACTIVE.BR

tftp> quit

In general, it is recommended to save the active ASC BRAM information prior to any upgrade.

If the BRAM revision is different between the firmware revisions involved in a downgrade, the active and standby ASC BRAM information should be restored following the downgrade using:

tftp shelf

tftp> bin

tftp> put AXIS_ASC_ACTIVE.BR

tftp> quit

tftp shelf

tftp> bin

tftp> put AXIS_ASC_ACTIVE.BR AXIS_ASC_STANDBY.BR

tftp> quit

The active and standby ASC cards must be reset in order to execute the saved configuration. If the ASC BRAM revision is the same between the firmware revisions involved in a downgrade, the ASC configuration should be preserved (there is no need to restore the configuration).

save/restore SM configuration?

The ASC card stores service module (SM) configuration information on the disk in a configuration (PRI) file. The file contains a revision which identifies the format of the configuration information. The format can change from release to release. The newer version of firmware will always provide conversion routines which automatically reformat the configuration information as part of an upgrade. However, there is no support for reformatting as part of a firmware downgrade.

If the SM configuration file revision is different between the firmware revisions involved in an upgrade, the configuration file should be saved for each primary and stand-alone SM using:

tftp shelf

tftp> bin

tftp> get AXIS_SM_1_<slot>.PRI.<service password>

tftp> quit

In general, it is recommended to save the SM configuration file for each primary and stand-alone SM prior to any upgrade. If the SM configuration file revision is different between the firmware revisions involved in a downgrade, the configuration file should be restored for each primary and stand-alone SM using:

tftp shelf

tftp> bin

tftp> put AXIS_SM_1_<slot>.PRI.<service password>

tftp> quit

The standby ASC card must be reset in order to download the SM configuration files from the active ASC card. Each primary and stand-alone SM must be reset in order to execute the saved configuration. If the SM configuration file revision is the same between the firmware revisions involved in a downgrade, the SM configuration should be preserved (there is no need to restore the configuration).


hometocprevnextglossaryfeedbacksearchhelp
Posted: Mon Jan 15 22:04:00 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.