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.30
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.30
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.3.30
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.30
Switch MIB changes of Release 9.3.11, 9.3.20 and 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 MFN
Front Cards
Front Card for APS Compatibility
Back Cards
New Features supported in BXM Firmware MFN:
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 MFN
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 ACF
Upgrade Instructions
Known Anomalies
Bugs Fixed in ACF
Boot Code Requirements
Unsupported Configurations or Applications.
Notes and Cautions
Firmware Filenames and Filesizes

Introduction
New Features
Obsolete Features
Compatability
Bugs Resolved in XBA
Upgrade Instructions
Known Anomalies
Bugs Fixed in XBA
Boot Code Requirments
Unsupported Configurations or Applications
Notes and Cautions
Firmware Filenames and Sizes

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.30 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 rollout plan 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.30

This release includes all features supported up to Release 9.3.24. With Release 9.3.30, the BPX and IGX switch software supports several new features. An overview of each feature is presented in the following sections.

1. URM BC-2FE Back Card on the IGX

Release 9.3.30 provides support for the new BC-2FE back card for the IGX Universal Router Module (URM). The BC-2FE back card provides two Fast Ethernet (FE) ports that support 100 Mbps Ethernet. The URM front card and BC-2FE back card combination supports IOS-routing functions only. The URM front card and BC-2FE2V back card combination introduced in Release 9.3.20 continues to support both IOS-based voice and routing functions.

There are a couple precautions regarding the use of the BC-2FE back card.

For more information about BC-2FE card, refer to the Cisco IGX 8400 Series Provisioning Guide.

The CLI commands modified to support the new URM BC-2FE back card are listed below.

2. URM VSI Support on the IGX

Release 9.3.30 introduces support for the Virtual Switch Interface (VSI) feature on the IGX URM. The VSI feature and usage on the URM is the same as for VSI on the UXM interface card, except that the URM does not support trunks, or IMA lines and trunks. An NPM with 4M BRAM and 64M RAM is required to support this feature. Existing CLI commands are used to configure VSI on the URM embedded ATM port. These commands configure the VSI controller, VSI slave, VSI partition, service class template (SCT), and VSI Qbin statistics. The IOS CLI VSI xtag commands are used to configure the URM embedded router.

3. URM Remote Router Configuration Feature on the IGX

The Release 9.3.30 Remote Router Configuration feature allows you to start up the URM embedded IOS router with an IOS configuration file that is downloaded from a TFTP server and stored in the URM Admin flash. In order to use this feature, all nodes in the network must be running Release 9.3.30 or higher. This feature eliminates the need to have console access to the embedded router to perform initial configuration. Once the IOS configuration file is stored in the URM, it can be used repeatedly upon router reset or restart. The IOS configuration file can have a configuration to enable access to the router from standard TCP-based applications, such as telnet, FTP, and TFTP. The maximum file size for the router configuration file is 256K and the maximum file name length is 32 bytes.

The new and modified CLI commands used to support the URM Remote Router Configuration feature are listed below.

4. TFTP Configuration Save and Restore Feature on the BPX and IGX

In releases prior to 9.3.30, the configuration save and restore facility used a proprietary protocol for communication between the nodes and CWM only. With the Release 9.3.30 TFTP Configuration Save and Restore facility, the standard TFTP protocol can be used to backup configuration files to a network server other than CWM. The TFTP server can be any machine that is accessible to the network and is used to store configuration files. Configuration files that are saved using the TFTP method can be restored using the proprietary method, and vice versa, as long as the files are stored in the correct directory with the correct file names assumed by the proprietary protocol. In order to use this feature, all nodes in the network must be running Release 9.3.30 or higher.

The TFTP Configuration Save and Restore facility includes a TFTP Start file interface for initiating a configuration save and restore request. The TFTP Start file naming convention is:

Upon receipt of the TFTP Start file, the node drives the save and restore process in the same manner as it does with a CLI or SNMP request.

The default number of simultaneous sessions is 4, but the feature allows for up to 15 simultaneous TFTP Save/Restore operations. Use the default, then slowly increase the number of sessions to guard against any traffic congestion problems in your network(s).

The TFTP Configuration Save/Restore feature requires that all nodes in the network run software releases 9.3.30 or greater.

The TFTP Configuration Save operation requires that the following directory and files are created on the TFTP server prior to initiating the Save operation on the switch. Also, these directory and files have to have Read, Write, Execute permissions turned on for everybody.

Directory:

The general format of the directory is "pathname/<backup_id>_Cfgdir. For example, /usr/users/svplus/<backup_id>_Cfgdir. The pathname "/usr/users/svplus" can be different from this example. However, the "<backup_id>_Cfgdir" part has to follow the format in this example. Where the backup_id is the name given by the user to the saved configuration.

Files:

Create the following empty files in the directory:

D1.<nodename>.cfg

D1.<nodename>.000

D1.<nodename>.001

Nodename is the name of the node for which the configuration is to be saved.

The new and modified CLI commands used to support the TFTP Configuration Save and Restore facility are listed below.

Note   The TFTP Configuration Save and Restore facility also includes an SNMP interface for initiating configuration save and restore requests and reporting errors and status. This new interface allows the use of other network management platforms running SNMP managers for driving network management functionality in the WAN.

5. Trunk Incremental CDV Feature on BPX and IGX

The Release 9.3.30 Trunk Incremental CDV feature reduces the transmission latency introduced at the egress port of a voice or NTS connection when the connection traverses one or more virtual trunks.

In order to maintain end-to-end bit transparency for voice and non-timestamped (NTS) data connections, the system must know the worst-case cell delay variation (CDV) that may be experienced by a cell as it traverses the network. The system creates an egress de-jitter buffer large enough to cancels the worst-case CDV on each connection.

Most delay components through the network are fixed, i.e., all cells experience the same delay. Only the queuing delay experienced on a trunk may be different from one cell to another. The worst-case CDV caused by the variable queuing delay for a point-to-point leased line trunk is easily calculated as a function of the trunk transmit queue sizes and the trunk transmit rate. Unfortunately, the worst-case CDV on a trunk which is carried as a VP through an ATM service provider's network cannot be calculated by the BPX/IGX software.

Consequently, in prior software releases, the BPX/IGX software would assume the largest possible value of CDV for virtual trunks. Thus, the egress de-jitter buffer for any voice or NTS connection carried over a virtual trunk was set to a very large value, adding delay to the connection which was often unnecessary.

With this feature, instead of assuming the maximum possible CDV for a virtual trunk, the BPX/IGX system allows the network administrator to specify the incremental CDV of a trunk which results from the ATM service, based on the type of VP service used for the trunk (CBR, rt-VBR, nrt-VBR, etc.) and CDV information that may be provided by the ATM service provider. In this way, much more realistic CDV values are used, resulting in more reasonable (i.e., smaller) egress de-jitter buffers for voice and NTS connections carried on virtual trunks. The feature allows the explicit configuration of the incremental CDV for both virtual and non-virtual trunks to accommodate the case where a non-virtual trunk uses an ATM service provider's VP service.

The configured incremental CDV for each trunk is added to the calculated CDV (based on the trunk transmit queue depths and the trunk transmit rate) to derive the effective CDV. The effective CDV is used during connection routing to ensure that the CDV tolerance specified for the connection (in cnfsysparm) is not exceeded. The effective CDV is also used to derive the de-jitter buffer size at the egress ports.

The incremental CDV is specified in units of 125 microseconds. The incremental CDV value is restricted such that the sum of the incremental CDV and the calculated CDV (based on the trunk transmit queue depths and the trunk transmit rate) does not exceed 255 units of 125 microseconds.

When changing the voice queue depth or the NTS queue depth, the acceptable range is restricted such that the sum of the incremental CDV and the calculated CDV does not exceed 255 units of 125 microseconds.

The incremental CDV is defaulted to 0 for every trunk during upgrade, as well as when a new trunk is added.

The CLI commands modified to support the Trunk Incremental CDV feature are listed below.

6. xCRC-4 Error Detection Feature on the IGX

ITU-T recommendation G.704 provides for the optional use of a 4-bit CRC to report errors in the E1 framing structure. The Release 9.3.30 CRC-4 Protection feature allows you to enable/disable the CRC check on multiframed UXM E1 trunks and lines.

The CLI commands modified to support the CRC-4 Protection feature are listed below.

7. AIS OAM Recognition Feature on BPX and IGX

With the Release 9.3.30 AIS OAM Recognition feature, virtual trunks recognize receipt of end-to-end F4 OAM AIS alarms from the ATM service provider. Prior to Release 9.3.30,virtual trunks recognized ILMI traps/responses as a source of Virtual trunk path failure.

The AIS OAM Recognition feature is provided on BPX BXM and IGX UXM cards only. Virtual trunks in a VP-Tunnelling configuration (IGX) do not support this feature.

The absence or presence of ILMI support from the ATM service provider does not affect the functionality of detecting F4 OAM AIS. Similarly, absence or presence of AIS indication from the ATM cloud does not affect the functionality of ILMI.

The Virtual Trunk Path Fail states have been expanded to distinguish between failures due to ILMI and AIS. The trunk states now include:

This feature provides a new entry point into the Virtual Trunk Path Failure alarm. Consequently, more connection rerouting may occur. You can use the cnftrk Trunk Deroute Delay timer to avoid excessive rerouting during brief outages.

The CLI commands modified to support the AIS OAM Recognition feature are listed below.

8. Virtual Trunk Clock Source Synchronization Feature on BPX and IGX

With the increased use of virtual trunks in Wide Area Networks, it is required that the clock source be derived from the ATM service provider for network synchronization. The Virtual Trunk Clock Source Synchronization feature associates the network clock source with the physical interface, rather than the virtual interface. This enables the use of all configurable virtual interfaces available on a physical trunk port as clock sources. When a virtual trunk fails, the clock source is not switched to another physical interface or internal clock source if there is another active, clock configurable virtual interface on the physical interface. This means that if at least one virtual trunk interface is up without any failure, the physical interface remains a sustainable clock source. This feature has no effect on regular, non-virtual trunks.

When a virtual trunk port is configured for clock source, the first virtual trunk interface on the trunk port is internally marked as the clock source. If the first virtual trunk interface on the trunk port fails, or becomes unusable as the clock source, the node searches for the next active virtual trunk interface that is usable as a clock source and marks that interface as the clock source. This virtual trunk search mechanism allows the clock source of the node to be associated with the physical trunk port rather than the physical interface. The clock selection mechanism within the same trunk port is transparent to the other nodes in the network, including the highest numbered node.

The CLI commands modified to support the feature are listed below.

9. 800 Part Number Support for Back Card Feature on BPX and IGX

This Release 9.3.30 feature enables display of the 800-level part number (also referred to as the Top Assembly Number, or TAN) for selected back cards. The 800 part number provides information about the back card that can assist with trouble shooting. Only back cards used by the following front cards provide 800 part number support:

The 800 Part Number Support feature is not provided on controller back cards. Additionally, this feature does not provide the capability of writing the back card 800 part number on the IGX.

The CLI commands modified to support the 800 Part Number Support for Back Card feature are listed below.

10. Virtual Port ILMI Enhancement on the BPX

The Virtual Port ILMI enhancement enables selection of the ILMI link management protocol on a BXM physical interface configured with virtual ports. Prior to Release 9.3.30, the ILMI protocol applied only to physical ports. LMI continues to be supported on BXM physical ports only.

Although ILMI can be enabled on the virtual ports, there is only one ILMI session per physical interface; meaning, an ILMI session only runs between the BXM physical interface and the ATM device to which it is directly connected. Similar to the existing ILMI implementation on the physical ports, the ILMI session on the BXM interface with virtual ports does not process incoming connection status traps.

ILMI configuration performed on one virtual port applies to all virtual ports on the same physical interface. When the protocol is enabled on a virtual port, ILMI processing is done only on the BXM card. You cannot configure the protocol to run on the controller card (BCC) with virtual ports.

The ILMI Neighbor Discovery feature on the BXM interfaces with virtual ports is only supported at the BPX switch level. There is currently no Cisco Wan Manager support for this feature. The cnfport CLI has been modified to allow users to configure ILMI on a virtual port.

11. Concurrent Routing on the BPX and IGX

The Release 9.3.30 Concurrent Routing feature allows multiple route requests to be concurrently active on a node. This feature shortens network settling time (the time required for all connections in the network to reroute) by allowing multiple route requests to be accepted and serviced without blocking.

The maximum total number of concurrent routes is eight, and the maximum number of master routes is two. The second instance of the master route has to be path orthogonal to the first master route (i.e. with non-overlapping path). If the master node fails to find the second eligible route after a number of tries, it gives up the second route attempt—the second route is path blocked.

Concurrent routing also supports CPU throttling, a mechanism used to temporarily reduce routing concurrency when CPU utilization exceeds a defined threshold. The threshold is set by the cnfrrcpu command.

CLI commands modified to support the Concurrent Routing feature are listed below.

12. 60K Channel support for VSI on the BPX

The Release 9.3.30 60K channel support for VSI feature provides the capability to support up to 60K channels for VSI connections on trunk side, port side, or a combination of trunks and ports. The enhanced BXM-E card models DX and EX support up to 60K channels per card slot. In contrast, pre-release 9.3.30 switch software specifies that the total number of channels used by AutoRoute and VSI connections cannot exceed 32K. The maximum supported AutoRoute channels remains at 32K.

To upgrade a BXM-E card slot with 32K channel configuration, you can execute the new upgdvsilcn command. If you have a BXM card slot, and want to configure that slot to use the 60K channels feature, you have to follow the procedure for "Hitless Upgrade of BXM to BXM-E" documented in Release 9.3.00, then execute the new upgdvsilcn command.

Channel statistics level 0 or 1 is required for feature operation. If you execute upgdvsilcn with channel statistics levels 2 or 3, you receive the following error message: "Logical card does not support 60K LCN for VSI." Use the cnfcdparm command to specify the channel statistics level.

The new and modified CLI commands used to support the 60 channel support for VSI feature are listed below.

13. F4 to F5 Mapping Feature on the BPX

The F4 to F5 Mapping feature allows end-to-end OAM cell flow on a multi-segment PVC to enhance end-to-end connection management. The feature allows the path level OAM (F4 AIS) cells arriving at the VCC/VPC interface to be mapped to channel level OAM (F5 AIS) cells for all the VCC segments at the interface with the same VPI value. The VPC is provisioned by the ATM service provider. The VCCs are terminated at the BXM line port, which is the VPC/VCC interface. When the F4 to F5 Mapping feature is enabled on a BXM port, the BXM is programmed to detect F4 AIS for all the VPIs for which VCCs exist on that port. Consequently, F4 to F5 mapping is configured on a logical port basis. Mapping is not configured for VPIs on a logical port.

The modified CLI commands used to support the F4 to F5 Mapping feature are listed below.

14. Automatic Routing Management to PNNI Migration

Release 9.3.30 supports the first phase of the Automatic Routing Management (AR) to Private Network-to-Network Interface (PNNI) migration. This release enables the introduction of PNNI networking software and MGX 8800 series routing switches into existing networks comprising BPX 8600 series routing switches running AR networking software.

The BPX 8600 supports both an Extended Permanent Virtual Connection (XPVC) and an Extended Permanent Virtual Path (XPVP) that spans over an AR-PNNI, or AR-PNNI-AR, hybrid network. This document concentrates on Extended Permanent Virtual Connections (XPVCs). Each XPVC can contain up to five segments that support various combination pairs of FR, ATM, and RPM endpoints. Each XPVC may contain feeder nodes such as MGX 8220, MGX 8230, MGX 8250, and Release 1 MGX 8850.

The UNI or NNI interface on each XPVC segment is enhanced and called Enhanced User-to-Network Interface (EUNI) or Enhanced Network-to-Network Interface (ENNI). The EUNI/ENNI allows segment OAM loopback cells to start from an edge of the hybrid AR-PNNI network and traverse through the multiple XPVC segments. When a fault is identified, CLI commands described in this document can be used at each EUNI/ENNI point to loopback OAM cells. Cisco recommends you use the Cisco WAN Manager (CWM) application to set up multi-segment OAM loopback. This OAM segmentation capability supports fault isolation in the AR-PNNI network.

With Release 9.3.30, the BXM card supports an Extended Local Management Interface (XLMI) protocol. The XLMI protocol enables the exchange of connection status and Neighbor Discovery information between the BPX and MGX switches in the AR-PNNI hybrid network.XLMI supports D bit, meaning that if a segment is automatically deleted, an AIS is sent to the Customer Premises Equipment (CPE). Abit operational status is not exchanged.

The CWM combines the XPVC segments into a single connection for simplified management. CWM must be used to add, modify, or delete a multi-segment XPVC (using the SNMP Service Agent proxy along with provided CWM-XPVC-CLI scripting capability). CWM must also be used to display the XPVC connection details. The CWM initiates test delay procedures and monitors the connection endpoints at the edge of the AR-PNNI network. CWM receives connection information from each network segment and reports the XPVC connection status.

The Release 9.3.30 AR-PNNI networking feature is compatible with the following network components:

The following PVC endpoints are eligible on the AR network edge:

All connections supported on BPX software Release 9.3 with the above endpoints are supported in the AR-PNNI hybrid network. All feeders supported on BPX software Release 9.3 are supported in the AR-PNNI hybrid network.

The following network components are not supported:

The XLMI protocol only runs on the BXM card and is only supported over the AR-PNNI link.

The following features are not supported in Release 9.3.30:

The modified CLI commands used to support the AR-PNNI migration feature are listed below.

15. Network to Endpoint Connectivity Verification and Round Trip Delay Measurement

The network to endpoint loopback connectivity verification feature tests the data path for a connection from a BPX switch by generating and detecting end-to-end OAM loopback cells. You can verify the connectivity from the network to a PVC endpoint or a PVP endpoint, depending upon the type of connection on which the test is issued from the BPX switch. Unlike the command tstdelay, which tests connectivity "inside" the network, the new command tstpingoam tests connectivity going "out" of the network.

New command tstpingoam: This new command is used to test the network to endpoint (CPE) connectivity of a connection using end-to-end OAM loopback cells.

The tstpingoam command is useful for troubleshooting in a multi-provider network, as shown in Figure 1.

When an end user experiences connectivity or delay problems with a connection to an ATM network, there are multiple places where connectivity problems can occur. It is difficult to determine where the problem is located, and therefore, who has the responsibility to fix the problem. By giving each service provider the ability to establish connectivity with the CPE and measure delay, they can quickly narrow down which network has the problem, then work within that network to fix the problem.

The new or modified CLI commands used to support the network to endpoint loopback connectivity verification feature are listed below.

16. Deferred Connection Alarm Generation on the BPX

The Release 9.3.30 Deferred Connection Alarm Generation feature reduces the number of feeder communication failures reported to Customer Premise Equipment (CPE), while providing enough time for network operators to take corrective action. When a communication failure is reported, an alarm is sent to the Cisco Wan Manager and a message is sent to the remote end to condition the connections. When this feature is enabled, a feeder communication failure will not be reported to the remote end as long as the data traffic is not impacted. An alarm will still be sent to the Cisco Wan Manager.

Two new statistics have been added to the dsplmistats command to provide information about the number of communication failures detected and the number of times the connection alarms were deferred due to this feature. These statistics are "Num LMI Failures detected" and "Num Conn Alarm gen deferred".

"Num LMI failures detected" is incremented every time a communication failure is detected on a feeder trunk.

"Num Conn Alarm gen deferred" is incremented if this feature is active when a communication failure is cleared on a feeder trunk. Note that this statistic is not incremented when the communication failure is detected, only when it is cleared.

Since LMI statistics are not preserved across switch overs and rebuilds, if the communication failure was declared before the switch over/rebuild and the communication failure clears after the switch over/rebuild, the "Num Conn Alarm gen deferred" statistic could be greater than the "Num LMI failures detected" statistic.

In order for this feature to work, the Line Sampling state machine must be ON (the on2 command, option number 1). If the Deferred connection alarm generation feature is enabled and the Line Sampling state machine is OFF, the feature will not be activated when a communication failure is declared on a feeder.

Use the dsplmistats command to check the status of the feature (Enabled/Disabled/Activated). A warning message will be displayed if the feature is enabled, but the sampling is OFF.

For a connection added between the feeder in communication failure and another port or feeder, the dspcon command for either connection end points would show that the feeder is in Port Comm Fail. However, if the feature is active on a feeder, this behavior has been changed so that only the dspcon at the feeder endpoint would show the correct feeder status. The communication failure is masked at the other endpoint. For ex: Feeder 1.1 is in Comm fail and a connection is added between 1.1 and 3.3 (another feeder). If the feature is not active, dspcon at 1.1.1.1 and 3.3.1.1 would show that Line 1.1 is in Comm Fail (''Line 1.1 : Port Comm Fail"). If the feature is active, dspcon at 1.1.1.1 would show that 1.1 is in Comm Fail ("Line 1.1 : Port Comm Fail") while dspcon at 3.3.1.1 would show that 1.1 is OK ("Line 1.1 : OK").

The Deferred Connection Alarm generation feature is disabled by default when a feeder trunk is activated or after upgrading a feeder from a pre-9.3.30 release.

CLI Commands modified to support the Deferred Connection Alarm Generation feature are listed below.

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) · 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.

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:

5. 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.30

1. The cnfcdparm CLI (BPX):

2. The tstconseg CLI (BPX):

A new optional parameter (the OAM loopback cell format) has been added to the tstconseg CLI (BPX only).

The current tstconseg cmd spec is:

tstconseg <channel> <iteration cnt> [A|a]

The new tstconseg cmd specs are:

tstconseg <channel> <iteration cnt> [A|a] [I|i|o|O]

tstconseg <channel> <iteration cnt> [I|i|o|O] [A|a]

The optional parameters can be specified out of order.

The following examples are used to illustrate the new UI:

tstconseg 1.1.100.1 5 /* send default I.610 cell */

tstconseg 1.1.100.1 5 I /* send I.610 cell */

tstconseg 1.1.100.1 5 i /* send I.610 cell */

tstconseg 1.1.100.1 5 O /* send O.151 cell */

tstconseg 1.1.100.1 5 o /* send O.151 cell */

tstconseg 1.1.100.1 5 a o /* send O.151 cell, abort the tst upon err */

tstconseg 1.1.100.1 5 I A /* send I.610 cell, abort the tst upon err */

3. Changes for "Neighbor Discovery"

4. Changes for rrtcon command

A new option, pfail, has been added to the rrtcon command. rrtcon -pfail reroutes all permanently failed connections mastered on the node where this command is issued.

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

<List of blocked features/commands>

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.

For 9.3.30, these features are blocked in a mixed network. They require that all nodes of the network are running 9.3.30.

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 supports:

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.30

None.

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-keep alive 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.30

1. tstpingoam not supported for connections on a ENNI/EUNI port. Only one set of test results is maintained for local connections.

So if tstpingoam or tstconseg is done successively for both ends of a local connection via SNMP, the results will be the same for both ends and would be that for the last test performed on either end of the local connection.

The number of iterations that can be specified via SNMP for tstconseg or tstpingaom is limited to 5 due to SNMP timeout restrictions. The CLI allows up to 10 iterations.

2. In the URM card, VPI/VCI 0, 1023 are reserved and cannot be used for a VSI partition.

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 under the following conditions:

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.3.30

None.

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