|
|
This appendix provides special upgrade information.
You can now gracefully upgrade your Broadband Switch Module (BXM) card to a BXM-E card without any service interruption (on yred 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 you with 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 yred, autoroute 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 alloated to the first port of the first enabled VSI. This provides a convenient way to fall back to a former VSI configuration.
A full description of these commands is located in the WAN Switching SuperUser Command Reference.
| 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 yred case, or the active legacy BXM is replaced by a BXM-E in non-yred cases. If set to "N," you must upgrade the logical database manually using the upgdlogcd command. | Y | WAN Switching SuperUser Command Reference |
cnfcdparm | Configure card parameters. This command is used to set the standby card to the appropriate channel stats level and number of connections. | N/A | WAN Switching SuperUser Command Reference |
upgdlogcd | Upgrade logical card database. upgdlogcd <log_card_num> is used when you want 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, you can switch back to the legacy card before the upgdlogcd command is initiated. | N | WAN Switching SuperUser Command Reference |
Use one of the following upgrade options described in Table A-2.
| Option | Used when... | Steps | ||
|---|---|---|---|---|
Yred BXMs, manual | Legacy BXMs are yred 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 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. Yred the switch so that the standby BXM-E becomes active. 4. Repeat steps 1-2 for the other slot. User 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.
| ||
Yred BXMs, automatic | Legacy BXMs are yred 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. Yred switch so that the standby BXM-E becomes active. 4. Repeat steps 1-2 for the other slot. 5. Switch software automatically upgrades the logical database when step 4 is done.
| ||
Stand alone BXM, manual | Legacy BXM card is | 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.
| ||
Stand alone BXM, automatic | Legacy BXM card is non-yred 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.
|
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. 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 "graceful upgrade," that is, upgrade to a standby controller card. There is no change to the "non-graceful 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 intra-version 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 will be 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.
The process of upgrading a network from one release of switch software to another involves several phases:
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 re-enables 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 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 these feature mismatching functions:
Feature mismatch is supported by these BPX switch software features:
Refer to the 9.2 release notes for up-to-date information on feature support, and software, hardware, and firmware requirements.
All configuration commands that enable Release 9.2 features support mismatch verification. For example:
Switch software provides an upgrade path for each of the Release 9.2 features. Table A-3 below 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.
| 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) |
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 will be blocked at the command line interface.
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 will be 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 will be blocked.
| 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 mismatch. | No |
Active Y-cable configuration with the Secondary Card supporting fewer channels than defined in the logical card (primary card) database: the secondary card will mismatch. | Secondary card mismatch |
Active Y-cable configuration with the primary card supporting less channels than the logical card database: the primary card will mismatch. | Primary card mismatch |
Active Y-cable configuration with the primary or secondary cards (or both) supporting more channels then the logical card DB: neither card will mismatch although the additional channels are NOT available to the user. | No mismatch
|
Standby Y-cable configuration with the primary or secondary cards supporting different number of channels: card will mismatch. | Mismatch
|
The following sections describe some of the behavior related to feature mismatching in this release.
The BXM and UXM card insertion/mismatch checking verifies that the inserted card supports all features currently available to the user. For Feature Mismatching, this verification is performed:
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.
The dspcd command gives you mismatch information for the specified card.
If the feature is not available, a warning message is displayed and the feature will not be enabled.
During addyred's mismatch checking, the following verifications are done:
The addyred commands (addyred, delyred, dspyred, prtyred, switchyred) will verify feature support on both the primary and secondary cards.
Following are some things to be aware of related to feature mismatch:
Posted: Fri Jul 27 16:46:51 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
