Upgrade Information

You can now gracefully upgrade your Broadband Switch Module (BXM) card to a BXM-E card without any service interruption (on Y-red BXMs).

The enhanced BXM-E card (version DX or EX) supports a higher connection density (32K) than either the legacy BXM or regular BXM-E cards. Both DX and EX versions have the same connection density, providing the ability to upgrade networks with the high connection density BXM-Es on trunk side, port side, or a combination of trunks and ports.

Prior to this feature, upgrading a functioning legacy BXM or regular BXM-E card (configured in low-connection-density mode), to the DX or EX version of BXM-E (configured in higher connection density mode) required deleting all existing connections terminating on the active BXM card and reestablishing the connections on the new card.

After the BXM-E card replaces the BXM card, the switch software programs all channels on the new active card or on the hot standby card. The performance effect due to programming the channels is minimal since the process is done only once for each BXM card. If the cards are Y-red, Automatic Routing Management traffic still can be transported through the active card while the standby BXM-E is programmed.

This section contains both automatic and automatic and manual upgrade scenarios. The benefit of manually upgrading is that the logical database is not automatically upgraded, thus permitting you to fall back from BXM-E to BXM without mismatch. The concept of mismatch is introduced when BXM cards are configured as Y-redundancy or 1+1 APS. BXM cards with different connection densities are not declared as mismatch, so long as the physical density of the latest inserted card is greater or equal to the density of the other card in the Y-redundancy pair.

If VSI was configured on the legacy card, the VSI partition is expanded to allow the extra LCNs. The additional LCNs are allocated to the first port of the first enabled VSI. This provides a convenient way to fall back to a former VSI configuration.

Summary of Commands

A full description of these commands is located in the Cisco WAN Switching SuperUser Command Reference.

Table A-1 BXM-BXM-E Upgrade Commands
Command	Description	Default	Consult
cnfnodeparm	Configure node parameters, auto BXM upgrade parameter. If set to "Y," the Switch software upgrades the logical database as soon as both the legacy BXMs are replaced by BXM-Es in Y-red case, or the active legacy BXM is replaced by a BXM-E in non-Y-red cases. If set to "N," you must upgrade the logical database manually using the upgdlogcd command.	Y	Cisco WAN Switching SuperUser Command Reference
cnfcdparm	Configure card parameters. This command is used to set the standby card to the appropriate channel statistics level and number of connections.	N/A	Cisco WAN Switching SuperUser Command Reference
upgdlogcd	Upgrade logical card database. The upgdlogcd <log_card_num> is used to manually upgrade the logical card database. When using the upgdlogcd command, the cnfnodeparm "auto BXM upgrade" parameter must be set to "N." When performing the upgrade, switch back to the legacy card before the upgdlogcd command is initiated.	N	Cisco WAN Switching SuperUser Command Reference

Upgrade Options

Table A-2 Upgrade Options
Option	Used when...	Steps
Y-Red BXMs, manual	Legacy BXMs are Y-red and the "auto BXM upgrade parameter" is set to "N" for the cnfnodeparm command.	1. Remove the standby BXM card and replace it with the BXM-E card. 2. BXM-E card scan be flagged as "Mismatch" if the configured channel statistics level or number of connections is smaller than those configured on the active BXM card. Use the command cnfcdparm <BXM-E slot_num> to configure the desired level of channel statistics and number of connections, if not already configured. The BXM-E card is reset after the cnfcdparm command is executed. After the BXM-E card boots, there should be no mismatch. 3. Y-red the switch so that the standby BXM-E becomes active. 4. Repeat steps 1-2 for the other slot. You still can fall back to the legacy card up to this point. 5. Upgrade the logical card using the command upgdlogcd <log_card_num>. Switch software upgrades the logical database from the number of connections configured on the legacy BXM card to the number of connections configured in step 2 and 4. From this point on, mismatch is declared if the legacy card is reinserted. Note During upgrading Y-red BXM cards to BXM-E cards, the level of service disruption is expected to be the same as the one experienced when switchyred is executed for Y-red legacy BXMs.
Y-red BXMs, automatic	Legacy BXMs are Y-red and the "auto BXM upgrade" parameter is set to Y for the cnfnodeparm command.	1. Remove the standby BXM card and replace it with the BXM-E card. 2. BXM-E card can be flagged as `Mismatch' if the configured channel statistics level or number of connections is smaller than those configured on the active BXM card. Use the command cnfcdparm <BXM-E slot_num> to configure the desired level of channel statistics and number of connections, if not already configured. The BXM-E card is reset after the cnfcdparm command is executed. After the BXM-E card boots, there should be no mismatch. 3. Y-red the switch so that the standby BXM-E becomes active. 4. Repeat steps 1and 2 for the other slot. 5. Switch software automatically upgrades the logical database when step 4 is done. Note During upgrading Y-red BXM cards to BXM-E cards, the level of service disruption is expected to be the same as the one experienced when switchyred is executed for Y-red legacy BXMs.
Standalone BXM, manual	Legacy BXM card is non-Y-red and the "auto BXM upgrade" parameter is set to "N" for the cnfnodeparm command.	1. Use an empty slot to configure the BXM-E card for the desired level of channel statistics and number of connections. The channel statistics level and number of connections must be either equal to or higher than the ones configured on the legacy BXM card that it is replacing. While this step is optional, if skipped, the BXM-E card may not have the desired channel statistics level and appropriate number of connections. 2. Remove the BXM card and replace it with the BXM-E card. If step 1 is skipped, the BXM-E card can create a mismatch if it does not have the desired configuration. In that case, use the command cnfcdparm <BXM-E slot_num> to set the card to the desired level of channel statistics and number of connections. This may prolong service disruption. 3. Issue the upgdlogcd <log_card_num> command to upgrade the logical card database. Switch software upgrades the logical database from the number of connections configured on the legacy BXM card to the number of connections configured in step 1. From this point on, mismatch is declared if the legacy card is reinserted. Note In non-Y-red cases, the traffic disruption is unavoidable because the legacy BXM has to be removed and replaced with the BXM-E card.
Standalone BXM, automatic	Legacy BXM card is non-Y-red and the "auto BXM upgrade" parameter is set to `Y' for the cnfnodeparm command.	1. Use an empty slot to configure the BXM-E card for the desired level of channel statistics and number of connections. The channel statistics level and number of connections must be either equal to or higher than the ones configured on the legacy BXM card that it is replacing. While this step is optional, if skipped, the BXM-E card may not have the desired channel statistics level and appropriate number of connections. 2. Remove the BXM card and replace it with the BXM-E card. If step 1 is skipped, the BXM-E card can create a mismatch if it does not have the desired configuration. In that case, use the command cnfcdparm <BXM-E slot_num> to set the card to the desired level of channel statistics and number of connections. This may prolong service disruption. 3. Switch software automatically upgrades the logical database when step 2 is done. Note In non-Y-red cases, the traffic disruption is unavoidable because the legacy BXM has to be removed and replaced with the BXM-E card.

Upgrade Protection from Release 9.3 to a Later Release

Release 9.3 includes an Upgrade Protection feature. This section provides guidelines on upgrades from BPX switch software Release 9.3 to later releases.

Active statistics collection interferes with the software upgrade process. Prior to Release 9.3, you were responsible for turning statistics off before beginning the software upgrade procedure.

The Upgrade Protection feature introduced in 9.3 protects you against the effects of failing to turn off statistics. In 9.3, statistics collection is automatically turned off by the system when you enter the loadrev 1 phase. You are now prevented from running loadrev/runrev during the time that statistics collection is enabled. When you execute loadrev, the switch gives this message "Warning: Statistics collection will be automatically disabled."

In addition to statistics collected by Cisco WAN Manager, the local statistics collection state machines are also disabled at this time.

Upgrade Protection applies only to a "graceful upgrade," that is, an upgrade to a standby controller card. There is no change to the "nongraceful upgrade" procedure.

This feature is operational only when upgrading from Release 9.3 to a later release. Upgrade from Release 9.2 to 9.3 does not use this 9.3 feature. Upgrade Protection is used in intraversion upgrades, such as an upgrade between 9.3.1 and 9.3.2

If you attempt to load an older release than the one currently running, you are warned that downgrades are not supported. You may override this warning and continue at your own risk. This feature is meant to warn you early in case an invalid release is inadvertently loaded.

If you need to see certain statistics at this phase of the upgrade, you are allowed to restart state machines one at a time. However, it is your responsibility to disable all these machines before entering the runrev phase.

Procedure

•

Recent software errors. Any nodes that continually log errors or have logged recent errors should be reported to Cisco TAC.

•

Card errors. Cards that are logging self or background test failures or have a history of hardware errors should be investigated by Cisco TAC.

•

Nodes with less than 40% CPU idle time (20% in the case of PCCs). Such nodes are not usually found within BPX/IGX/IPX networks. These nodes should be examined closely. If the idle time is consistently low, you should contact the Cisco TAC.

•

Load model failures. These failures should be reported to the Cisco TAC. Software Release 8.4 and higher use trunk-based loading and can show load model failures shortly after network topology changes.

•

Any trunks that are logging errors should either be fixed or configured not to pass management traffic for the duration of the upgrade.

•

All alarms should be accounted for. The real purpose of this check is to ensure that there are no alarms, such as bus failures, which requires special intervention before the upgrade.

The process of upgrading a network from one release of switch software to another involves the following phases:

Step 1

Load the new software image into the switches of the network by using loadrev 1

Step 2

Upgrade the new image in standby controller cards (assuming graceful software upgrade) by using
upgrade. If you need to see certain statistics at this phase of the upgrade, you are allowed to restart state machines one at a time. However, it is your responsibility to disable all these machines before entering the runrev phase.

Step 3

Run the new software revision, retaining the old revision and configuration for fallback protection, by using runrev.

Step 4

Load the new revision into all controller cards in each node, purging all traces of the old revision, and completing the upgrade. Use loadrev 2.

When you complete the upgrade by entering the loadrev 2 phase, the Upgrade Protection feature reenables all the statistics state machines that were active when upgrades were started. If CWM statistics are desired, you must use CWM to restart collection.

Feature Mismatching

Feature mismatching provides customers a graceful migration path to Release 9.2 features.

Switch Software Release 9.1 and previous releases of switch software mismatched cards if the capabilities in the logical card database did not match exactly the capabilities of the physical card. This restriction does not allow customers to gracefully migrate their BXM/UXM cards.

The current feature mismatching capability will not mismatch cards unless the actual feature has been enabled on the card. This allows for a graceful card migration from an older release.

BPX switch software features perform the following feature mismatching functions:

•

Command Line Block—Specifies that the command line interface will block you from enabling the feature if it is not supported by the logical card.

•

Inserting cards/mismatch checking—Specifies that the card is mismatched only if the feature has been enabled and the inserted card does not support this feature.

•

addyred command mismatch Checking—If the primary card is active, the addyred command will not allow you to configure Y-redundancy if the secondary card does not support this feature. If the feature is not enabled, and the primary and secondary cards do not support the same feature sets, you are warned that the capability will not function.

Refer to the 9.2 Release Notes for up-to-date information on feature support, and software, hardware, and firmware requirements.

The configuration commands that enable Release 9.2 features to support mismatch verification are listed in Table A-3.

Table A-3 Configuration Commands to Support Mismatch Verification
Name	Description
uptrk	Verifies virtual trunking support.
cnfrsrc and addshelf	Verifies VSI 2.0 support.
addapsln	Verifies APS support.
cnfport	Verifies LMI/ILMI support.
cnfoamlpbk	Verifies OAM Loopback support.
dspcd	Verifies PPD on policing (PPDPolic) support.

Switch software provides an upgrade path for each of the Release 9.2 features. Table A-4 describes the various scenarios while running Release 9.2 switch software and various versions of Release 9.1 and Release 9.2 firmware. It also describes the process of upgrading firmware in a scenario where a single active card and Y-cable is in use.

Table A-4 Upgrading Firmware When Single Active Card and Y-Cable is in Use
Configuration/Features	VSI	VT	LMI/ILMI	APS	OAM
Single Active Card Configuration: if the firmware is upgraded from 9.1 to 9.2, no mismatch will occur.	N.A. See Note 1 below table.)	OK	OK	OK	OK
Single Active Card Configuration: if the firmware is downgraded from 9.2 to 9.1, mismatch will occur if the 9.2 feature has been configured.	MM (if VSI is configured)	MM (if VT is configured)	MM (if Card based LMI is configured)	MM (if APS is configured)	MM (if OAM is configured)
Y-cable configuration with the Primary Card running 9.1 firmware and the Secondary Card running 9.2 firmware: the Primary Card will mismatch if the 9.2 feature has been configured.	Primary MM (Primary Card mismatch if VSI configured)	Primary MM (Primary Card mismatch if VT feature is configured)	Primary MM (Primary Card mismatch if card-based ILMI is configured)	Primary MM (Primary Card mismatch if APS is configured)	Primary MM (Primary Card mismatch if AOM is configured)
Y-Cable configuration with the Primary Card and the Secondary Card running 9.2 firmware: no mismatch will occur and the 9.2 features are available to be configured.	OK	OK	OK	OK	OK
Y-cable configuration with the Primary Card running 9.2 firmware and the Secondary Card running 9.1 firmware: the Secondary Card will mismatch if the 9.2 feature has been configured	Secondary MM (Secondary Card mismatch if VSI configured)	Secondary MM (Secondary Card mismatch if VT feature is configured)	Secondary MM (Secondary Card mismatch if card-based ILMI is configured)	Secondary MM (Secondary Card mismatch if APS is configured)	Secondary MM (Secondary Card mismatch if OAM is configured)

Note VSI 1.0 is supported in Release 9.1 switch software and Release 9.1 BXM firmware. In Release 9.2, VSI 1.0 will not be supported in switch software. You must upgrade firmware before switch software can support VSI 2.0. (Refer to 9.2 Release Notes for firmware and hardware requirements to use VSI 2.0 and VSI 2.2.) Release 9.2 switch software will mismatch BXM cards that have VSI 1.0 supported when the VSI feature is configured.

If BXM cards are configured for Y-cable redundancy and the cards do not support the same feature sets, if the feature is not enabled, the cards will not mismatch. If you attempt to enable the Y-cable redundancy feature, it is blocked at the command line interface.

Multiple VSI Partitions

Support for up to two partitions requires BPX switch software 9.2.3 and Firmware Ez. The card uses a flag in the capability message to report multiple partition capability. Firmware releases that do not support multiple partitions set this flag to OFF. The multiple partitions capability is treated as a card attribute and added to the attribute list.

Use of a partition with ID higher than 1 requires support for multiple VSI partitions in both switch software and BXM firmware, even if this is the only partition active on a the card.

In a Y-red pair configuration, the multiple partition capability is determined by the minimum of the two cards. A card with no multiple partition capabilities will mismatch if any of the interfaces has an active partition with ID higher than 1. Attempts to enable a partition with ID higher than 1 in a logical card that does not support multiple partitions are blocked.

Table A-5 Mismatch Conditions if Number of Channels Changes
Configurations	Mismatch
Replacing the current active card with a card with more channels: card will not mismatch, although the additional channels are NOT available to the user.	No
Replacing the current active card with a card with fewer channels: the inserted card will mismatch.	Yes
Active or standby Y-cable configuration with both the primary and secondary card supporting the same number of channels as defined in the logical database.	No
Active Y-cable configuration with the Secondary Card supporting fewer channels than defined in the logical card (primary card) database.	Secondary card mismatch
Active Y-cable configuration with the primary card supporting fewer channels than the logical card database.	Primary card mismatch
Active Y-cable configuration with the primary or secondary cards (or both) supporting more channels then the logical card database: neither card will mismatch although the additional channels are NOT available to the user.	No
Standby Y-cable configuration with the primary or secondary cards supporting different number of channels.	Mismatch

Functional Description of Feature Mismatch Checking

This section describes some of the behavior related to feature mismatching in this release.

Card Insertion/Mismatch Checking

The BXM and UXM card insertion/mismatch checking verifies that the inserted card supports all features currently available to the user. For feature mismatching, the following verification methods are performed:

•

When a single card is inserted, if the physical card does not support the specific feature, and the feature has been enabled, the card will mismatch.

•

When a single card is inserted, if the feature is not enabled, and the physical card supports the new feature, the logical card database should be updated to reflect this feature.

•

During Y-cable mismatch, if the feature is enabled and if the inserted primary or secondary card does not support this feature, the card will mismatch.

•

During Y-cable mismatch, if the feature is not enabled and if the inserted primary or secondary card does not support the feature, the logical card database is updated to reflect this.

•

During Y-cable mismatch, if the feature is disabled, and if both the inserted primary and secondary cards both support this feature, the logical database is updated to reflect this.

UI Commands and Enabling Feature Mismatch

When a feature is enabled, a verification is made to assure that the hardware and firmware supports this feature. That is, during feature configuration, switch software performs a check to determine if the feature is supported by the BXM or UXM card. For example, if you are trying to add APS on a specific line (with addapsln) and the BXM card does not support this feature, a warning message is displayed and the addition is not completed.

If the feature is not available, a warning message is displayed and the feature will not be enabled.

addyred/delyred Mismatch Checking

During the addyred command mismatch checking, the following verifications are done:

•

A verification to ensure that both the primary and secondary cards support the activated features. For example, if on the primary card, the APS feature has been configured, and on the secondary card this feature is not available, you are blocked from using the addyred command.

•

If the feature is not enabled, and the secondary card does not support similar feature sets, switch software updates its logical database to reflect this.

•

Following a delyred command execution, the logical card's database is updated to reflect the primary card's capabilities.

The addyred commands (addyred, delyred, dspyred, prtyred, switchyred) will verify feature support on both the primary and secondary cards.

Considerations for Feature Mismatch Checking

•

Consider a situation where a user replaces an active BXM card running Release 9.1 firmware with an Enhanced BXM card running Release 9.2 firmware (active card). The BXM-E (enhanced card) has more channels (channels scheduler). However, in this situation, the additional channels on the Enhanced BXM card cannot be used. To benefit from the additional channels provided on the Enhanced BXM card, you must put this card in a standby mode.

•

Mismatches are reported when an old BXM card is replaced with a new BXM card that has different port group or channel levels (MLCS), even though the old BXM card and the new BXM card have identical channel numbers.

Table Of Contents