Table of Contents

Phased Release Strategy
Definitions

Clarifications for Release 9.3.11
Clarifications for Release 9.3.10
Clarifications for Release 9.3.05
Clarifications for Release 9.3.00
Clarifications for Release 9.2

General Upgrade Procedure

Procedure for Upgrading BXM cards to the 9.3 Firmware Release
Procedure for Upgrading UXM cards to the 9.3 Firmware Release
Procedure for Adding New BCC Cards as a Part of Upgrading to Release 9.3

Revision Interoperability Supported
Version Compatibility Notes
Control Card Requirements
Control Card Boot Firmware Requirements
Control Card Compatibility Requirements
Control Card Physical Card Upgrade Procedure
Obsoleted

Additional Notes for Release 9.3.24
Additional Notes for Release 9.3.20
Additional Notes for Release 9.3.11
Additional Notes for Release 9.3.10
Additional Notes for Release 9.3.05
Additional Notes for Release 9.3.00
Additional Notes for Release 9.2
Limitations for Release 9.3.24
Limitations for Release 9.3.20
Limitations for Release 9.3.11
Limitations for Release 9.3.10
Limitations for Release 9.3.05
Limitations for Release 9.3.00
Limitations for Release 9.2
Limitations for Release 9.1
Limitations for Release 8
Required Workarounds for Release 9.1
Required Workarounds for Release 8

Compatibility Notes

MGX 8220 Firmware Compatibility
MGX 8850 1.1 Firmware Compatibility
MGX 8230 1.1 Firmware Compatibility
MGX 8250 1.1 Firmware Compatibility
BPX 8600 Firmware Compatibility
IGX 8400 Firmware Compatibility
MGX 8220 5.0 Hardware Compatibility
BPX 8600 Hardware Compatibility
IGX 8400 Hardware Compatibility

SNMP MIB

Switch MIB changes of Release 9.3.11, 9.3.20, 9.3.24
Switch MIB changes of Release 9.3.10
Switch MIB Changes to Release 9.3.05
Switch MIB changes to Release 9.3

BPX 8600 Nodes

BNI-T3
BNI-E3
BNI-155/155E
BXM-T3
BXM-E3
BXM-155
BXM-622

IGX 8400 Nodes

UXM-T3
UXM-T1-IMA (with 1 physical only line up)
UXM-T1-IMA (with 4 physical lines up)
UXM-E1-IMA (with only one physical line up)
UXM-E1-IMA (4 physical lines up)
UXM-E3
UXM-OC3
NTM-T1
NTM-E1
NTM-SR

About the Firmware MFM
Front Cards
Front Card for APS Compatibility
Back Cards
New Features supported in BXM Firmware MFM:
New Features supported in BXM Firmware MFK:
New Features supported in BXM Firmware MFJ:
New Features supported in BXM Firmware MFH:
New Features supported in BXM Firmware MFF
New Features supported in BXM Firmware MFE
New Features supported in BXM Firmware MFD
New Features supported in BXM Firmware MFC
New Features supported in BXM Firmware MFB
New Features supported in BXM Firmware MFA
New Features supported in BXM Firmware MEC
New Features supported in BXM Firmware MEB
New Features supported in BXM Firmware MEA
New Features supported in BXM Firmware MDA
Clarifications:
Special Installation/Upgrade Requirements
Features obsoleted
Notes & Cautions
Known Anomalies
Bugs Fixed in MFM
Bugs Fixed in MFL
Bugs Fixed in MFK
Bugs Fixed in MFJ
Bugs Fixed in MFH
Bugs Fixed in MFF
Bugs Fixed in MFE
Bugs Fixed in MFD
Bugs Fixed in MFC
Bugs Fixed in MFB
Bugs Fixed in MFA
Bugs Fixed in MEC

Bugs Fixed in MEB
Bugs Fixed in release MEA
Bugs Fixed in release MDA
Firmware Filenames and Sizes

Introduction
New Features
Obsolete Features
Compatibility
Bugs Resolved in ACE
Upgrade Instructions
Known Anomalies
Bugs Fixed in ACE
Boot Code Requirements
Unsupported Configurations or Applications.
Notes and Cautions
Firmware Filenames and Filesizes

World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback

Cisco.com
Technical Assistance Center

Cisco TAC Web Site
Cisco TAC Escalation Center

9.3.24 Version Software Release Notes Cisco WAN Switching System Software

About the 9.3 Release

The 9.3 software release supports the Cisco WAN switching products: BPX 8600 series and IGX 8400 series. This release does not support the IPX switch.

Throughout this document, unless otherwise stated, all references to the BXM also include the BXM-E, and references to the UXM also include the UXM-E.

Phased Release Strategy

The MSSBU and CSEBU rollout plans for the 9.3 release is based upon a series of incremental feature releases. This phased feature release strategy is designed to allow the earliest customer availability of key new features, consistent with maintaining high product quality. For the latest status of each 9.3 feature, please see the following information.

The minimum release version noted in the table represents the minimum switch software version required for each feature. As usual, it is recommended that customers use the most current maintenance releases.

Definitions

Software Release 9.3.24

This is a maintenance release including all features supported up to Release 9.3.20.

Software Release 9.3.20

All features are supported up to Release 9.3.10, and the following additional feature is introduced:

1. Universal Router Module (URM) for IGX

This feature introduces a new card for the IGX, the Universal Router Module (URM). It consists of a new front and back card hardware combination that incorporates UXM and router functionality along with the relevant networking capabilities in a single card pair. This feature allows users to provision VoIP and VoATM on IGX switches. The URM card runs standard IOS software, which has been enhanced to support the URM card, and provides the VoIP capability. The URM card also supports VoATM provisioning which is derived from the existing UXM card. The ability to have IOS voice on the IGX is the key capability of this new feature, and the router part of this card can do IP routing by using the two FE ports on the back card.

Note   The following features are not supported in this release of the URM feature: · VoFR (only ATM interface supported on the URM) · VSI support · MPLS LSC/LER support · VoATM support using SVCs · Y-redundancy is not supported for URM cards

Note   There is not a generally available CWM revision that can support or manage the URM cards with Release 9.3.20.

Note   Some changes have been made for the Migration 1B feature, but are not part of this release.

Software Release 9.3.11

This is a maintenance release including all features supported up to Release 9.3.10.

Software Release 9.3.10

All features are supported up to Release 9.3.10, and the following additional features are introduced:

1. Dynamic Partitioning for BPX

Dynamic partitioning enables the addition of a PNNI partition to existing interfaces (both ports and trunks) without affecting any of the existing AR connections on that interface. Dynamic partitioning also enables the expansion of PNNI VPI/VCI range into the AR partition without impacting existing connections. This feature is required to facilitate the migration from AutoRoute to PNNI.

2. Qbin Statistics

In previous releases of the BPX and IGX, only statistics from Qbins 1-9 were collected on AutoRoute trunks. Starting with Release 9.3.10, the switch allows the collection of additional Qbin statistics. Following is a summary of all Qbin statistics collected by the BPX and IGX. Qbin statistics are Cells Served, Cells Discarded, and Cells Received.

All other Qbins are unused and the switch does not provide statistics for them.

Also starting in Release 9.3.10, the switch provides the collection of Qbin Cells Discarded statistics via SNMP for the above mentioned Qbins.

3. ILMI 4.0 for IGX

This feature allows the ILMI 4.0 protocol to be run on the UXM card instead of on an NPM card. The feature can be enabled on a port or virtual trunk basis, but the UXM card requires that the new firmware is loaded to support the new feature.

4. ILMI/ELMI Neighbor Discovery

This feature enables the Cisco Wan Manager (CWM) to discover any ATM devices attached to the BXM or UXM ports on the BPX or IGX switches, provided that those neighbor ATM devices also support ILMI Neighbor Discovery. If the BXM or UXM card supports the ILMI Neighbor Discovery feature, the user only needs to configure ILMI and Protocol-By-Card on the port, then the relay of the neighbor's topology information to CWM is automatic. However, in order to authorize the switch to give out its own topology information to the neighboring ATM devices, the user has to use the cnfport command to enable the Neighbor Discovery Enable/Disable parameter. Use the new command dspnebdisc to display neighboring ATM devices' topology information.

Note   Cisco WAN Manager (CWM) 10.3 is required for Switch Software 9.3.10. However, this version of CWM will not be going GA. When CWM 10.4 is released, it will be necessary for users to upgrade to this version of CWM to be able to use all of the features in this switch software release.

If the switch software version on the node is Release 9.2.x, the following steps are required to upgrade the UXM firmware to revision ACC or later:

Step 2   Upgrade the UXM boot code to boot 8.

Step 3   Upgrade the run-time UXM firmware to revision ABJ or greater.

Step 4   After the card comes up, upgrade the run-time firmware to revision ACB.

Warning If these procedures are not followed, there is a big possibility that the card will enter a state from which it can NOT be recovered. Please refer to Appendix B for more information about loading the new firmware.

Software Release 9.3.05

Introduced the following features:

1. Virtual Port

This feature supports a combination of Virtual Port traffic shaping and connection traffic shaping. The Virtual Port feature allows one or more Virtual Ports per Physical Port interface. Connection- level traffic shaping within Virtual Ports is supported. Although Virtual Ports can connect directly to an ATM edge device or a CPE device, they generally are used to connect indirectly through an ATM network, because direct connections to an ATM edge device or CPE equipment can be done with currently available Physical Ports. A maximum of 31 Virtual Ports is available per BXM card on the BPX. Each Virtual Port supports all AutoRoute traffic types that are currently supported by Physical Ports. (This is a chargeable feature on the BPX.)

Software Release 9.3.00

Introduced the following features:

1. Hitless Connection Density Upgrade for BXM

This feature provides a way to hitlessly upgrade an active BXM (legacy or regular enhanced model)—configured for 16K connections or less—to an enhanced BXM (version DX or EX) configured for more connections (16K or 32K). User traffic is not affected during the upgrade. This BXM connection density upgrade feature provides the customer with the ability to hitlessly scale up their networks using the enhanced BXM supporting up to 32K connections with level 1 channel statistics on the trunk side, port side, or a combination of ports and trunks. The new enhanced BXM card must be configured such that its channel statistics level and number of connections are either equal to or higher than the ones configured on the existing BXM (legacy or enhanced) that it is going to replace. This can be done automatically, based on a configurable option. The upgrade can be done for both Y-redundant and non-Y-redundant BXMs.

2. Support for 3 VSI Partitions

This feature enables support of three (3) simultaneous VSI partitions on a BXM line/trunk interface. With this feature, up to three VSI controllers can independently control the BPX switch by using different partitions of the BXM interface resources including VPI range, bandwidth, and number of connections. AutoRoute is not counted toward these three partitions. An application of the feature is the simultaneous support of MPLS controllers. However, the coexistence of MPLS and PNNI controllers on a node running Release 9.2 or later is not supported.

3. VSI MIB Support

Prior to this release, the BPX software neither kept nor knew the specific information about a VSI controller (for example, type, capability, resource usage, and so on). A network management system is needed to query the controller directly via SNMP to learn such information. This feature enables, via SNMP MIB, an NMS to query the BPX switch for VSI controllers attached to that BPX and the associated information. The feature allows for easier discovery of BPX-attached VSI controllers by external SNMP-capable application (such as CWM).

4. 800 Board-Level Revision Number

The manufacturing board-level revision number, also known as the manufacturing 800 number, provides the maximum information possible about a given card. The ability to remotely identify the manufacturing board-level revision number assists in troubleshooting, maintenance, and sparing. Prior to this release, there was no mechanism to remotely identify the board level revision number without physically removing the card from the slot. This project provides the capability to identify the board-level revision number via CLI, Cisco WAN Manager, or CiscoView for IGX and BPX cards. This feature is currently not available for backcards.

5. Priority Bumping

This feature allows connections for both BPX and IGX that are classified as more important (via COS value) to bump existing connections that are of lesser importance. Priority Bumping is useful when there are insufficient resources (for example, bandwidth) to route these important connections due to trunk failures in the network. (This is a chargeable feature on the BPX).

6. SCR (Sustained Cell Rate) and PCR (Peak Cell Rate) Policing at Less Than 50 CPS on BXM and UXM

With this feature, the minimum SCR and PCR policing values supported by the BXM and UXM are lowered depending on card types:

The policing prompt will be introduced for ABRSTD connections with VSVD=OFF. Previously, policing was always enabled for ABRSTD connections with VSVD=OFF. This change delivers the following advantages for ABRSTD connections with VSVD=OFF.

7. Separate Abort Stack

The software error table on the IGX and BPX currently contains up to 12 entries. When the table is full, additional errors overwrite the last entry. Errors that are not fatal are processed equally with aborts. This means that if an abort is logged into the last entry of the table, an error can then be logged, overwriting the more important abort information. Similarly, if more than one abort is logged when the table is full, only the last one logged remains in the table. This feature allows the preservation of abort stack information which, in turn, allows for faster debugging and fix implementation.

8. Upgrades Protection

This enhancement provides additional protection against running loadrev/runrev and doing upgrades during the time that statistics collection is enabled. This enhancement warns and automatically disables statistics collection if the user says "Yes" to the warning prompt.

9. 2000 VC Bandwidth Parameters

This enhancement increases the maximum number of VC bandwidth parameters from 700 to 2000 on an IGX. This enables service providers to increase service offerings where additional VC bandwidth parameters are required.

10. UXM and UXM-E ATM Forum IMA-Compliant Ports

This feature enables the UXM and UXM-E to support ATM Forum IMA Standard version 1.0 compliant IMA ports in addition to IMA trunks. Support for IMA ports allows the IGX to directly interoperate with other Cisco devices that support IMA ports, and provide a more cost-effective alternative to using an AUSM/B in an SES feeder to IGX to support the same functionality. This IMA functionality complies with the ATM Forum IMA Standard version 1.0.

11. Control Traffic Shaping

This enhancement allows users traffic-exclusive use of available trunk bandwidth. Previously CC Traffic used available trunk bandwidth in excess of statistic reserve at the highest priority, bumping user traffic also trying to claim available bandwidth. This feature also requires the appropriate firmware versions for the cards.

Clarifications for Release 9.3.24

None.

Clarifications for Release 9.3.20

1. Changes in IGX Parameters

dsplns (no options) displays the detailed screen, and queries the user if summary lines need to be displayed

dsplns d displays the detailed screen, and user is not queried for summary display

dsplns s displays only the summary screen, for example:

Line Summary

dsplns <invalid input> user is prompted for a valid input

This command does not query the user for the VC shaping parameter.

This command queries the user for the VC shaping parameter.

For URM ports, the port type is always UNI, and the protocol can be either ILMI or NONE. If ILMI is configured, only Protocol-run-on-the-card is supported.

These changes also apply to the SNMP interface.

---

Note    XLMI and ENNI options are displayed for cnfport and dspport. However, users should note that this is an unsupported feature in 9.3.20.

---

Accepts URM ports.

Accepts URM card type

Added new alarm type for URM router alarm

Supports URM card

This command displays detailed operational information and alarm status for all URM embedded router on a specified router slot.

This command displays a summary of the operational information and alarm status for all URM embedded routers.

This command resets the embedded router in a URM card. This does not affect the embedded UXM.

This command configures the router parameters on a specified URM card slot.

This command displays all the router configuration parameters on a specified URM card slot.

This command displays all the router configuration parameters on a specified URM card slot.

---

Note    For the Migration 1B feature, these commands have been added but are not part of this release.

---

2. Changes in BPX Parameters

This command now displays the type and revision for BXM-E cards.

Clarifications for Release 9.3.11

None.

Clarifications for Release 9.3.10

1. Only the cell discard Qbin statistics for the allowed Qbins are provided via SNMP.

2. Starting with Release 9.3.10 on the BPX, the cnfvsipart command is only applicable to BXM trunks. To enable VSI ILMI on the port, use the cnfport command to enable ILMI and protocol by card. Doing so effectively enables VSI ILMI on the port interface.

3. Changes in BPX Parameters:

Meaning of the Neighbor Discovery parameter:

Y—The BPX sends its interface information to the neighbor if queried by the neighbor.

N—The BPX does not send its information to the neighbor.

The BPX always queries for its neighbor's interface information using the ILMI Neighbor Discovery procedure and reports to CWM if the information is available, whether the Neighbor Discovery parameter is set to Y or N.

User needs to use cnfport command to enable/disable ILMI/VSI ILMI on ports.

This new command is used to display neighboring ATM devices' topology information. This command is added to support the BPX ILMI Neighbor Discovery feature.

4. Changes in IGX parameters:

Meaning of the Neighbor Discovery enable/disable parameter:

Y—The IGX sends its interface information to the neighbor if queried by the neighbor.

N—The IGX does not send its information to the neighbor.

The IGX always queries for its neighbor's interface information using the ILMI Neighbor Discovery procedure and reports to CWM if the information is available, whether the Neighbor Discovery parameter is set to Y or N.

When the protocol is set to ILMI, the meaning of the parameter:

Y—The ILMI protocol is executed by the UXM card.

N—The protocol is executed by the NPM.

Meaning of the parameter:

This new command is used to display neighboring ATM devices' topology information. This command is added to support the IGX ILMI Neighbor Discovery feature.

5. The IMA-added trunk transmit rate can be configured without deleting it. But it is done locally and is not propagated to the other end.

Clarifications for Release 9.3.05

1. Starting with Release 9.3.05 on the BPX, the user needs to execute the following sequence of commands to create an ATM service port or virtual port: upln, addport, cnfport, upport. Previously, only upln and upport were required.

2. Starting with Release 9.3.05 on the BPX, the VC-Shaping parameter is no longer available with the cnfln command. Use the cnfportq command to enable/disable VC Shaping.

3. Starting with Release 9.3.05 on the BPX, the user can configure the port bandwidth. Previously this parameter was defaulted to the line speed.

4. Starting with Release 9.3.05 on the BPX, the user can configure the VC Queue Depth parameter for the CBR and VBR connection. Previously, this parameter was configurable only with ABR-type connections.

5. The restriction of not being able to configure additional VSI partitions if one partition already uses VPI=0 has been removed. VPI is allowed to be 0 for a VSI partition on feeder trunks, in addition to ports. However, since both the PNNI and MPLS controllers uses certain default control channels, users should be extremely cautious with the controller's channels. Side effects of the collisions are unpredictable for BPXs.

6. The addloclp/dellp command cannot be used for port loopbacks on virtual ports. Use addportloclp/delportlp instead.

7. Changes in BPX Parameters:

8. The dsplog command has been enhanced in Release 9.3.05. User-visible changes include:

A counter at the top of the event log indicates both the user's place and the total entries in the event log.

Integrated mode. Integrates a single-line summary of software error and abort log entries into the display (by time-stamp) and are displayed in reverse video. For example:

This can be combined with all of the above options EXCEPT "p". Thus, dsplog i r t, but not dsplog p i t.

Clarifications for Release 9.3.00

1. For the 800-level part number, there is a dependency on manufacturing to release boards with NOVRAM containing an 800-level part number. There are scenarios in which the 800-level part number cannot be seen. See the following chart for the different combinations:

Notes:

2. The dsplog command has been enhanced in Release 9.3.00. User-visible changes include:

Reverses the log, showing oldest entries first. This option allows you to see the bottom of the list quickly.

Allows paging through the log, much like dspcons. For a single page log, this option acts just like dsplog and terminates immediately. But for multiple page logs, it allows you to move backward and forward through the log by pages (using "n" and "p") until "q" or DEL is pressed.

Time-stamp mode. Begins log display with the entry nearest to the specified time. The time parameters must immediately follow the "t" option.

3. The Robust APS Alarm message that the BPX sends to CWM is being modified to contain a new field. CWM converts these Robust APS Alarm messages into SNMP trap 20100. When APS Alarm Clear messages are sent from the BPX to CWM, the resulting 20100 trap contains a new field indicating the alarm condition that is being cleared.

4. Changes in BPX Parameters:

5. Changes in IGX parameters:

Clarifications for Release 9.2

1. There is a change in reporting of the port group number starting in Release 9.2.30. The previous image (MEC) of BXM firmware used to report one port group for the two-port group cards at the channel statistics level 2 and 3. This made the port belonging to the second port group unusable.

When upgrading from MEA-MEC, you must upgrade the software to 9.2.30 (or later) first and then burn the BXM card with the MED (or later) firmware. The BXM reports two port groups for two port cards all the time. The smooth transition between the earlier one-port group and the newly reported two- port groups also displays message in dspcd "Inconsistency with logical PG #" (port group number). All earlier software mismatches the card.

If the BXM card is programmed with an MEC or earlier firmware revision, the Channel Statistics level 2 or 3 reports one-port group. Burning a MED or later image results in two-port groups, but for backward compatibility the software does not recompute the LCNs based on the new port groups. In its logical database, this does not impact the AutoRoute connections.

For a VSI controller, the reported value is higher than the actual available LCNs. That means a VSI controller may not be able to add connections even though the available connections are non-zero. If the user wishes to remove the above discrepancy, the card must be put in the standby mode.

---

Note    The newly configured card, or the card in standby mode programmed with an MED image brought to the active state, does not have the above discrepancy.

---

2. The combinations of system limits such as the number of trunks, lines, ports, and connections, as well as enabled TFTP interval statistics, should be provisioned so that the node has at least 50 percent idle time usage. Use the command dspprfhist to verify.

3. On the BXM and UXM, for the OC-3 Multimode Fiber back cards, Y-Redundancy/hot standby is not supported due to reduced optical power.

4. Release 9.2.31 introduces a new command—cnffdrlmiparms which makes the feeder LMI timers and counters configurable. This command is currently supported on BPX only and cannot be added in the Job mode.

Usage: cnffdrlmiparms slot.port T393 T394 T396 N394 N395

Where slot.port specifies the feeder trunk to configure. The details of the other parameters is as follows:

5. In Release 9.2.31, the system parameter 2 (cnfsysparm 2) is changed from "Fail Connections On Communication Break" to "Allow CPU Starvation of Fail Handler."

The old parameter has been removed as it violated the principle of separating the control and data plane. The new parameter allows a new feature to be turned off that gives CPU to the Fail Handler at the expense of the Transaction Handler in case the Fail Handler does not get scheduled for a long time.

6. The minimum software required to run MPLS are:

or,

Special Installation/Upgrade Requirements

Note   There are no generally available CWM revision that can support or manage the URM card with Release 9.3.20, or support the features in Release 9.3.10.

General Upgrade Procedure

Note   Please consult your Support Representative before performing any software upgrade.

The earliest release supported for a graceful upgrade is 9.2.23.

Before you upgrade the switch software, make sure the cards have the minimum firmware revision per the compatibility matrix.

Procedure for Upgrading BXM cards to the 9.3 Firmware Release

See Appendix A for instructions on upgrading the BXM firmware.

See the Compatibility Matrix for the tested/supported versions of other firmware and software that work with this release.

Procedure for Upgrading UXM cards to the 9.3 Firmware Release

Note   For the VSI/MPLS feature, upgrade the UXM firmware to revision ACC or later. Note that the upgrade procedure has changed.

If the switch software version on the node is Release 9.2.x, the following steps are required to upgrade the UXM firmware to revision ACC or later:

Step 2   Upgrade the UXM boot code to boot 8.

Step 3   Upgrade the run-time UXM firmware to revision ABJ or greater.

Step 4   After the card comes up, upgrade the run-time firmware to revision ACC or later.

Warning If these procedures are not followed, there is a big possibility that the card will enter a state from which it can NOT be recovered. Please refer to Appendix B for more information about loading the new firmware.

If a Switch Software Release 9.3.x has already been loaded onto the node, the following steps are required to upgrade the UXM firmware to revision ACC:

Step 2   Upgrade the run-time UXM firmware to revision ACC.

Procedure for Adding New BCC Cards as a Part of Upgrading to Release 9.3

If new BCC cards are to be installed as part of the upgrade to Release 9.3, then the physical card upgrade procedure described below must be completed as a separate activity from the Switch software upgrade.

Revision Interoperability Supported

The Revision Interoperability feature allows a mixed/ heterogeneous network of 9.2.x and 9.3.x (where "x" equals any GA version of 9.2 and 9.3) nodes to coexist and interoperate. This capability allows customers to upgrade their networks from 9.2 to 9.3 in multiple steps. It is not recommended that users operate in this state for extended periods of time.

Normal network maintenance and operations such as provisioning, trunk reroutes, card insertions and removals, and normal network alarming, are supported in the mixed revision network. Normal alarms can be received while upgrading a node to Release 9.3.

In a mixed-revision network, functions that are implemented in 9.3 but not in 9.2 are disabled. For example, features that are supported in both Releases 9.2 and 9.3 will function at their 9.2 level. New features developed in 9.3 are automatically enabled when all nodes are upgraded to the 9.3 revision level. Specifically, connection provisioning, connection rerouting, alarming and CWM support for these features are supported but will function at their 9.2 capabilities, and not at their 9.3 levels until all nodes are upgraded. The command dspblkdfuncs will display blocked (disabled) features.

Note   The URM card cannot be activated in a network with mixed switch software releases.

Version Compatibility Notes

For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.

This release runs with:

---

Note    MGX 8220 Release 4.1 cannot be used to have an IMA trunk to a UXM Model B card because MGX 8220 Release 4.1 uses a non-standard IMA standard while UXM Model B firmware uses a ATM Forum IMA compliant standard.

---

---

Note    Cisco WAN Manager (CWM) 10.3 is required for Switch Software 9.3.10 or later. However, this version of CWM will not be going GA. When CWM 10.4 is released, it will be necessary for users to upgrade to this version of CWM to be able to use all of the features in this switch software release.

---

Control Card Requirements

All BPX processor cards must be configured with a minimum of 64 MB of RAM, and NPMs must be configured with a minimum of 32 MB of RAM. NPMs require at least 1 MB of BRAM. To verify the BRAM size on IGX 8400 nodes, use the dspcd command.

Control Card Boot Firmware Requirements

As specified below, the correct version of CC boot firmware must be installed on the cards prior to a software upgrade to Release 9.3.

With the new version of NPM boot code (RxS), the boot code upgrading does not require physical card resetting with the following steps:

Step 2   Execute the switchcc command and wait until the NPM(1) becomes standby. NPM(2) is now active.

Step 3   Execute the resetcd command to reset the standby (resetcd 1 h). Wait until the reset card NPM(1) becomes standby.

Step 4   Burn the boot code on the active NPM(2).

Step 5   Execute the switchcc command and wait until the NPM(2) becomes standby. NPM(1) is now active.

Step 6   Execute the resetcd command to reset the standby (resetcd 2 h). Wait until the reset card NPM(2) becomes standby.

Control Card Compatibility Requirements

Each redundant pair of BCC cards in a given BPX 8600 node must be of identical type and memory configuration. That is, for example, if the active card is a BCC-3-64, then so must be the standby. BCC-3 cards with 64 MB of RAM cannot be mixed with BCC-4 cards.

Each redundant pair of NPM cards in a given IGX 8400 node must be of identical type and memory configuration. That is, for example, if the active card is an NPM-32, then so must be the standby. NPM cards with 32 MB of RAM cannot be mixed with NPM cards with 64 MB of RAM. Also, NPM-64 cards cannot be mixed with NPM-64B cards.

This is a requirement for all software upgrade procedures. It does not apply to the physical card upgrade procedure, as described below.

Control Card Physical Card Upgrade Procedure

When performing a Control Card (CC) upgrade, the following procedure must be used. This applies to all processors: BCCs, and/or NPMs.

Step 2   Replace with new CC front and back cards that are identical to the current active CC. (Replacement of back card only applies to BCC.)

Step 3   Wait for the standby updates on the newly installed standby CC to complete.

Step 4   Issue a switchcc command to utilize the newly installed CC.

Step 5   Verify that the network is stable.

Step 6   Remove the current standby CC front and backcard. (Remove back card only applies to BCC.)

Step 7   Replace with new CC front and back cards that are identical to the current active CC. (Replace back card only applies to BCC.)

Step 8   Wait for the standby updates on the newly installed standby CC to complete.

Step 9   The CC physical upgrade is now complete.

Step 10   With the secondary card in the standby state, cause a switchover using the switchcc command. This will test that the hardware is working correctly.

Note   After Step 2, the node will contain a mix of an old type CC and the new type CC. This condition is permitted only while the standby updates to the new CC are in progress, which will take less than one hour. The time during which this mixture of CC types exists must be kept to a minimum by immediately replacing the second old type CC with the matching one of the new type.

Obsoleted

BPX BCC-32 cards are no longer supported in Release 9.3.

The following IGX cards are no longer supported in Release 9.3:

UVM model A, B, and C firmware are not supported in SWSW Release 9.3 and beyond.

Adaptive Voice feature is not supported in IGX SWSW Release 9.3

Notes and Cautions

Additional Notes for Release 9.3.24

None.

Additional Notes for Release 9.3.20

The URM lines are included in the maximum number of lines on the nodes.

Additional Notes for Release 9.3.11

None.

Additional Notes for Release 9.3.10

1. VSI/MPLS controllers should be added on a line and not on trunks. The following steps should be followed:

Step 2   Up the ports by using the upport command.

Step 3   Configure the partition resources by using the cnfrsrc command.

Step 4   Add an MPLS controller by using the addctrlr command.

2. Typical ILMI configuration on the router side should have the following type of information:

interface ATM2/0

IP address 10.9.8.4 255.255.255.0

no IP directed-broadcast

ATM PVC 41 0 16 ILMI

ATM PVC 46 0 5 qsaal

ATM ILMI-keepalive 20

no ATM address-registration

ATM ILMI-PVC-discovery

3. The VPI/VCI for ILMI control PVC should match on UXM port and the neighbor router/IGX/BPX for ILMI protocol to work correctly.

4. Certain parameters for the router configuration would require shutdown and up the router interface using router command "shut/no shut" on the interface to take effect on the modified configuration.

Additional Notes for Release 9.3.05

1. An incompatibility exists between the ASI and BXM implementations of the HCF no-shift mode. As a result, the diagnostic command tstdelay fails for a connection terminating on an ASI and a BXM when the associated ports are configured for the HCF no-shift. Note that the following connection types are not affected by this incompatibility (and thus tstdelay works as expected):

In general, customers should, whenever possible, avoid mixing ASI and BXM ports when the use of HCF no-shift mode is required.

2. When Priority Bumping is turned on, connections are added with a cos value of 15 instead of 0. When Priority Bumping is turned off, all connections except voice connections add with a default value of 0. Voice connections add with a default value of 2. If a different value for cos (other than 15) is desired, use the cnfcos command to change the value.

3. VPI 0 is now supported on a VSI partition even when there are multiple VSI partitions on the interface. This functionality reverses the restriction in the 9.2 release.

4. On the enhanced BXM card (BXM-E), the firmware translates the configured transmit cell rate (cells per second) into a minimum inter-cell gap. The mathematics of this conversion involves non-integer computations, which introduces rounding/truncation effects. As a result, the actual output bandwidth is somewhat larger than the configured bandwidth. This behavior is manifested in certain situations when the bandwidth of a port, virtual port, trunk, or virtual trunk is configured for less than the line rate, and the port/trunk is heavily loaded. The Cisco WAN Switching Command Reference, Release 9.3.05, Appendix A, BXM-E Configured and Actual Bandwidths, contains a table showing the actual output bandwidth versus the configured bandwidth.

Additional Notes for Release 9.3.00

1. Once Priority Bumping feature is enabled, the reroute timer in cnfcmparm (9 Reroute Timer) is recommended to be set to a value of 3 seconds or greater.

The need to do so is to make the bumped connections (connections that are derouted when priority bumping is exercised) wait for this period before they are eligible to route again.

2. The "Adaptive Voice" feature, also known as the "Adaptive VAD" feature, is not supported by the IGX Switch Software. However, Voice Activity Detection, or VAD, is still supported.

Additional Notes for Release 9.2

1. Because of a hardware limitation, the non-enhanced versions of the BXM hardware are not able to recognize all user-programmed cell transmission rates. Rather, only discrete transmission rates can be used.

The equation below shows what the BXM hardware actually transmits given a user-configured cell rate. The transmitted cell rate is always less than or equal to the configured cell rate. To prevent any cell loss, the transmitted cell rate must be equal to the configured rate. To do so, a cell rate must be chosen from the chart that follows.

The rate chart lists the highest 200 cell rates supported by BXM such that if used results in no cell loss (given cell traffic is less than configured cell rate). Additional rates can be calculated using 1470588/[n + (1/256)], where n is an integer.

The logic to calculate the actual cell transmission rate in a BXM card is as follows:

if (configured cell rate = full line cell rate) then

transmitted cell rate = full line cell rate

else

transmitted cell rate = from equation below or from the following chart

Example:

If a trunk is configured at 100,000 cps, the actual transmitted cell rate is then 98,013 cells per second (cps), and any traffic sent over 98,013 cps would be discarded.

If a trunk is configured at 98,013 cps, then the actual transmitted cell rate is 98,013 cps with no cell loss.

Therefore, only rates in the following chart should be used. Otherwise, cell loss may be experienced. The chart is not be exhausted at the end, but still go on with the computing from the above equation.

.

2. On the BPX with MGX 8220 feeder(s), regardless of the setting of the Node Parameter "42 Enable Feeder Alert", a feeder alert message is sent to all MGX 8220 feeders immediately before a hitless rebuild takes place. The feeder alert message temporarily disables the LMI polling from the MGX 8220 feeders. The MGX 8220 polling resumes as soon as the BPX is ready to exchange LMI messages.

3. The amount of traffic allowed on a VP Tunneling connection is two-thirds the bandwidth of that connection. The minimum bandwidth must be 100 cells per second. For example, a CBR connection with peak cell rate 1500 cps then can pass traffic up to 1000 cps.

4. For an IMA trunk, the configuration is blocked if the converted cps of the number of links to be decremented is MORE than the transmit rate (CSCdm71616).

5. Card errors (0x25170076) occur on BXM when only one virtual trunk (VT) is configured in a physical port. To avoid this situation, configure at least two virtual trunks on any physical port that you have VTs on. When performing the configuration, make sure to configure the VTs one directly after the other (CSCdm69974).

Limitations for Release 9.3.24

None.

Limitations for Release 9.3.20

1. No generally available CWM revision can support or manage the URM cards with Release 9.3.20.

2. Y-redundancy is not supported for the URM cards.

3. The UPM card cannot be activated in a network with mixed switch software releases.

4. On URM ports, VPI 0 and VCI 1023 is reserved.

5. The following features are not supported in this release of the URM feature:

Limitations for Release 9.3.11

When an IGX feeder node has a trunk connected to an IGX routing node, the UXM card can go into a mismatch state when the Switch Software is upgraded to 9.3.x and the voice and data connections are terminated on the UXM feeder trunk. The workaround for this limitation is either (1) burn UXM firmware ABK or later, or burn firmware ACB or later onto the card or (2) reset the UXM card. (CSCds85758)

Limitations for Release 9.3.10

1. If ILMI is enabled to run on a UXM card, than no address registration or service registration is supported for ILMI 4.0.

2. When ILMI is running on the cards on a virtual trunk port, all the virtual trunks on the same port share the same ILMI session.

3. The LMI protocol must not run on the BXM cards connected to an Axis shelf. It should run on the BCC cards.

4. Executing a dncd command on a BNI-155 does not turn off the laser on the physical port. As a result, the other trunk end connected to this card still detects a physical layer signal and regards this as a trunk "communication failure" rather than as a LOS (loss of signal). Hence, all connections fail and are not derouted/rerouted by the connection management (AutoRoute or Priority Bumping in 9.3x).

5. ILMI Neighbor Discovery is only supported on BXM/UXM physical ports.

6. An NPM-64B card is required for the VSI feature.

7. Release 9.3.10 does not support the VSI feature in a mixed revision network. All nodes in the network must run Release 9.3.10 or later in order to use the VSI feature.

8. ILMI can be enabled on a UXM card, but it cannot be enabled on the same card as VSI.

9. When an MPLS controller is added to a port, it sets up a signalling channel to the port to which it is attached. The VPI and VCI for this connection are user-configurable. Default values of 0 and 32 are used if the user does not configure different values. So extreme card should be taken before adding an Auto Route connection with VPI = 0. An Auto Route connection should never be added with a VPI and VCI that is being used by the MPLS controller. If an addcon command fails with swerr 9082 (with firmware error code 0x01EF), this means that an attempt was made to add an Auto Route connection where an MPLS signalling VC was already existing. If this error is seen, the Auto Route connection that caused it should be deleted immediately. The way to avoid to getting to this situation is to configure the signalling VC on the router such that it is within the VSI partition. In other words, instead of having the signalling VC as 0/32, configure the signalling VC on X/32 where X is the starting VPI of the VSI partition configuration for the control port interface.

10. The BPX only supports ILMI address registration with a PNNI controller. In the case where the BXM port does not have a VSI partition controlled by a PNNI controller, it is necessary to disable address registration on the attached router. This is to prevent the router from sending unnecessary ILMI cold start trap to the BPX.
Below is an example of how to disable address registration on a Cisco 7200 series router:
interface atm 1/0"
no atm address registration
Refer to the IOS command reference and Configuring ATM on ATM port adapter for further details.

11. Release 9.3.10 supports only MPLS controllers for the IGX. The PNNI controller is not supported in Release 9.3.10 for the IGX.

12. Release 9.3.10 supports only up to 3 controllers (1 controller per partition).

13. Release 9.3.10 does not support controller redundancy for the IGX.

14. Release 9.3.10 does not support compact CBA on slave side, that is the command compactrsrc VSI is not supported for the IGX.

15. Release 9.3.10 does not support Auto UBU allocation for the UXM only. UBUs must be allocated manually for the IGX.

16. For the IGX, when a VSI partition is deleted/disabled, all connections are deleted.

17. If CBR connections are configured with PCR less than or equal to 50cps, CBR cells may be dropped at a BXM trunk interface. Do not add a CBR connection with the PCR less than or equal to 50 cps. Using CBR connections with the PCR greater than or equal to 51 cps does not cause any cell drops.

Limitations for Release 9.3.05

None.

Limitations for Release 9.3.00

1. Level Version Number is supported for front cards only.

2. Standards-compliant IMA ports (MGX 8220, Release 5.x) on UXM/UXM-E are not compatible with the proprietary protocol used in the IMATM (MGX 8220, Release 4.x).

3. Standards-compliant IMA trunks are not compatible with the proprietary IMA protocol used in Model A UXM firmware. Model B and later firmware releases are IMA standard-compliant. Both ends of an IMA trunk must have the same protocol.

4. Switch software 9.3.00 and BXM firmware MFB support the attachment of multiple VSI controllers to the BPX. In case of MPLS, however, only one LSC should be attached to a VSI partition, which is the same for the IGX. If multiple LSCs are attached to a VSI partition, the results are unpredictable, which is the same for the IGX.

5. On BXM OC-3, OC-12 8DX, and 2DX enhanced cards, do not configure the queue depth(s) for CBR / rt-VBR / nrt-VBR / UBR/ABR to be greater than 262143 using the cnfportq command. All configuration changes made while or after configuring queue depth(s) greater than 262143 are lost after a rebuild, when the switch is running 9.3.00. All ports, whose queue depth(s) are configured to be greater than 262143 in 92 are lost after upgrading from 9.2 to 9.3.00.

6. When doing a grouped upgrade from Release 9.2 to 9.3, the software error 1427 may be logged on the BPX/IGX node during a non-graceful upgrade. This error can be ignored since it is harmless to the network.

7. When upgrading from Release 9.2 to 9.3, the 9.2 statistics on BXM/UXM cards are supported to maintain compatibility. However, once users configure a statistics level in 9.3, they cannot configure back to 9.2 statistics.

Prior to replacing a bad BXM/UXM, make sure that the level of channel statistics is the same as the original card.

Limitations for Release 9.2

1. The coexistence of MPLS and PNNI controllers on a node running Release 9.2 or later is not supported.

2. When cnfrsrc command is used to delete VSI partitions on an interface, software does not check if any Soft Permanent Virtual Circuit (SPVC) connections exists on that partition. Even if there are SPVC connections on a partition, the partition can be deleted using the cnfrsrc command. The only protection is that users are provided with a warning when they try to delete the partition.

If there are SPVC connections on a partition and the partition is deleted, the SPVC connections are left in a undefined and unrecoverable state. Hence, before deleting a VSI partition, ensure that all the SPVC connections are deleted on that partition.

3. The cloud port to which a virtual trunk is connected should have ILMI polling disabled. Otherwise, it could lead to a virtual trunk being clear on one end and declaring Virtual Trunk Path Failure at the other end (CSCdm52909).

4. For performance reasons, AIS connection status is not sent to the standby BCC. After switchcc, it may take a few minutes to update the AIS connection status. If dspcon does not show the proper status of AIS or the dspalms screen shows the incorrect number of AIS, (after switchcc) wait a few minutes until the status gets updated. (the dspalms and dspcon commands show the status of AIS.)

5. Hitless Rebuild has similar limitations to that of a switchcc and full rebuild:

6. UVM cards in Y-redundancy mismatch if one is burned with Idle Code Suppression Firmware and the other is not.

When installing/burning Idle Code Suppression Firmware on UVM pairs, the Y-redundancy must be removed, firmware in both UVM cards burned, and then the Y-redundancy can be restored.

7. Mismatch is reported when replacing a BXM card with another BXM card that has a different Port Group, even though both BXM cards have the identical channel number.

8. Care must be taken when changing the Deroute Delay parameter, which is controlled by the cnftrk command. This defaults to zero, but if set to anything but zero, connection rerouting, due to a trunk failure, is delayed as provided by the parameter.

9. To provide ABR service on a connection, set up an ABRSTD connection, enable VSVD and enable FCES to allow RM cells to be passed to and from customer equipment. The MCR for such ABRSTD connection can be set at any user-desired value.

When the network is experiencing congestion, all the affected ABRSTD connections, regardless of the services (ABR or UBR) they are carrying, are all throttled back at the VSVD points at the network edge. During network congestion, connections carrying UBR services are virtually stopped (to a through-put of mere 6 cps) while connections carrying ABR services can send at a much higher, user desired MCR. This option would avoid the situation where UBR service gains an unfair advantage over ABR service while sharing the same CoS queue.

10. Reconfiguring the trunk parameter may cause the connection to be rerouted if the changed bandwidth load is smaller than what was used by the connections that use the trunk.

11. The BXM and UXM channel stat-level feature gives these cards the capability of collecting more than 4 statistics per connection. However, it is the controller card's limitations, available memory and performance, that indicates how many statistics can actually be collected from the cards and then reported to the Cisco Wan Manager (CWM).

The BCC-3-64 can collect at most three interval statistics per connection when there are 16,000 AutoRoute connections configured on the node. (Interval statistics are those statistics that are reported to the CWM. They are often referred to as TFTP statistics.)

You can collect approximately 48,000 statistics (3 x 16,000) on the BCC-3-64. This is approximate because there are many variables that affect this value such as: are peaks enabled, how many buckets are collected, are all connection of the same type, are trunk, line, or port enabled, and so on

With this approximation of 48,000 statistics on the BCC-3-64, this then means that, as a rough estimate, you could enable 32 stats on 1,500 connections, 48 stats on 1,000 connections or 9 stats on 5,000 connections, and so on The approximation formula being:

max_stats_per_connection = 48,000/number_of_connections

12. The transmit rate on an IGX IMA trunk can be altered at the local node without any trunk outage. It is possible that the transmit rates are different at the two ends of an IMA trunk. After this trunk is deleted, it cannot be added back unless the transmit rates are the same.

Limitations for Release 9.1

1. The maximum number of VC PARMs supported:

In other words, one less than the stated maximum value.

VC PARMs are Virtual Circuit Parameters combinations/sets. One set of VC Parameters is used for each unique Virtual Circuit that has been provisioned. Identically provisioned VCs (exclusive of endpoints) use the same set of parameters.

Limitations for Release 8

1. If LMI/ILMI is provided by the BCC:

The maximum possible number of ports on the BPX 8600 that can be configured with LMI/ILMI enabled is 52. However, each BPX supports up to a total of 16 feeder trunks and each feeder trunk has LMI enabled. That is, if a BPX 8600 is configured with only two feeder trunks, then only (52 - 2) = 50 ports can have LMI/ILMI enabled.

If LMI/ILMI is provided by the BXM firmware:

2. Virtual Path Connections with cells whose VCI values are above 4095 are transmitted correctly only if the path is exclusively through BXM trunks and terminates at BXM ports.

3. The feature of CIR=0 for Frame Relay connections is not supported for connections terminating between FRM cards in IGX nodes and FRSM cards in an MGX 8220 shelf.

4. SVC Voice Connections are derouted after decreasing the allocated bandwidth (increasing Statistic Reserve). It is the design intent that increasing the statistical reserve causes SVC conns to be derouted and not be rerouted.(See bug CSCst92308).

5. For the loadrev operation, it is important that the Cisco Wan Manager/TFTP buffers are maintained at their default size.

6. Due to a hardware limitation, the BNI trunk sends 13 to 15 percent more traffic than what it is configured for when the trunk is configured for less speed (cps) than the maximum port speed. This is especially important when the BNI trunk is connected to IMATM pairs, which carry less than T3 bandwidth.

7. When using the shift/no-shift feature on a BPX 8600 node's port card, controlled via the cnfport command, the other end of the connection must have the same setting. Otherwise, there is a loss of continuity.

8. The external ABR segment control loop on ForeSight (ABRFST) is an option at the User Interface. It is supported by UXM-E/BXM-E (enhanced versions), but is not supported by UXM/BXM hardware. The user should not enable this option on ForeSight connections (CSCdi92451). In any case, there is no coupling between the loops.

9. The interface between a BXM feeder trunk and an MGX 8220 feeder is always considered to be an NNI interface (CSCdj16808).

10. When adding more than 4000 connections on a BPX node, the VC polling rate must be changed to a higher interval, to accommodate the additional time needed to poll for the statistics for each VC. The cnfsysparm command, parameter 24 must be changed according to the following:

11. Because the detailed card error event log is not retained within BRAM, this information is lost should a processor rebuild occur. Therefore, when issuing a dspcderrs command on a particular slot, the display does not show the detailed card error information should rebuild event occur. This functionality has not been modified from previous releases.

12. When a physical-layer failure (for example, LOS) is detected on the BXM, a Major Alarm is generated, and any connection routed over that port is downed (Fail state). The software sends a command to the remote end of the connection to generate AIS in the egress direction. (CSCdj30543).

Impact:

Since the connection is in a failed state, AIS is generated in the upstream direction (in addition to the downstream direction). Although this does conform to the letter of the I.610 standard, this is not necessarily what a user would expect to see, because it interferes with the RDI response from the end-to-end connection termination point. (A fault in the downstream direction causes a fault in the upstream direction.)

Reason for the current implementation:

The BNI cannot generate AIS. If there is a fault at a BNI trunk, the current mechanism is to cause AIS to be generated by the BXM port by downing the connection. Since the BXM can generate only OAM cells from the RCMP, and the RCMP is in the ingress path, the cells must be backward routed to the egress (egress QE). Also, since end-to-end OAM cells are required, the ingress QE must be configured to drop ALL cells in the ingress path. This creates a break in continuity in the opposite direction, and AIS cells must also be generated at the other end of the same connection, in the upstream direction of the original fault.

13. There are problems in the fallback mechanism that can cause database corruption. If fallback is performed immediately after upgrading, the Stby_Info revision fields are not yet filled in on the new active CC. They don't get filled in until there is an upcard response from the new locked CC. This causes restart instead of a switchcc. If the locked CC is reset, then fallback immediately, a restart occurs instead of a switchcc (CSCdj30811).

14. In order to test/simulate the Y-redundant switchover of ASI T3 or E3 pairs, the resetcd command must be used, or by pulling out the active card. It is not be correctly simulated by doing a dncd (down card) on the active card. Using dncd causes cell discards. (CSCdj08923).

15. UBR traffic gains an advantage over ABR traffic when UBR and ABR PVC's are combined on the same network. This is because UBR and ABR PVC's share the same Qbin (Class of Service Queue) on the BXM card. ABR PVC's use a flow control mechanism, VSVD, which ensures that traffic sources slow down when the Qbin usage exceeds the EFCI threshold. However, UBR PVC's do not have this throttling mechanism. Therefore, ABR is throttled back, whereas UBR is not. This unfair advantage is not considered a problem, since the decision to share a Qbin for ABR and UBR traffic was intentional. Any best-effort service that one would route over UBR can be routed over ABR(VSVD), with the additional benefit of protecting resources in the network. If UBR and ABR PVC's are required then:

Option 1—Consider adding all best-effort PVC's as UBR or

Option 2—Isolate the ABR and UBR paths by using cnfpref command to ensure that ABR and UBR PVC's do not share the same queues.

Option 3—To provide UBR service on a connection, rather than setting up a UBR connection, do the following:

Step 2   Enable VSVD

Step 3   Disable FCES (Flow Control External Segment)

Step 4   Disable DEFAULT EXTENDED PARAMETERS

Step 5   Choose policing option "4" to allow access as UBR.1 (PCR policing only). This connection has ABR VSVD in the network and allows UBR.1 access. The MCR for such ABRSTD connection may be set at the minimum acceptable value of 6 cells per second (explained later why to do so).

16. Combining Frame-Based Traffic Control (FBTC) and non-FBTC connections within a Class of Service can cause FBTC connections to not receive a fair share of bandwidth. For example, if VBR connections are added at a terminating port, and some of these VBR connections have FBTC enabled while other VBR connections have FBTC disabled, the VBR connections with FBTC disabled may obtain all of the excess bandwidth before the connections with FBTC enabled receive any of the excess bandwidth. The same holds true for ABR or UBR connections. This only is relevant where FBTC and non-FBTC connections share a Qbin, either at a port or at a trunk.

Required Workarounds for Release 9.1

1. When adding a node into an existing network, ensure that its node number is unique prior to actually adding it into the network. Use the rnmnd command, and renumber the individual node while it is still stand-alone. This makes the joining of this node much simpler, and avoids the problem of node renumbering an active network, as described below.

Required Workarounds for Release 8

1. There is a problem with node renumbering. Node renumbering (the rnmnd command) should be executed only during a stable network environment and only if absolutely necessary. A stable network environment would be, for example, one in which no connection was added for the past 30 minutes and no topology change was made in the last hour and there are no alarms or node unreachabilities. Node renumbering must be done only when the network is stable to reduce the possibility of certain temporarily blocked messages during the node renumbering process being delivered to the wrong nodes. This would occur after the completion of the node renumbering process. It is recommended that a node be renumbered prior to being added to the network.

2. The settling time for network-wide updates can take a long time in certain situations, specifically, the settling time for updates due to network-wide topology changes and connections in a large network when a processor switchover occurs. The time is proportional to the number of nodes as well as the number of connections. A general estimate would be 30 seconds per node. During the period of transitions (when the updates are occurring) some network operations such as adding connections might, in some cases, take somewhat longer to complete.

3. When using Cisco Wan Manager, there could be a problem with communicating with a node that just had a processor switchover. The problem is within the SPARCstation itself and its caching of EtherNet addresses. It can be solved by execution the following command on the workstation as the superuser: # arp -d <node_name>

4. Users may not use the command addcon slot.1-24 v to add 24 voice connections to a CVM/UVM at once. Instead, they must separate this activity into two or more commands, so that no more than 16 connections are added at once. This is an issue only for voice connections. Data connections can be added using the "1-24" syntax. This also applies when the CVM/UVM circuit line is an E1, in which case "1-32" would apply (CSCdj14319).

5. When a switchcc is executed on a BPX 8600 configured with two BCC-4 cards and contains a BXM-622 trunk card, there may be a bad clock path problem reported. It is indicated as a Minor Alarm—bad clock path. This is a transitory problem, although the alarm indication persists. To clear this, execute the clrclkalm command.

Additional Documentation

In order to take advantage of the dual SIU when upgrading to the BCC-4, the BPX 8600 node must have a new backplane that has dual traces incorporating with the BCC-4.

The command dspbpnv can be issued to verify if the node had the new backplane or the old backplane. The following table details the bit fields for the BCC Backplane NOVRAM format, the display of word 2 describes the backplane type.

The command cnfbpnv can be used to configure the backplane, if backplane is so enabled.

The peak intervals are controlled to be only those values for which peaks can be accurately collected The rules for peak intervals are as follows:

Compatibility Notes

For a complete list of firmware revisions supported, see the Compatibility Matrix document, which is included in this release package.

This release runs with Release 4.1.0x or 5.0.0x of the MGX 8220.

Compatibility Matrix

MGX 8220 Firmware Compatibility

MGX 8850 1.1 Firmware Compatibility

MGX 8230 1.1 Firmware Compatibility
MGX 8250 1.1 Firmware Compatibility

BPX 8600 Firmware Compatibility

IGX 8400 Firmware Compatibility

Note   For the VSI/MPLS feature, the UXM firmware needs to be upgraded to revision ACC or later. The upgrade procedure has changed.

If the switch software version on the node is Release 9.2.x, the following steps are required to upgrade the UXM firmware to revision ACC or later:

Step 2   Upgrade the UXM boot code to boot 8.

Step 3   Upgrade the run-time UXM firmware to revision ABJ or greater.

Step 4   After the card comes up, upgrade the run-time firmware to revision ACC or later.

Warning If these procedures are not followed, there is a big possibility that the card will enter a state from which it can NOT be recovered. Please refer to Appendix B for more information about loading the new firmware.

If a Switch Software Release 9.3.x has been loaded onto the node, the following steps are required to upgrade the UXM firmware to revision ACC:

Step 2   Upgrade the run-time UXM firmware to revision ACC or later.

Note   IGX-UVM model E is a super set of models A, B, and C firmware. A, B, and C are obsolete and should not be used.

MGX 8220 5.0 Hardware Compatibility

BPX 8600 Hardware Compatibility

IGX 8400 Hardware Compatibility