9.3.47 Version Software Release Notes Cisco WAN Switching System Software

MGX 8230 1.1/1.2 Firmware Compatibility and
MGX 8250 1.1/1.2 Firmware Compatibility 53

About the 9.3.47 Release

The 9.3.47 software release supports the Cisco WAN switching products: Cisco BPX 8600 series and Cisco 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, see the following information.

Definitions

Minimum Release Versions

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

For information about these features, refer to the corresponding release notes at the following URLs:

Software Release 9.3.47 Files

New Features in Release 9.3.40

Virtual Trunk Bandwidth Oversubscription

Virtual trunking defines multiple trunks within a single physical trunk interface. Virtual trunking allows the user to allocate as much bandwidth as needed instead of the full T3, E3, OC3, or OC12 bandwidths. Virtual trunking bandwidth refers to the service rate.

Prior to Release 9.3.40, the bandwidth of a virtual trunk (VT) is limited by its allocated portion of the total physical bandwidth at the interface. If a VT on a single interface is not utilizing its allocated share of bandwidth, other VTs cannot use this available bandwidth when their traffic exceeds the configured level. Each of the VTs on a physical interface has a fixed bandwidth which leads to inefficient use of the total bandwidth.

In Release 9.3.40 the purpose of oversubscribing is to allow a VT to utilize up to a maximum configured bandwidth on the physical interface. The sum of individual maximum bandwidths of the VTs on a single physical interface can exceed the actual physical bandwidth available on that interface. If a VT is not utilizing its share of bandwidth, another VT can use the bandwidth.

VT bandwidth oversubscription is applicable to AutoRoute (AR) and PNNI. This feature is available on the BPX switch with the BXM-E card. This feature is not supported on any other BPX card or on the IGX switch.

Functionality

The VTs on a physical interface can be configured with minimum and maximum service rates. The maximum service rate can be oversubscribed. If some connections on one VT burst traffic, they are allowed through on the oversubscribed VT up to the maximum service rate.

By default oversubscription on a VT is disabled, and the minimum and maximum service rates are set to the same value. Whenever the minimum and maximum values are changed by the user to be not equal, oversubscription is implicitly enabled.

By default the minimum and maximum service rates on a VT are set to 3000 cps or to the maximum bandwidth available on the physical interface, whichever is smaller.

VT oversubscription is disabled by making both the minimum and maximum service rates equal.

Configuration Requirements

The trunk on which this feature is to be enabled must be up. The remote end can be a BPX or IGX.

The sum of the maximum service rates of all VTs on a physical interface can be greater than the total bandwidth of that physical interface.

AutoRoute Connections

When routing connections over a VT, AutoRoute (AR) searches for the VT which has maximum available bandwidth and routes the connection over that VT. When a connection is routed over an oversubscribed VT, AR uses the minimum service rate to check for available bandwidth.

VSI Partitions

A VSI partition on a VT can be oversubscribed since the VSI partition shares the same virtual interface (VI) as that of the VT on which VSI partition is configured. The VI now has a minimum and a maximum service rate. Thus, connections on a VSI partition can burst up to the maximum VI rate with enough bandwidth on the interface. This maximum VI rate is configured through the cnftrk CLI command.

CLI Additions and Modifications

This section contains the commands that have been modified to support VT bandwidth oversubscription.

cnftrk

The cnftrk command has been modified to allow configuration of minimum and maximum service rates.

dsptrk

The dsptrk command shows the minimum and maximum service rate values. This display is the same as Example 1.

dspcmi

The dspcmi debug command shows whether the card supports VT oversubscription.

dspcd

dsptrkutl

The Overall utilization field in the display screen indicates the percent utilization of the trunk. If a trunk is oversubscribed, the percentage utilization might exceed 100% when the bandwidth usage exceeds the minimum configured value.

MIB Addition

This section contains the following addition to the atmTrunks table in the switch MIB to support VT bandwidth oversubscription.

Mismatch Capabilities

VT oversubscription is considered enabled if at least one VT on a active BXM is oversubscribed.

Redundancy

Feeder VCI Restriction Removal

STI cells used by Cisco WAN switches and ATM standard UNI/NNI cells have different header formats. ATM standard cells use a 16-bit VCI address field; whereas, STI cells use a 12-bit VCI field. In STI cells the higher 4 bits of octet 4, which contain the last 4 bits of VCI address in ATM standard cells, contain ForeSight information. Therefore, UNI/NNI cells support 65535 VCI addresses while STI cells can support only 4095 VCI addresses.

Since BNI cards use only STI cells, an ATM network with BNI and non-BNI modules must ensure that VCI address translation occurs whenever a cell moves from an ATM (non-BNI) segment to an STI (BNI) segment and vice-versa. Otherwise, the lower 4 bits of VCI information in the UNI/NNI cell are overwritten with ForeSight information when the cell enters the STI segment. This translation is achieved by shifting the lower twelve VCI bits of an ATM cell left or right when it enters or exits an STI segment.

This feature allows VCI shift to be turned on or off on BXM feeder trunks, enabling them to use the full 65535 VCI UNI/NNI address range. This feature also applies to MPLS which requires a VCI range greater than 4095.

Usage

To get the VCI unchanged in a VPC connection, shift must be disabled on all nodes in the path of the connection. The no-shift option must be selected at the master and slave nodes of the connection. Via nodes take on the same shift configuration as the master and must be no-shift if the master node configuration is no-shift.

Configuration

By default in Release 9.3.40 BXM feeder trunks have VCI shift disabled. The feeder trunks that exist prior to Release 9.3.40 have the VCI shift enabled by default.

To pass VCI without shift on a connection, the master and slave nodes should be configured as no-shift. The connection should not route over a BNI trunk.

For an existing connection, a change in the shift/no-shift setting is effective after the connection is rerouted. For example, if a node is upgraded from a version of SWSW that does not provide cnffdr support to one that does, any existing connections over BXM feeder trunks shift the VCI for cells passing over the connection.

Use the following guidelines for changing the shift/no-shift setting on a feeder trunk:

No configuration is required on via nodes since via nodes follow the configuration of the master node.

For a routing trunk, the cnfport command is used to turn shift on or off. For a feeder trunk, shift has to be configured using the cnffdr command or through SNMP.

When new feeder trunks are added on a node running SWSW software with this feature, the trunks come up with shift turned off.

To ensure that the VCI is not changed on a VPC connection, BNI trunks must not be in the path of the connection since BNI trunks use only 12-bit VCI (STI cells).

CLI Additions and Modifications

This section contains the commands that have been modified to support VCI restriction removal.

cnffdr

The cnffdr command is used to configure shift/no-shift on a BXM feeder trunk. The cnffdr command configures the shift/no-shift setting only under the following conditions:

If any of the above conditions are not true, the system displays an error message and prompts for another trunk number.

The following example shows the cnffdr display screen The Feeder trunk field displays the trunk number followed by the type of shelf.

dspfdrcnf

For BNI feeder trunks, the VCI field is copied to an STI cell. The shift/no-shift setting is not applicable. Therefore, for BNI feeders the dspfdrcnf command displays a [-] in the Shift field, shown in the following example.

MIB Addition

This section contains the addition to the atmTrkTable in the switch MIB to support VCI restriction removal.

SNMP Error Messages

Redundancy

Controller Card Redundancy

Standby updates are applicable for the shift/no-shift parameter setting. The same configuration is available after executing a switchCC. If a switchCC (automatic) occurs when the configuration is changed but the connections are not rerouted, the configuration is available in the new active controller card. For the configuration to be to be effective, a manual reroute must be done after the switchCC.

Y-redundancy and APS

Display Connection Counts

In SWSW Release 9.3.40 the CLI command, dspconcnts, is modified to include the following connection counts:

CLI Addition

This section contains the command that has been added to support connection counts.

dspconcnts

The dspconcnts command shows the number of connection and connection endpoints.

VC Merge

The VC merge feature is already supported on BPX nodes. For more information on this feature, refer to the BPX Installation and Configuration documentation at the following URL:

On the IGX VC merge feature is supported only on UXM-E cards running firmware ACJ or higher.

This feature allows multiple incoming VCs to be merged in to a single outgoing VC. A UXM enhanced card with the VC merge capability can be configured to allow the merging of frame-based connections into a merged VC. The merged VC is controlled by the VSI controller.

The VC merge feature allows scalability of MPLS networks since one VC is allocated to each destination of each link.

The SWSW allows the configuration of VC merge for an enhanced UXM card through the cnfcdparm command. VC merge can be enabled only if the card supports this feature.

The VC merge feature is supported only for frame-based connections. These connections carry AAL5 frames consisting of multiple cells. The cells from a particular frame must be in an uninterrupted sequence when the frame goes out after merging.

After the node is upgraded to Release 9.3.40, VC merge can be enabled on the UXM-E cards by using the cnfcdparm command. The VC merge configuration parameters are saved in BRAM and are sent to the standby processor card.

Availability of Contiguous LCNs

The UXM card requires 550 contiguous logical channels (LCNs) in the AutoRoute (AR) partition to support this feature. The VC merge configuration request is denied if 550 LCNs are not available on the AR partition. The user is prompted to allocate LCNs on the card if the feature needs to be enabled.

The traffic on the VCs might get affected when this feature is enabled where 550 non-contiguous LCNs are available on the card. A trap is sent to indicate that the card needs to be deactivated and reactivated to enable the feature support. Since deactivation of the card disturbs the traffic, the user is prompted with a Y/N to proceed with the request. After the user enters Y to proceed, the SWSW configures the VC merge feature by sending appropriate commands upon card activation. The user is prompted before the interruption of any data traffic.

Redundancy

Graceful mismatch is supported. A mismatch condition is declared if the VC merge feature is in use, and Y-redundancy is attempted using a card that does not support the feature. In such cases, feature mismatch is declared (see Table 6).

CLI Additions and Modifications

cnfcdparm

The cnfcdparm command supports the VC merge configuration on UXM supported cards. A card must have at least one active partition to enable VC merge.

dspcd

NTM Subrate Trunk Encryptor Synchronization

This feature toggles the DTR lead on an NTM subrate interface backcard for a preconfigured ON and OFF cycle in the case of a disturbance to the trunk. This toggling continues until the trunk alarms clear.

Functions

When this feature is enabled, the NTM firmware detects a loss of synchronization by monitoring the following alarms:

The firmware then toggles the DTR lead periodically as specified by the ON and OFF times until all the above alarms are cleared. When the alarms are cleared, the firmware restores the state of the DTR lead.

CLI Modifications

This section contains the commands that have been modified to support NTM subrate trunk encryptor synchronization.

cnftrk

DTR toggling is enabled and disabled using the cnftrk command. A DTR toggle on alarm field is displayed for an NTM subrate trunk. Valid values are Y or N.

Fields for configuring ON and OFF duration are DTR secs ON and DTR secs OFF. Valid values for both fields are in the range of 1-128 seconds. Default for DTR secs ON is 29 seconds. Default for DTR secs OFF is 1 second. See the display screen in Example 12.

dsptrk

The dsptrk command is extended to display state of DTR toggling (enabled or disabled) and the ON/OFF durations.

cnftrkict

If the feature is enabled on a trunk, the cnftrkict command displays a warning message whenever DTR settings are changed. This warning indicates that the settings will be overridden by cnftrk settings in case of trunk disturbance.

MIB Additions

This section contains the three additions to the fpRteTrk table in the switch MIB for this feature.

SNMP supports enable/disable toggling and configures the ON/OFF toggling parameters.

SNMP OIDs are partitioned into two sets, legal_fprtetrkcnfg_tbl and legal_fptrkparm_tbl. Each table has a separate access function, corresponding to cnftrk and cnftrkparm CLIs. These OIDs are contained in the fpRoutingTrunks table.

UXM Trunk and Line Loopback

This feature provides the loopback commands on a UXM physical interface that is configured for physical, virtual, or feeder trunk(s) in trunk mode and configured for an UNI or NNI ATM port in line mode.

When a physical loopback is added on a UXM physical interface, all the traffic on the physical interface is looped back.

The physical loopback configuration is stored in BRAM and updated to the standby NPM. The configuration is retained after a rebuild, switchcc, or software upgrade. SWSW does not broadcast the physical loopback information on a UXM physical interface to the other BPX/IGX nodes in the network.

Local Loopback (addlnloclp)

When a UXM port interface is put in local loopback state, the traffic that comes into the cell bus from the local cable is looped back on the cell bus and sent back out the cable. This traffic is passed into the network.

The traffic that comes from the remote end through the network is not sent to this interface. This traffic is dropped and is not mixed with the traffic being looped back.

For local loopback on normal trunks the node which has the trunk-end in local loopback state goes into Comm-Fail state while the remote node goes into loopback state. The traffic from the remote node is looped back by the local node.

The symbol "]" always indicates local loopback for both lines and trunks. The loopback behavior on IMA lines/trunks, IMA virtual trunks, and feeder trunks is similar to that of normal lines/trunks. The user can reduce the number of retained links (to ensure that IMA group status is OK using cnfln or cnftrk commands) and safely put a local loopback on one or more of the individual physical IMA links. The test traffic entering the looped IMA links is looped back while the main user traffic remains unaffected (as long as a sufficient number of retained links remain).

Local Remote loopback (addlnlocrmtlp)

For local remote loopback on normal lines, the node that has its line interface in the local remote loopback state loops back the traffic coming from the cell bus. The traffic is looped back and is not passed to the cable. Traffic from the ports on the local node is not sent on to the network. Traffic is dropped at the local node and is not mixed with the traffic being looped back.

For local remote loopback on normal trunks, the node that has its trunk-end in local remote loopback state loops back the traffic coming from the cell bus. The remote node does not receive this traffic.

The traffic being received from the remote node is dropped and is not passed on to the CPE attached to the local node. This traffic is not mixed with the traffic being looped back.

The symbol "[" always indicates local remote loopback for both lines and trunks. The loopback behavior on IMA lines/trunks, IMA virtual trunks, and feeder trunks is similar to that of normal lines/trunks. Local remote loopback on individual IMA links is not supported.

Delete Local/Local Remote loopback (dellnlp)

The dellnlp command deletes either local or local remote loopback on a line or trunk interface.

The displaying (output) screens of the following existing IGX user commands include the loopback indicators on all the trunks or lines on the UXM physical interface:

Table 8 lists the expected behavior upon using the loopback commands on a single (isolated) node and other nodes in a network. The behavior at both the local and remote nodes is shown. All loopback commands are executed on local nodes.

Limitations

The physical loopback commands on IGX can be executed on the UXM physical interface only, not on an individual virtual interface.

Local remote loopback on individual IMA physical links (either lines/trunks) are not supported. Either all or none of the individual IMA physical links might be put into loopback. This loopback behavior is a firmware limitation. However, for local loopbacks either one or more (including all) of the individual IMA physical links can be put into local loopback.

Traffic loopback behavior on feeder trunks is the same as on normal physical trunks. However, the display is different, as shown in Table 8. Feeder trunks do not have an alarm state called Looped Back. For loopbacks on feeder trunks, both local and remote ends are in major alarm and go into communication-failure state. The states are different because feeder trunks use LMI/ILMI protocol for communication failure tests while normal physical trunks use AutoRoute protocol.

CLI Additions and Modifications

addlnloclp

addlnloclp <slot.port> or <slot.port[-port, port]> or <slot.port.vport> or <slot.port-port.vport>

addlnlocrmtlp

addlnlocrmtlp <slot.port> or <slot.port[-port, port]> or <slot.port[.vport]> or <slot.port-port.vport>

dellnlp

dellnlp <slot.port> or <slot.port[-port, port]> or <slot.port.vport> or <slot.port-port.vport>

dsptrks

If a UXM physical interface is put in loopback state (either local or remote local), the dsptrks command displays a loopback indicator associated with each of the logical trunks (physical or virtual) that are configured on that UXM physical interface.

dsplns

The dsplns command displays a loopback indicator for the logical line. This command includes the following modifications:

dspphyslns

The changes in dspphyslns are identical to those of the dsplns and dsptrks commands except that the loopback indicator is shown against each individual IMA physical line as appropriate.

Redundancy

If Y-redundancy is configured on a UXM card that supports hot-standby the line loopback configuration on its physical interface, if SET, is also programmed to the standby UXM.

Single-Ended FCES and Policing

Single-ended FCES mechanism is used to provide an end-to-end flow control capability to ABR and FST types of connections consisting of multiple segments. This feature allows the BXM-E and UXM-E to provide congestion information to non-Cisco products using a standard interface. ABR flow control is extended to the external segment.

Policing is the process of monitoring ingress traffic of a connection to determine if the traffic can enter and how that traffic is handled once inside the network.

These features allow single-ended FCES and policing on a connection to be configured on an endpoint basis rather than on a connection basis. The congestion control loop is enabled between only those devices that support this feature.

Similarly, policing is independently configured at each endpoint of the connection. This feature allows maximum traffic throughput to avoid cell discards due to traffic clumping on the NNI interfaces.

Functions

Requirements

FCES

Independent values for FCES provisioning can be configured for the following reasons:

MIB

To integrate with CWM, the switch MIB atmEndptOeBCM object for FCES is read-write.

Policing

When a connection is added using addcon, configured using cnfcon, or displayed using dspcon CLI commands, the parameter for policing takes one of the following value combinations:

For UBR connections, CLP tagging is used and corresponds to the following input values:

The policing type has a range from 1 to 5. Table 9 shows how these policing types are defined. The value to the left of [/] is the local endpoint policing type and the value to the right of [/] is the remote endpoint policing type. The two endpoints are provisioned independently using these two input values.

To configure policing based on endpoints rather than connections, use the addcon and cnfcon CLI commands.

Compatibility

MIB

A new MIB object atmEndptOePolicing supports policing type on the other end.

Redundancy

One-to-one redundancy is preserved since the values for FCES and policing endpoint provisioning are stored in BRAM and are sent to the standby card.

Network Interoperability

When connections are added from a node with this feature to another node without this feature, the endpoint-based provisioning can be achieved. On the node the display without this feature, the dspcon command displays only one local endpoint value.

The dcct, dvc, and dvcparms commands display the values on both endpoints.

When an ATM class is configured from a node with this feature to have two different values for FCES or policing, the CWM Connection Manager (CM) updates this ATM class definition on all the nodes in the network including nodes without this feature. If a connection is added from an old revision node using this updated class, the connection uses the two different values to provision the connection.

With an upgraded CWM and mixed revisions on a switch, single-ended FCES is supported if the master node is an upgraded node.

Line and Port Alarm Masking

Alarms on a line or port can be masked so that they are not propagated to the network. This masking allows the known alarms in the network to be hidden from the new alarms.

Line and port alarms can be masked through CLI and SNMP interfaces. Activation and deactivation of the interface alarms are logged in the local event log.

Functions

Line and port alarm masking mirrors the existing trunk alarm masking and provides the following functions:

Line Alarms

The line alarms on a node are caused by physical line failures which result in failure of all of the connections on the line interface.

Port Alarms

The port alarms in a node can be caused by a failure on the end device (CPE) connected to it. These alarms can be caused by an LMI/ILMI failure to restrict communication between the interface card and the CPE. This failure results in a port communication failure that causes a minor alarm on the node.

In addition to port communication failures, the serial port interface card, UFMU, can have port configuration, port over speed, and cable mismatch failures. These failures result in minor alarms on port interfaces.

An IGX Frame Relay NNI port can go in to major alarm only when an NNI failure occurs, and the debug flag is enabled.

MIB Additions

This section describes the objects added as a part of the alarm masking feature.

CLI Additions and Modifications

This section contains the commands that have been modified to support line and port alarm masking.

cnfintalm

The cnfintalm command configures the thresholds for the integrated line/trunk alarm parameters. This command is the renamed version of the existing cnflnalm command.

cnflnalm

The cnflnalm command enables or disables a line alarm. Upon successful completion of this command, the dsplns screen is displayed with the configured line number in highlighted display.

cnfportalm

dspalms

dspintalmcnf

The dspintalmcnf command configures the thresholds for the integrated line/trunk alarm parameters.

This command is the renamed version of the existing CLI command dsplnalmcnf to avoid the conflict between the line alarm masking and integrated alarm parameter configuration of lines.

Trunk VC Shaping

This feature provides the capability to enable VC shaping on UXM and BXM trunks, virtual trunks, and feeder trunks per Qbin or QoS.

Compatibility

On the BPX, the BXM card must support the trunk VC shaping feature for VC shaping to be enabled on the trunks.

On the IGX, the UXM card must support traffic shaping for VC shaping to be enabled on the trunks.

This feature is compatible only with firmware releases supporting traffic shaping. Additionally, PCR shaping can be disabled per QBin only if the firmware release supports trunk VC shaping. Otherwise, PCR shaping cannot be disabled.

Limitations

The capability to enable and disable VC shaping is available only on AutoRoute Qbins (1-9). VC shaping cannot be enabled on the high priority Qbin (2) since this Qbin services the CC traffic. VC shaping cannot be enabled on other Qbins (Qbin 0, VSI Qbins 10-15).

The maximum rate at which a VC can transmit is limited by its PCR value if PCR shaping is enabled.

Enabling VC Shaping (or disabling from previous enable state) on a trunk applies only to new connections routed over the trunk. VC shaping can be applied to all the connections belonging to a Qbin by performing a reroute.

Functionality

The VC shaping capability can be turned on per QoS on the BXM card by configuring the appropriate Qbin to enable the function. When VC shaping is enabled on a Qbin, egress cells are placed on their respective VC queues before they are scheduled into the Qbin. Cells are scheduled from different VC queues into the Qbin using WFQ to ensure fairness among the different VCs.

On the UXM card, VC shaping can be turned on per trunk. The configuration is then applied to relevant Qbins.

Traffic from a VC queue into the Qbin is limited to the PCR. When VC shaping is enabled, both PCR-shaping and WFQ are in effect. However, PCR-shaping can be removed by programming the PCR of the connection to a large value, leaving only WFQ in effect.

The user can enable VC shaping for a particular Class of Service (CoS) on a trunk or virtual trunk using the cnftrkqparm command, cnftrk command on the IGX, or SNMP.

On the BXM, depending on the CoS, the user is provided with the following options:

CLI Modifications and Additions

This section contains the CLI modifications to support the trunk VC shaping feature.

cnftrk

The cnftrk command on the IGX was used to enable VC shaping on a per trunk basis before this feature. Since the feature moves the capability to a per-QoS basis, the VC shaping parameter in the cnftrk command is removed.

cnftrkq

The cnftrkq command enables and disables VC shaping for trunks, virtual trunks, and feeders on a per-Qbin basis.

VC shaping can be enabled only on the AutoRoute Qbins using this command. Enabling VC shaping on VSI Qbins is not supported. The default values for all the Qbins is disabled.

VC shaping can be enabled on a QBin only if that card supports VC shaping. If a card does not support VC shaping the following error message displays: VC shaping not supported on the card.

dsptrkq

The dsptrkq command displays the VC shaping parameters per Qbin for trunks, virtual trunks, and feeder trunks.

dspcmi

The dspcmi command display includes the new card attribute, Trunk VC Shaping. This field is valid only on the BPX.

dspcd

The dspcd command display includes trunk VC shaping on the BPX (shown in Example 22).

Redundancy

This feature does not have impact on redundancy. No mismatch is declared if one of the cards in a Y-red pair supports this feature and the other does not. However, the feature is activated only if both cards in Y-red support the feature.

MIB Additions

The atmTrunks MIB table currently contains the atmTrkVcShaping object to enable VC shaping per trunk. This object is not used for the BPX and nine new objects are added to enable VC shaping per Qbin. The existing object, atmTrkVcShaping, is still used on the IGX.

Special Installation/Upgrade Requirements

General Upgrade Procedure

Before upgrading 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 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

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 4 After the card comes up, upgrade the run-time firmware to revision ACC or later.

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:

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 users to upgrade their networks from 9.2 to 9.3 in multiple steps.

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 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 function at their 9.2 capabilities, and not at their 9.3 levels until all nodes are upgraded. The dspblkdfuncs command displays blocked (disabled) features.

For 9.3.30 and above, the following features are blocked in a mixed network. These features 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.

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), upgrading does not require physical card resetting with the following steps:

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

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. For example, if the active card is a BCC-3-64, then the standby card must be the same. 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. For example, if the active card is an NPM-32, then the standby card must be the same. 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.

These requirements apply to all software upgrade procedures. These requirements do 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 on all BCC and/or NPM processors:

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 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 With the secondary card in the standby state, cause a switchover using the switchcc command. This command tests that the hardware is working correctly.

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 dspbpnv command can be issued to verify if the node has 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 cnfbpnv command can be used to configure the backplane if backplane is enabled.

Obsoleted Hardware and Firmware

Notes and Cautions

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

Limitations for Release 9.3.40

Compatibility Matrix

Compatibility Notes

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

MGX 8220 Firmware Compatibility

		System 5.0		System 4.1
PCB Description	CW2000 Name	Latest F/W	Min F/W	Latest F/W	Min F/W
ASC F/W	ASC	5.0.18	5.0.17	4.1.11	4.1.00
ASC Boot	ASC	1.0.03	1.0.01	1.0.03	4.0.04
ASC/2 FW	ASC	5.0.18	5.0.17	4.1.11	4.1.00
ASC/2 Boot	ASC	1.0.03	1.0.01	1.0.03	4.0.04
ASC/2F FW	ASC	5.0.18	5.0.17	4.1.11	4.1.05
ASC/2F Boot	ASC	1.0.03	1.0.01	1.0.03	1.0.01
BNM-T3	BNM-T3	n/a	n/a	n/a	n/a
BNM-E3	BNM-E3	n/a	n/a	n/a	n/a
BNM-155	BNM-155	n/a	n/a	n/a	n/a
FRSM-4T1	FRSM-4T1	4.0.24	4.0.19	4.0.23	4.0.13
FRSM-4E1	FRSM-4E1	4.0.24	4.0.19	4.0.23	4.0.13
FRSM-4T1-C	FRSM-4T1-C	4.0.22	4.0.19	4.0.23	4.0.13
FRSM-4E1-C	FRSM-4E1-C	4.0.22	4.0.19	4.0.23	4.0.13
FRSM Boot	FRSM-4T1	4.0.00	4.0.00	4.0.00	4.0.00
FRSM Boot	FRSM-4E1	4.0.00	4.0.00	4.0.00	4.0.00
FRSM Boot	FRSM-4T1-C	4.0.00	4.0.00	4.0.00	4.0.00
FRSM Boot	FRSM-4E1-C	4.0.00	4.0.00	4.0.00	4.0.00
SRM T1E1 (B)	SRM-T1E1	n/a	n/a	n/a	n/a
SRM 3T3	SRM-3T3	n/a	n/a	n/a	n/a
CESM-4T1	CESM-4T1	4.0.18	4.0.15	4.0.17	4.0.11
CESM-4E1	CESM-4E1	4.0.18	4.0.15	4.0.17	4.0.11
CESM Boot	CESM-4T1	4.0.01	4.0.01	4.0.01	4.0.00
CESM Boot	CESM-4E1	4.0.01	4.0.01	4.0.01	4.0.00
CESM-8T1	CESM-8T1	5.0.15	4.1.05	4.1.09	4.1.00
CESM-8E1	CESM-8E1	5.0.15	4.1.05	4.1.09	4.1.00
CESM-8 Boot	CESM-8T1	1.0.01	1.0.01	1.0.01	4.1.00
CESM-8 Boot	CESM-8E1	1.0.01	1.0.01	1.0.01	4.1.00
AUSM-4T1	AUSM-4T1	4.0.22	4.0.19	4.0.21	4.0.13
AUSM-4E1	AUSM-4E1	4.0.22	4.0.19	4.0.21	4.0.13
AUSM Boot	AUSM-4T1	4.0.00	4.0.00	4.0.00	4.0.00
AUSM Boot	AUSM-4E1	4.0.00	4.0.00	4.0.00	4.0.00
FRSM-8T1	FRSM-8T1	5.0.16	5.0.10	4.0.24	4.0.13
FRSM-8E1	FRSM-8E1	5.0.16	5.0.10	4.0.24	4.0.13
FRSM-8T1 Boot	FRSM-8T1	1.0.02	1.0.01	1.0.02	4.0.01
FRSM-8E1 Boot	FRSM-8E1	1.0.02	1.0.01	1.0.02	4.0.01
AUSM-8T1	AUSM-8T1	5.0.16	5.0.10	4.0.24	4.0.14
AUSM-8E1	AUSM-8E1	5.0.16	5.0.10	4.0.24	4.0.14
AUSMB-8T1	AUSMB-8T1	5.0.14	5.0.10	4.0.24	4.0.19
AUSMB-8E1	AUSMB-8E1	5.0.14	5.0.10	4.0.24	4.0.19
AUSM-8T1E1 Boot	AUSM-8T1	1.0.02	1.0.01	1.0.02	4.0.01
AUSM-8T1E1 Boot	AUSM-8E1	1.0.02	1.0.01	1.0.02	4.0.01
AUSM-8T1E1 Boot	AUSMB-8T1	1.0.02	1.0.01	1.0.02	4.0.01
AUSM-8T1E1 Boot	AUSMB-8E1	1.0.02	1.0.01	1.0.02	4.0.01
FRSM-HS1	FRSM-HS1	5.0.15	4.0.16	4.0.20	4.0.11
FRSM-HS1/B	FRSM-HS1/B	5.0.14	4.0.16	4.0.20	4.0.11
FRSM-HS1 Boot	FRSM-HS1	1.0.01	1.0.01	1.0.01	4.0.00
FRSM-HS1 Boot	FRSM-HS1/B	1.0.01	1.0.01	1.0.01	4.0.00
FRSM-HS2	FRSM-HS2	5.0.13	5.0.10	n/s	n/s
FRSM-HS2 Boot	FRSM-HS2	1.0.01	1.0.01	n/s	n/s
IMATM	IMATM-T3T1	n/s	n/s	4.0.22	4.0.13
IMATM	IMATM-E3E1	n/s	n/s	4.0.22	4.0.13
IMATM	IMATMB-T1	5.0.15	5.0.10	4.0.22	4.0.13
IMATM	IMATMB-E1	5.0.15	5.0.10	4.0.22	4.0.13
IMATM Boot	IMATM-T3T1	n/s	n/s	1.0.02	4.0.01
IMATM Boot	IMATM-E3E1	n/s	n/s	1.0.02	4.0.01
IMATM Boot	IMATMB-T1	1.0.02	1.0.01	1.0.02	4.0.01
IMATM Boot	IMATMB-E1	1.0.02	1.0.01	1.0.02	4.0.01

MGX 8850 1.1/1.2 Firmware Compatibility

MGX 8230 1.1/1.2 Firmware Compatibility and
MGX 8250 1.1/1.2 Firmware Compatibility

BPX 8600 Firmware Compatibility

IGX 8400 Firmware Compatibility

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 5 After the card comes up, upgrade the run-time firmware to revision ACC or later.

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:

MGX 8220 5.0 Hardware Compatibility

BPX 8600 Hardware Compatibility

Card Type	Part Numbers	Latest H/W	Min. H/W
Controller Cards
BPX-BCC-64M (Non-Orderable)	800-04008-04	A	A
BPX-BCC-BC (Non-Orderable)	73-211380-00	D	A
BPX-BCC-3-64M	73-3720-02	R	J
BCC-3BC	800-02916-01	E	A
BPX-BCC4V	800-03580-06	E	C
BPX-BCC-4V/B	800-06483-02	C	A
ASI-2T3	73-216330-00	F	A
ASI-2E3	73-216330-01	F	A
ASI-155E	73-214250-00	H	F
ASI-155E	73-218100-02	J	A
Alarm Group
BPX-ASM	800-04009-01	C	A
BPX-ASM-BC	73-211910-00	C	A
ASM-LM	800-211910-10	B	A
Broadband Switch Group
BPX-BME	800-02855-04	B	A
BPX-BXM-T3-8	800-02777-07	J	B
BPX-BXM-T3-8E	800-03933-02	A	A
BPX-BXM-E3-8	800-02779-07	J	B
BPX-BXM-E3-8E	800-03928-02	A	A
BPX-BXM-T3-12	800-02776-07	J	B
BPX-BXM-T3-12E	800-03931-02	A	A
BPX-BXM-T3-12EX	800-03934-02	A	A
BPX-BXM-E3-12	800-02778-07	J	B
BPX-BXM-E3-12E	800-03929-02	A	A
BPX-BXM-E3-12EX	800-03930-02	A	A
BPX-T3/E3-BC	73-2759-02	A	A
BPX-BXM-155-8	800-02664-07	J	B (C for APS)
BPX-MMF-155-8-BC	800-03255-01	B	A
BPX-SMF-155-8-BC	800-03257-01	B	A
BPX-SMFLR-155-8-BC	800-02593-01	B	A
BPX-BXM-155-4	800-02666-07	J	B (C for APS)
BPX-BXM-E-155-4D	800-03094-02	A	A
BPX-BXM-E-155-8D	800-03092-02	A	A
BPX-BXM-E-155-4DX	800-03093-02	A	A
BPX-BXM-E-155-8DX	800-03091-02	A	A
BPX-MMF-155-4-BC	800-03256-02	B	A
BPX-SMF-155-4-BC	800-03258-01	B	A
BPX-SMFLR-155-4-BC	800-02594-02	B	A
BPX-BXM-622	800-02646-10	M	D (E for APS)
BPX-BXM-622-2	800-02638-10	M	D (E for APS)
BPX-BXM-E-622-2D	800-03150-02	A	A
BPX-BXM-E-622-DX	800-03151-02	A	A
BPX-BXM-E-622-2DX	800-03149-02	A	A
BPX-622-2-BC	73-2884-01	D	A
BPX-SMF-622-BC	800-03249-01	C	A
BPX-SMF-622-2-BC	800-03251-01	C	A
BPX-SMFLR-622-BC	800-03250-01	C	A
BPX-SMFLR-622-2-BC	800-03252-01	D	A
BPX-XLR-622	800-02738-01	C	A
BPX-XLR-622-2	800-02739-01	C	A
BPX-BME-OC12	73-2469-07	F	A
RDNT-SMF-155-4R	800-03677-01	J	A
RDNT-SMF-155-8R	800-03679-01	K	A
RDNT-LR-155-8R	800-03678-01	J	A
RDNT-LR-622-2R	800-03676-01	F	A
RDNT-SMF-622R	800-03675-01	F	A
RDNT-SMF-622-2R	800-03674-01	J	A
BPX-STM1-EL-4	800-03716-02	A	A
BNI-3-T3/C	800-02858-02	A	A
BNI-3-E3/C	800-02859-02	A	A
BNI-155E	73-218100-01	K	A
BNI-2-155/B	73-4133-01	L	L
BPX-T3/E3	800-03058-02	E	A
BPX-E3-BC	73-213070-01	E	A
BPX-MMF-2-BC	73-214290-00	D	A
BPX-SMF-2-BC	73-216270-00	D	A
BPX-SMFLR-2-BC	73-216270-01	D	A
SMF-LM-OC3	800-216270-10	C	A
SMF-LM-OC3-LR	800-216270-11	C	A
MMF-LM-OC3	800-214290-10	B	A
LM-3T3	800-213070-10	D	A
LM-3E3	800-213070-11	D	A

IGX 8400 Hardware Compatibility

Card Type	Part Numbers	Latest H/W	Min. H/W	Comments
Controller Cards
IGX-NPM-32	73-2894-01	W	A
IGX-NPM-64	73-2895-01	W	A
IGX-NPM-32B	73-2554-04	L	A
IGX-NPM-64B	73-2363-02	C	A
IGX-SCM	73-3341-01	Y	A	Revision X or later for nodes with UXM IMA trunks
Alarm Group
IGX-ARM	73-218230-00	B	A
BC-512011	73-212360-00	D	A
Trunk Group
IGX-NTM	73-2296-04	E	A
BC-6271A-TI	73-207380-00	M	A
BC-6171A-E1	73-207370-01	P	A
BC-6083A-SR	73-208540-00	J	A
BC-550150-Y1	73-210820-01	D	A
ACM1	73-2921-03	W	A
BC-571110A-T3	73-2879-01	L	A
BC-571210A-E3	73-2679-01	K	A
BC-571310A-E2	73-215940-00	D	A
BC-571410A-HSSI	73-216370-00	A	A
IGX-UXM	73-2511-03	D	A
IGX-UXM-E		A	A
BC-UAI-4-155-SMF	73-2703-03	D	A
BC-UAI-4-155-MMF	73-2705-03	D	A
BC-UAI-2-155-SMF	73-2699-03	C	A
BC-UAI-2SMFXLR		A	A
BC-UAI-4SMFXLR		A	A
BC-UAI-6-T3	73-2952-02	A	A
BC-UAI-3-T3	73-2954-02	A	A
BC-UAI-6-E3	73-2953-02	A	A
BC-UAI-3-E3	73-2955-02	A	A
BC-UAI-8-E1-BNC	73-2932-02	C	A
BC-UAI-4-E1-BNC	73-3061-01	C	A
BC-UAI-8-T1-DB15	73-2941-02	C	A
BC-UAI-8-E1-DB15	73-2942-02	C	A
BC-UAI-4-T1-DB15	73-3059-01	C	A
BC-UAI-4-E1-DB15	73-3060-01	C	A
BC-UAI-4-STM1E	73-3364-02	A	A
Port Group
IGX-URM	800-06260-06	A	A
BC-2FE2V	800-06257-03	A	A
ACM1A	73-2930-03	W	A
IGX-HDM	73-2853-02	F	A	*Show SDP H/W Rev, DM=SDP+ACM2
ACM2	73-2922-03	T	A
BC-5082A-V35	73-2450-01	K	A
BC-5083A-RS449	73-204850-00	V	A
BC-5084B-RS232	73-2723-01	W	A
IGX-LDM	73-207250-00	K	A	*Show LDP H/W Rev, LDM=LDP+ACM1A
BC-5286A-RS232	73-207180-01	L	A	LDI-4RS232
BC-5287A-RS232	73-207180-00	L	A	LDI-8RS232
IGX-CVM-DSOA	73-3002-02	D	A*	*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-T1EC	73-3003-03	E	A*	*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-E1EC	73-209660-00	H*	A*	*Show CDP H/W Rev, CVM=CDP+ACM1A
IGX-CVM-TT
BC-6271A-TI	73-207380-00	M	A
BC-6171A-E1	73-207370-01	P	A
BC-550100-J1	73-210820-00	C	A
IGX-FRM	73-2517-03	N	A
IGX-FRM-31	73-2517-03	N	A
IGX-FRM-2	73-2519-01	M*	A*	*Show FRP H/W Rev, FRM-2=FRP+ACM1A
BC-6251B-V35	73-3253-01	M	A	FRI-4V.35-2
BC-6254A-X21	73-211440-00	H	A	FRI-X.21
BC-6355A-X21	73-214120-01	C	A	FRI-2X21
IGX-UFM-4C	73-2531-05	N	A	Needs a minimum of ZAS/ZBC Firmware
IGX-UFM-8C	73-2531-05	N	A	Needs a minimum of ZAS/ZBC Firmware
BC-UFI-8T1-DB15	73-2444-02	D	A
BC-UFI-8E1-DB15	73-2445-02	D	A
BC-UFI-8E1-BNC	73-2449-02	D	A
IGX-UFM-U	73-2349-04	D	A
BC-UFI-12V35	73-2711-01	D	A
BC-UFI-12X21	73-2712-01	D	A
BC-UFI-4HSSI	73-2693-01	C	A
IGX-UVM	73-2361-04	K	A
BC-UVI-2E1EC	73-2420-01	B	A
BC-UVI-2T1EC	73-2373-01	C	A
BC-UVI-2S1EC	73-2374-01	A	A

Known Anomalies for Release 9.3.47

Bug ID

Description

CSCdk22430

Headline: Word 15 of bpnv checksum is not recalculated

Symptom: Checksum word 15 of backplane nvram is not recalculated when words 0-14 are updated using cnfbpnv.

Conditions: Observed with BPX 9.1.01.

Workaround: None

CSCdk80347

Headline: Standby NPM Watchdog Timeout after resetsys, 1M3, 2M, or abort command.

Symptom: NPM 2 restarted due to a Watchdog Timeout

Conditions: Happens when you run resetsys command to reset all the cards (except the active NPM card) on an IGX node with lot of active connections. When the standby NPM comes up, the event log mentions that: "NPM 2 Restarted due to a Watchdog Timeout" where 2 refers to the slot number of the standby NPM card.

Workaround: This does not affect any functionality except for the above log. Instead of running the resetsys command, individually reset the cards using resetcd command.

CSCdk91790

Headline: Eliminate UVMs modem polling to save system idle time

Symptom: SWSW system idle time is below 30% when more than 10 UVMs are activated

Conditions: SWSW polls each activated UVM for modem status every 1 second for each port. SWSW also spends time in processing the responses of the modem polling. When many UVMs are activated, the modem polling handling consumes a lot of system time and resources (buffer queue) which affect system performance. UVM FW has supported asynchronous event to report modem event. SWSW needs to stop polling modem status if the FW in UVM supports the async event.

Workaround: Use cnfnodeparm 46 to increase polling timer to improve system performance.

CSCdm22426

Headline: Commands which lock UI - dspbob - will cause jobs to fail without notice

Symptom: While using jobs to down or up the connection based on a jobtrigger, the job will fail if dspbob is executed while the control signal toggle.

Conditions: Observed with IGX 8.2.56.

Workaround: Retrigger the job after dspbob.

CSCdm40952

Headline: Two PVCs rerouted during switchcc in BPX network

Symptom: On a switchcc, the node will try to reroute some working connections not on their preferred route (dsprrst will show non-zero values). The reroute attempt will not be successful and the connections will continue to use their working path.

Conditions: This will happen only when preferred routes are set up for the connections and these connections are not routed on their preferred routes.

Workaround: If all connections are on their preferred route, this problem will not happen. To ensure that all connections are on their preferred route, execute "cnfpref * +" on that node - this will create a preferred route (same as the current route) for ALL the connections (including those which did not have preferred routes).

CSCdm76279

Headline: Cisco View no Data for FR-RealTimeCounters on IGX

Symptoms: When Using CiscoView to view the FR-RealTimeCounter SpreadSheet only the first two columns are displayed correctly, the remaining columns are displayed as 1's.

Conditions: All conditions are normal.

Workaround: None

CSCdp44912

Symptom: Upgrade from IGX 9.1.04 to 9.1.16 causes UXM Y-red card to go into mismatch.

Conditions: Same as above.

Workaround: delyred can be performed to avoid this condition.

Further Problem Description: Problem isolated "VC shaping" upgrade mechanism.

CSCdp48861

Headline: Polling for voice conn and line stats results in high TRNS RT usage

Symptom: The customer may notice slow UI response, or a difficulty logging into the node using the normal VT session. The dspprfhist shows high RT usage in the TRNS process. The thstats shows high RT usage by state machine 55 (0x33).

Conditions: This is due to statistics updates for voice connections. It may be seen on nodes with a high number of voice cards and voice connections (IGX with CVMs and/or UVMs).

Workaround: The command off1 17 can be performed. This will stop the collection of voice connection statistics (for all connections, not just voice), as well as the operation of the debug command dspchstats. If statistics must be collected, limit the number of statistics. Frame Relay statistics are collected at 5 minute intervals (configurable up to 15 minutes). Most voice statistics are reported at 1 minute intervals, but the following statistics are reported at 3 second intervals:

1. Seconds V.25 Modem On

2. Seconds DSI Enabled

3. Seconds Off-Hook

4. Seconds In Service

CSCdp98648

Headline: CWM 92 equipment manager does not support BXM enhance card type.

Symptom: Equipment Manager cannot tell the difference between BXM legacy or enhance.

Conditions: BPX nodes containing both legacy BXMs and Enhanced BXMs.

Workaround: Log into the BPX node and do dspcd XX and determine from number of channel support. The enhanced version of the BXM card has 61K channels, and the BXM card has less than 61K channels.

CSCdr05291

Headline: Problems deleting feeder trunks via SNMP

Symptom: switchIfService must be specified to delete feeder trunks, but not routing trunks.

Conditions: This requirement confuses CiscoView users.

Workaround: Use the CLI commands to delete feeder trunks.

CSCdr25278

Headline: Loss of Signal not properly indicated per UNI 3.1

Symptom: The SUT and EMS are not indicating LOS as per UNI 3.1

Conditions: None

Workaround: None.

CSCdr45021

Headline: BETA: Request to generate an alarm when an SES trunk use default SCT 1

Symptom: SCT 1 is default SCT reserved for MPLS. When an SES trunk is provisioned, if the default SCT is not changed to SCT 3, trunk will fail to come up.

Conditions: A warning message in configuration screen to indicate that the default is SCT 1 for MPLS and should be changed to SCT 3 for SES will be useful. This is an enhancement request from customer.

Workaround: Make sure that SES uplink uses SCT 3 as service class template.

CSCdr58295

Headline: burnfwrev before the completion of resetcd, makes the UXM card to Fail

Symptom: UXM card is in the "Failed/Unavail" state after the user issues a "burnfwrev" command while the card is coming up after a "resetcd".

Conditions: User issues a "burnfwrev" command before the UXM has come up after a "resetcd h".

Workaround: Do not issue the "burnfwrev" command until the UXM is up. If the "burnfwrev" command has been issued and the UXM is in the "Failed/Unavail" state issue a "resetcd h" to reset the UXM card.

CSCds34334

Headline: Traffic through IMATM trunks on BNI card doesnt fail

Symptom: Traffic statistics on local BNI IMA trunk doesn't fail when trunk card at remote end is downed.

Conditions: Connection between ASI-E3 and ASI-155E between two BPX nodes. Connection has a preferred route with d option through IMA trunk on BNI. IMA trunk between two BPX nodes through an AXIS node. Trunk card at remote end is downed.

Workaround: None.

CSCds47671

Headline: dspcurclk displays incorrect clock path for via nodes

Symptom: dspcurclk displays incorrect trunk numbers in the clock path

Conditions: Need the following clock path in dspcurclk for this problem to surface

Workaround: None.

Further Details: The display attempts to display the port on the via trunk before it is properly set.

CSCds64046

Headline: SW error 254 logged over weekend when network was in steady-state

Symptom: SWSW error 254

Conditions: Heterogeneous network devices 1. BPX, IGX nodes running 9.2.23 with SES PNNI controllers, tag LSCs 7200, tag LER 7200, AXIS feeders 2. Some alarms that were there prior to the SWSW error logged for long time

Workaround: None

CSCds68363

Headline: first_avail_lcn is UNKNOWN after BCC is switchcc or rebuilt

Symptom: dsplogcd shows the first_avail_lcn is UNKNOWN after switchcc or system rebuilt.

Conditions: It happens for BXM card with only ports.

Workaround: addcon to add new PVC, dsplogcd will show correct first_avail_lcn.

CSCds68603

Headline: tstdelay PVC after switchcc, the delay time is too long (> 290 msec.)

Symptom: None.

Conditions: None.

Workaround: None.

Further Problem Description This issue is firmware-related. The software is reporting the times. If the software is an issue, a profiler load taken during the test is required. However, the text makes reference to OAM load on the ASI, which indicates a firmware issue.

CSCds81526

Headline: Downed connections on master come up while on the slave side stays downed on the BPX/IGX.

Symptom:

1. The BPX and IGX nodes were loaded to their connection limit.

2. The dncon COS 0 i command was issued on the BPX node 3.

3. Downing about 70% of 16K connections took more that 2.5 hours (performance issue).

4. When the connections were downed, the master side and the slave side of the connection were showing down state which is correct.

5. The upcon COS 0 command was issued to up all downed connections. The command was issued on BPX node.

6. After CPU idle time reached 70%+ (steady-state) on the network wide, the master side of any connection is upped correctly (OK state). However, the slave side of the connection is still in the down state instead of the up state.

7. The upcon network messages were not propagated to the slave-side of the connection. The result is the master-side of the connection is upped, but the slave-side of the connection is still in down state.

8. The upcon finite state machines could be timing out or handling of such an inconsistent state under heavy loading still needs to be accounted.

Conditions:

1. Almost all 9.2.34+9.2.23 SWSW and SWFW features were provisioned.

2. The nodes were loaded to their limit with maximum terminating connections, VTs, and so forth.

3. Topology is of a tiered network with MGX 8220 and IGX feeders, MPLS LSCs and LERs, and SES PNNI controllers.

Workaround: The dncon/upcon commands with COS option can be executed only by users at SUPERGRP or higher privilege levels.

CSCdt07203

Headline: Hitless rebuilds logged on a failed switchcc can fill hitless lo.

Symptom: The hitless rebuild log filled up due to repeated failed switches.

Conditions: A bad standby BCC is required. The node must be running at least 9.2.

Workaround: Clear the hitless log with the command "dsphitless c" or switchcc less often so that the hitless rebuild log entries get a chance to age out of the log.

CSCdt66696

Headline: AIT-E3 backcard is displayed as BTM-E3 in CLI

Symptom: AIT-E3 backcard is displayed as BTM-E3 in CLI

Conditions: AIT-E3 backcard is displayed as BTM-E3 in switch CLI

Workaround: None

CSCdu03108

Headline: 1427 (NW_MSG_VERSION_MISMATCH) while nodes are upgrading.

Symptom: Software error 1427 logged on BPX node.

Conditions: Upgrade from release 9.1.19 to 9.2.3D (pre 9.2.38). The node logging the 1427 error is sending conditional updates to a node which upgrades during the process.

Workaround: None. However, the updates triggered by the upgrading node CC switch should maintain database consistency between the nodes. If the errors persist after the upgrade, then another issue has occurred.

CSCdu13921

Headline: Not enough trunk conids shows as not enough trunk BW for failed connections.

Symptom: Connection routing fails with the message "No route available (insufficient trunk bandwidth)" as seen with the [dspcon] command. However, when checking the trunk bandwidth usage via [dspload], enough bandwidth is allocated.

Conditions: This problem occurs when all of the connection identifiers (conids) are used. The most common occurrence of this issue is on BXM cards. These cards have configurable conid limits, and the defaults are rather small at 256.

Workaround: Check the [dspload] command. If the "Con ID Avail" count is 0, then the routing failure is due to connection ID exhaustion rather than bandwidth.

CSCdu15686

Headline: Diagnostics PortTest V35/X21

Symptom: Internal port diagnostics fails for V35/X21 ports. use "tstport" command. After the above test, the card goes to "Active-F" state as seen in "dspcds"

Condition: The above problem is seen only when port is configured as DCE and not seen with DTE ports. The UFMU F/W version YAM and YAN was tested and returned the same problem.

Workaround: None

CSCdu22300

Headline: Connections not routed due to wrong Gateway LCN calculation (RARE condition)

Symptom: Connections do not get routed even if there are enough resources on the trunk.

Conditions: All of the following should hold true.

1. Connections are being considered for routing in a network consisting of both UXM and NTM trunks.

2. If node X, node Y and node Z are the possible via nodes for a connection being considered for routing and

a. A UXM trunk (Trk1) connected between node X and node Y has the maximum available bandwidth among all of the trunks connected between node X and node Y.

b. A NTM trunk (Trk2) connected between node Y and node Z has the maximum available bandwidth among all of the trunks connected between node Y and node Z. Or, node Y is the slave node of the connection being considered for routing and is terminated on a non-UXM card. Gateway LCN is required at node Y's end of the UXM trunk (Trk1).

c. Gateway LCN is not available at node Y's end of the UXM trunk (Trk1).

3. The "Trunk Cell Routing Restriction" is set to "No" for the connection being considered for routing.

Workaround: Either one of the following options can be used:

1. Using the "cnfpref" command configure the connection to use a path which you have verified to carry the connection.

2. Using the "cnftrk" command, increase the Gateway LCNs on the UXM trunk (Trk1) at the node Y's end.

3. Increase the available BW on at least any one of the other trunks between Node X and Node Y such that it becomes more than the available bandwidth of the UXM trunk (Trk1).

4. Increase the available BW on at least any one of the UXM trunks between node Y and node Z such that it becomes more than the available bandwidth of the NTM trunk (Trk2). (Applicable only if node Y is not the slave node).

Available bandwidth can be obtained using the "dspload" command. Increasing the "Transmit Rate" and "Receive Rate" of the trunk at both ends of the trunk using the "cnftrk" command increases the available bandwidth.

CSCdv33406

Headline: BXM-155 w/ APS: Automatically loop release by switchyred command.

Symptom: While the APS(1+1) and the loop clock was configured to the BXM cards, the loop clock seemed to be released automatically on the execution of switchyred command.

Condition: APS 1+1 setup present and switchyred executed.

Workaround: Manually set the loop clock to NO once and then set back to YES again.

CSCdv36764

Headline: swerr 1008 was logged due to a BXM card resetting continuously

Symptom: swerr 1008 is logged when a BXM card is continuously reset every 5 minutes

Conditions: One of the BXM cards is continuously reset every 5 minutes due to an issue with the Stats Collection task of the BXM firmware running every 5 minutes on the card

Workaround: None

CSCdv73494

Headline: swerr 886,2071,2059 fills the log

Symptom: swerr 886,2071,2059 are in the log

Conditions: The log display shows the swerr

Workaround: None

CSCdv79961

Headline: Cannot configure stat level on UXM Y-red standby card

Symptom: Unable to configure stats level on standby card after upgrading swsw on IGX from 92 to 93 with UXM in Yred.

Conditions: 9.3.30; After upgrading from 9.2.34 to 9.3.11 UXM pair in Yred try to cnfcdparm for stat level change you receive this error message "Cannot change stats level for yred card or card in service" However, if you try the same thing when the card is not in yred, the node allows you to change.

Workaround:

1. Remove the standby card and place in some other empty slot.

2. Configure the stat level in the new, non-yred slot.

3. Replace the card into the y-red standby slot.

4. Wait until the card comes up fully as a standby, and has completed its programming.

5. Switch to the standby card that has the modified stat level.

6. Remove the new standby card and place in some other empty slot.

7. Repeat steps 2-3 on the next card.

CSCdv87535

Headline: chklm trk topology inconsistence in lsnt/upgrade/fallback

Symptom: Trunk topology inconsistency is observed between various nodes in the network.

Conditions: None.

Workaround: None.

CSCdw01866

Headline: LSNT: hitless rebuild, load updates is extremely slow

Symptom: After hitless rebuild in a large network, dspload does not show used recv load info for a long time. chklm could not be trust until all load updates sync up.

Conditions: During hitless rebuild.

Workaround: None.

CSCdw03498

Headline: Backcards empty after resetsys on node sw150.

Symptom: Backcards are "empty" in slot 3, 4, and/or 8 on sw node

Conditions: resetsys on sw node.

Workaround: None.

CSCdw04847

Headline: FastPackets used instead of cells for ATM queue size and delay calculations.

Symptom: The default value and the range allowed for queue size is wrong.

Conditions: This can be seen while using cnftrkparm to configure the queue sizes.

Workaround: A valid range is approximately half of that allowed in cnftrkparm. Configure the queue sizes to be within the valid range.

CSCdw04934

Headline: CLI switchyred command, took approximately 40 to 70 seconds to complete.

Symptom: switchyred sometimes took 40 to 70 seconds to complete.

Conditions: Network with following software configuration: 9.3.3d MF02

Workaround: None.

Further Problem Description: After loading MF02, switchyred is taking 40 to 70 seconds to complete.

CSCdw07614

Headline: Date and time changed after runrev command was issued.

Symptom: Date and time changed during upgrade.

Conditions: 9.3.3b and 9.3.3d MF01

Workaround: None.

Further Problem Description: The date/time changed after runrev command issued on two different nodes. This was noticed doing dsplog, it showed the date and time changed then changed back.

CSCdw30811

Headline: Improperly format FPAD port object and alarm messages sent to CWM

Symptom: Port and alarm messages for FTM ports are not formatted correctly, consequently the CWM cannot track or manage these entities. Because this message is misformated, the CWM does not know where it starts or ends, and consequently other messages from the switch can be discarded. This could then result in incomplete database tables so the CWM cannot collect statistics, manage the ports or establish new connections. This could also result in discarded alarm messages on the CWM so it may not set or clear alarm messages appropriately.

Conditions: This problem will only occur when FTM/FTC cards are on the IGX.

Workaround: Remove all configuration related to the FTM/FTC cards and remove them from the switch all together. FTM/FTC cards are not supported in 93 software, the last version of software that supported these cards was 92.

After removing FTM/FTC configuration and hardware, resync the CWM workstation by doing one of the following:

1. Do a controller card switch over on the IGX switch. This requires a redundant NPM switch. This breaks the link to the CWM, and when the CWM reattaches it will resync with this one node.

2. Do a hitless rebuild on the IGX switch. This will break the link to the CWM, and when the CWM reattaches, it will resync with this one node.

3. Do a full rebuild on the IGX switch.

Caution This will cause an outage on the node and is customer impacting. This will break the link to the CWM, and when the CWM reattaches, it will resync with this one node.

4. On the CWM, stop and then restart the CWM core.

Caution Note this causes the CWM to resync with all nodes in the network.

CSCdw42981

Headline: off3 parameters 1,2 and 3 get set to the default value after rebuild

Symptom: The settings for the following on3/off3 parameters set to their default values (as shown below) after rebuild; Trace Msg Sent

Disabled Multi-DB Stby Updates
Enabled Trace Conv Msg
Disabled

Conditions: This only occurs if the user has modified the setting from its default value, and then a full rebuild occurs. For example if the value of "Multi-DB Stby Updates" was set to Disabled then after rebuild it will be set to 'Enabled'.

Workaround: After the full rebuild, if required reset the value back to the desired value.

CSCdw44810

Headline: event log for runrev initiated from remote node says loadrev

Symptom: Event log indicates "loadrev (new-revision) initiated from node (remote node)" when the remote node really did a runrev

Conditions: This will occur whenever a node invokes a runrev for another node by doing: runrev (newrev) * or runrev (newrev) (remote node)

Workaround: None.

CSCdw47805

Headline: Possible NTM SR trunk with mismatch tx ts queue depth after upgrade

Symptom: The NTM subrate trunk transmission timestamp queue depth is different at the two ends.

Conditions: 1. With one side of the trunk is up only (the other end down), upgrade from pre-9331 images the node to post-9331 images on both side. Up the other side of the trunk.

Workaround: 1. down the upped trunk after upgrade 2. or use cnftrkparm to change the transmission timestamp queue to be the same size as the other end after upgrade.

CSCdw60790

Headline: addcon fails to add abrfst conn with PCR < 50 for BXM OC12 port card

Symptom: Addcon fails to add abrfst connection with PCR < 50 on OC12 card.

Conditions: Add abrfst connection with PCR < 50. The port card is bxm OC12.

Workaround: When adding the connection, disable 'Default Ext Parms [Enable]:'. Add the connection to a rate >= 50. Use cnfcon to change it to a lower value.

CSCdw64896

Headline: disabling routing state machine does not reduce high CPU usage

Symptom: When a node has a lot of unroutable derouted connections in a node that has more than 12K cons, the CPU usage is very high (close to 90%). When the routing state machine is turned off, the CPU load does not go down for a long time.

Conditions: A node with a lot of unroutable failed connections which have several hops between the master and slave.

Workaround: Down the unroutable connections to bring down CPU load.

CSCdw68880

Headline: Some BXM statistics are not being polled for -- always zero value

Symptom: The interval statistics listed below always return a value of zero:

59 Good Pdu's Received by the Sar
60 Good Pdu's Transmitted by the Sar
61 Rx pdu's discarded by the Sar
62 Tx pdu's discarded by the Sar
63 Ivld crc32 pdu
64 Invalid Length pdu rx by the sar
65 Shrt-Lgth Fail detected by the sar
66 Lng-Lgth Fail detected by the sar

Conditions: Always occurs.

Workaround: None

CSCdw78948

Headline: sw error 105 after node rebuild

Symptom: When performing a hitless rebuild on an IGX node using the command: resetcd <slot> R the UFM card may log a OB error. There could be a software error 105 logged along with the card error.

Conditions: This only occurs if the UFM has ports configured for NNI operation. Note: this is a timing sensitive problem and therefore may not occur on each hitless rebuild. The problem is more likely to occur if the node has more than 400 terminated or via connections.

Workaround: None

CSCdw85810

Headline: upport,cnfport does not enforce port group speed limitation on UFMU card

Symptom: The following port group rules are enforced by SWSW cnfport, upport on UFMU card: 1. Two ports per port group: The sum of port speed should not exceed 8 Mbps. 2. Four ports per port group: The sum of port speed should not exceed 8 Mbps. The UFMU port could be configured but there may be traffic drop and the port may not be up to that speed.

Conditions: cnfport on UFMU card.

Workaround: When doing the cnfport, manually check whether it conforms the port group rules or not.

CSCdw86892

Headline: event log for switchyred errors does not cover all possible errors

Symptom: When a switchyred fails the event log may occasionally log an event of: switchyred error: BXM <prislot>/<secslot> ? where instead of displaying the error code, or the textual reason, it instead shows ?

Conditions: This occurs rarely, when the switchyred command encounters an error that the event log does not know how to map to text. The customer is given an appropriate message at the user interface, but it is not presented in the event log.

Workaround: None

CSCdx22448

Headline: VSI protocol down if delete and re-add mpls VSI controller quickly

Symptom: VSI protocol will be down if delete and re-add mpls VSI controller (c7200/URM) quickly on IGX

Conditions: delete and re-add MPLS VSI controller on IGX before the VSI protocol time out.

Workaround: there are two workarounds: 1. delete the VSI controller and wait the VSI interface on router is down and then add the VSI controller back. 2. on the router, shut then "no shut" any one of the XtagATM interface which is controlled by the VSI controller.

CSCdx23232

Headline: con_verify on BPX for conns logs swerr 1417

Symptom: con_verify on BPX for connections resulted in swerror 1417

Conditions: One end of the connection should be on a node running 9.2.36 and the other end on a node running an upgraded firmware.

Workaround: None

CSCdx27113

Headline: Sometimes Seconds in Service reported 3601 seconds for one hour

Symptom: Customer experienced 'Seconds in Service' for the frame relay connections sometimes reports more than 100% in service, for example, the value of 'Seconds in Service' for one hour shows 3601 seconds.

Conditions: None

Workaround: None

CSCdx30787

Symptom: IGX, MGX, and BPX mibs cannot be found at: http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

and the OID translator at:

http://www.cisco.com/cgi-bin/Support/Mibbrowser/unity.pl

Conditions: Customers can never find the mibs in the above expected location. Moreover, the oid translator never works for the Stratacom mibs.

Workaround: Call the TAC to find out where the mibs are.

CSCdx33468

Symptom: dspcons shows all connections but dspcon shows "connection does not exit"

Conditions: The network has the following software configuration: SWSW is 9.3.10 BXM FW is MFR.

Workaround: None.

CSCdx34134

Headline: testdelay times out every now and then

Symptom: testdelay from CMGUI/ConnProxy fails every now and then while it passes everytime from CLI

Conditions: None

Workaround: None

CSCdx34855

Headline: dsptech displays a false vc db inconsistency warning

Symptom: Upon login, or invocation of the dsptech command, the display for the VC field is bold and has an asterisk next to it, indicating there is a VC inconsistency -- even when there really is not an inconsistency.

Conditions:

1. There are a large number of connections on the node, 14,000 or more.

2. The user logs in and sees the dsptech login screen or they manual invoke the dsptech CLI command, while connections are still being added.

Workaround: Wait until connection additions have stopped, and then invoke the dsptech command.

CSCdx34887

Headline: Incorrect status reported for failed connections due to open space calculations.

Symptom: Connections failed to route but the dspcon command displays their status as "OK" and the "Path:" as 'looking for a route'. The dspalms command does not show the correct number of failed connections.

Conditions: The open space calculation incorrectly checks the path as OK to route the connection, but the path is actually NOT OK due to lack of resources such as load and conid.

Workaround: The dsprrgrps command can be used to get the accurate number of connections requesting reroute (failed connections).

CSCdx34916

Headline: Routing open space calculation incorrectly checks the max. VPC limit

Symptom: Connections are not routed but dspcon command displays the status as "OK" and "Path" as "looking for a route". The dnib and dspload commands show inconsistent Conid usage.

Conditions: Vpc resource on a trunk is almost used up and only one VPC conid is left. The connection fails on this trunk because the lack of VPC conid.

Workaround: Make VPC conid resource available to route the failed connection by either adding new trunks or free up some VPC conid resource on the trunk with the problem.

CSCdx37714

Headline: After Runrev IGX hangs when performing Ungraceful upgrade.

Symptom: When performing runrev on an IGX node with only one Processor (Ungraceful Upgrade), the node can hang in boot mode until a terminal is connected to the control port. Once a terminal is connected the screen will display "Transition to online in progress" and will recover with the new SWSW rev. In the node log you will often see the NPM has restarted due to either a watchdog or software abort, as opposed to Restarting due to Primary revision change.

Conditions: Single NPM node with no connectivity via control port either by local or terminal server. Nodes can be heavily loaded or have no configuration on them other than name/num/date an so forth.

Workaround:

1. The first workaround is already known and that is to have a terminal connected via the control port. (Not suitable in your scenario). This is the reason the problem has not been reported/documented before as discussions with other engineers and on our internal forums show that there are no examples of Single Processor IGX's having no connectivity via the control port. The Cisco Labs all have the Control Ports connected to a Terminal Server and customer examples of single node upgrades have had engineers onsite.

2. You can also recover the nodes remotely by using an Engineering command called "setimage". This command sets the SWSW level for use in code patches. If you set the required upgrade SWSW level and issue the runrev command the node will again remain in boot mode. However, you can connect via the Ethernet port and perform the Setrev command to force the node to rebuild with the correct revision.

3. If you connect the AUX port to the Control port using two standard 25-pin D types and a terminal cable, you can make the node rebuild correctly with the new SWSW revision. If you wire the control port to the below specification you ensure the node rebuilds and comes back online with the new rev. Testing has shown that inserting wires into the below pinout either before a runrev or after when the node is in boot will have the same effect.

TX 2 ------------- 8 CD
RTS 4 ----------5 CTS
DSR 6 ---------20 DTR

Pin Outs of the interface can be found at below URL: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/igx8400/8_5/ic85/igxicbl. htm#xtocid483424.

4. A further method of ensuring that the nodes recover after a SWSW upgrade is to have a redundant NPM card. No nodes failed when the node was configured in a redundant mode. In testing the same two card types were used in a single node and performed upgrades through 9.2.33, 9.2.38, 9.3.24, and 9.3.36 without problems.

5. The best option found so far to get around this problem is to disable DTR in the cnfterm for the control port. This has also been found to recover the node after the runrev has been issue.

CSCdx39692

Headline: swerror 1012 on doing dspchuse on a UXM card

Symptom: swerror 1012 is logged on UXM cards

Conditions: Execute "dspchuse" command on a UXM card

Workaround: None

CSCdx48018

Headline: swerror 502 and 504 on a bpx node in upgrades network

Symptom: sw errors 502 and 504 get logged

Conditions: None

Workaround: None

CSCdx48315

Headline: time zone not specified in event, error or abort logs

Symptom: The event log, error log and abort logs do not specify the time zone for when the event, error or abort occurred.

Conditions: This always occurs.

Workaround: None.

Further Problem Description: This can make debugging of a customer network a little more difficult if time zone changes have been made because support cannot easily or concretely determine when an action occurred.

CSCdx48581

Headline: Traffic leaking on IGX trunks upon remote loopback with UXM Y-RED

Symptom: Traffic leaking on IGX trunks upon remote loopback with UXM Y-RED

Conditions: Add trunk remote loop back with UXM Y-RED

Workaround: None

CSCdx48623

Headline: 9084/BC06 when local loop back added to a trunk on a Y-RED UXM

Symptom: A software error 9084 is logged on an UXM with Y-RED configuration when add local trunk loopback on UXM

Conditions: This occurs when addlnloclp is executed on a UXM trunk on a y-red card set.

Workaround: None

CSCdx51883

Headline: Configuring pass sync on virtual trunk doesnt change Pass Sync on all ports

Symptom: Configuring Pass Sync on a virtual trunk doesn't change the parameter on all the virtual trunks sharing that physical interface.

Conditions: Changing the parameter on a lower numbered virtual trunk doesn't affect the higher numbered virtual trunks where as the warning message displays that the parameter will be changed on all the virtual trunks on that port.

Workaround: change on highest numbered virtual trunk on a port.

CSCdx59734

Headline: SLT: swerr 524 is logged on BPX

Symptom: swerror 524 is logged

Conditions: Node has SW Error 524

Workaround: None

CSCdx65552

Headline: Wrong alarm reporting when APS 1:1 configured on BXM

Symptom: Remote SIGNAL FAIL alarm reported as the current APS alarm state.

Conditions: Happens when APS 1:1 is configured and then trunks are upped. One end is seen to report this alarm.

Workaround: None

CSCdx68364

Headline: 1m3 abort logged on IGX

Symptom: 1M3 abort logged on IGX

Conditions: Run over night jobs such as resetcd, switchcc on IGX. This happened on version 9.3.4R of the SWSW. There was a sw error 504(FREE_ERR) logged few minutes before the abort.

Workaround: unknown

CSCdx69339

Headline: 103 logged on IGX when run overnight jobs

Symptom: swerr 103 logged on UXM when running overnight jobs

Conditions: Run overnight jobs such as switchcc, resetcd on IGX nodes

Workaround: Unknown

CSCdx69703

Headline: 9000 logged on UVM

Symptom: SwError 9000 is logged on UVM cards

Conditions: run overnight jobs such as resetcd on IGX nodes

Workaround: unknown

CSCdx69838

Headline: 3M abort message logged on BPX, then BPX to degraded mode

Symptom: 3000000 abort message logged on BPX cause switchcc

Conditions: This particular 3000000 abort occurs because of a card failure that is causing the card to continually log software error 105's. This then causes the messages to be queued up which, if there isn't sufficient memory available will cause the node to run out of memory and then do a 3000000 abort. For the case where this was observed, the node had 15,947 connection -- a very heavily populated node.

Workaround: Periodically the slot that is continually logging the software error 105 that is causing the memory accumulation -- this will clear the queued messages for that slot. Or, remove the card all together.

Further Problem Description: This memory fault is occurring because a BXM was continually encountering buffer full errors for more than 15 continuous hours. 105's are typically caused by faulty FW, and are not expected to occur regularly in the field, and if so, certainly not at the level as encountered by this defect.

CSCdx72680

Headline: 331 fills log on NG upgrade to 934T when on/off (Neighbor Update Errs) enabled

Symptom: swerr 331 fills the log on a BPX node

Conditions: This occurred when a few nodes in the network underwent a non-graceful upgrade to throttle branch, which causes connection reroutes and the on/off flag for "Neighbor Update Errs" was changed from its default of off to on. Turning this flag on causes false 331's to be logged.

Workaround: Use the off command to disable the "Neighbor Update Errs" debug option when routing activity occurs in the network.

CSCdx78034

Headline: 542 CRC error and 1m2 abort logged when upgrade to 9.3.40 on BPX

Symptom: 542 CRC error and 1m2 abort logged when upgrade to 9.3.40 on BPX. Also active BCC report "Flash EEPROM Program Failure"

Conditions: Upgrade sw to 9.3.40

Workaround: These software errors indicate that there is a problem with the memory on the BCC. For such problem user has to replace the card and keep it under observation.

CSCdx84899

Headline: Software Errors 105/100 appeared with SES 1.1.75.103 attached

Symptom: Software errors 100/105 appeared on the BPX with SES version 1.1.75.103.

Conditions: Software error with the following software version configuration: SWSW 9.3.36 SES version 1.1.75.103 BXM FW MFR

Workaround: None

CSCdx85868

Headline: delallsvcrsrc cause APS errors to be sent to CWM

Symptom: After upgrading to 9.3.36 the customer had to issue the command delallsvcrsrc. When this was issued they saw messages for APS being generated in the CWM logs.

1022207183 62 Thu May 23 22:26:23 2002 node1 - Port Id 9.10, state clear on n ode node1 in network XYZ is modified.; .1.3.6.1.4.1.351.1.0.20067 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - Port Id 9.11, state clear on n ode node1 in network XYZ is modified.; .1.3.6.1.4.1.351.1.0.20067 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.5, Working line: 11.5, Protection line: 12.5.; .1.3.6.1.4.1.351.1.0.20101 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node node1 Line 3.2, Working line: 3.2, Protection line: 4.2.; .1.3.6.1.4.1.351.1.0.20101 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.1, Working line: 11.1, Protection line: 12.1.; .1.3.6.1.4.1.351.1.0.20101 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 11.2, Working line: 11.2, Protection line: 12.2.; .1.3.6.1.4.1.351.1.0.20101 0 

1022207183 62 Thu May 23 22:26:23 2002 node1 - APS Activated on network XYZ node1 Line 3.1, Working line: 3.1, Protection line: 4.1.; .1.3.6.1.4.1.351.1.0.20101 0 

Conditions: The BPX was running 9.3.36 and the effecting command was delallsvcrsrc command.

Workaround: None

CSCdx92352

Headline: Changing peak for already enabled TFTP stats does not work

Symptom: TFTP interval statistics peak values are smaller or larger than expected.

Conditions: This problem occurs when a user attempts to change the peak interval for statistics that already have peaks enabled, while leaving the file and bucket interval unchanged. For example, if they started with a TFTP interval stat with a 5 minute bucket, a 60 minute file and a peak interval of say 60 seconds. And they then left all of the other values the same, but changed the peak interval to say 120 seconds, then the operation would "succeed", the high level displays would say that the peak interval is 120 seconds, but the individual statistics would still be doing 60 second peaks.

Workaround: When changing the peak interval, first delete all of the stats then change the peak interval and send the new enable request.

CSCdx93228

Headline: Error message 2004 on the switch

Symptom: Tool gets snmp error message 2004 from the IGX's snmp agent.

Conditions: With SWSW 9.1.12.

Workaround: None.

CSCdy35192

Headline: Minor alarm doesnt clear on CWM GUI BPX icon unless you log into the node

Symptom: Minor alarm doesn't clear on CWM GUI BPX icon unless you log into node

Conditions: an alarm is generated when a card gets pulled from the BPX CWM Topology then shows an alarm on the desktop

Workaround: The only way to clear was to log into the node the CWM topology then shows the BPX no longer in alarm

CSCdy54959

Headline: SW Error 551 clears only on reseating of the BCC card

Symptom: Software Error 551 is logged and the BCC aborts. On reseating the BCC the problem gets resolved.

Conditions: Customer is running 9.3.36

Workaround: Reseating the BCC. Instead of re-seating the BCC following workaround also can be used, - After the error occur and switchover happen. Login to the standby card (which experienced 551) and execute the command 'clrallcnf'. User has to be extra cautious to do this, as it clears the configuration on the card, this has to be done only in the standby card.

Further Problem Description: Software error 551 occur when CRC error is observed in the code space. The recommended solution for this is to replace the card. But sometimes re-seating the card may help since the code is reloaded after the re-seat; doing a 'clearallcnf' also re-loads the code. But it has to be noted that if it is a real hardware issue re-loading the code is not going to help, the card has to be replaced.

CSCdy68473

Headline: Prompt for adding or deleting all loopbacks on IMA is misleading

Symptom: 1. The prompt for adding a local loop back using [addlnloclp] on the primary link of an IMA interface is not clear. It says: "Warning - Loopback all IMA links Continue?" When the user answers no, then only the primary is looped back. However, this is confusing, because answering no to the [addlnlocrmtlp] which can only be done as all or none, will instead cancel the command. 2. Canceling the [addlnloclp] command, by entering the <DEL> or "." at the prompt, does not cancel the command, it instead adds a loopback to the primary link. 3. The prompt for deleting a local loop back using [dellnlp] on the primary link of an IMA interface is not clear, for the same reasons as (1) above. Moreover, this command is used to remove BOTH local and local-remote loopbacks. 4. Canceling the [dellnlp] command at the "all prompt" by entering <DEL> or "." for a local loop back does not cancel the command, it deletes the primary's loopback. 5. The dellnlp command will prompt to delete all local loop backs from an IMA interface when the primary link is specified, even if it cannot be done, a delete all will only work if all are looped back.

Conditions: This problem occurs on IGX IMA interfaces when invoking the [addlnloclp] command or the [dellnlp] on local loopbacks, as explained in the symptom section.

Workaround: None.

CSCdy79353

Headline: Spare bandwidth not fairly allocated between AutoRoute and MPLS traffic

Symptom: Spare bandwidth is not fairly allocated between AutoRoute and MPLS traffic. MPLS traffic will have access to all of the spare bandwidth limiting AutoRoute traffic to its static load.

Conditions: AutoRoute with MPLS overlay

Workaround: Customer installed MPLS only trunks

Further Problem Description: PER 7127 has been raised

CSCdy81298

Headline: Switch does not send ELMI updates to router after changing Dnld type

Symptom: IGX 8410 switch may not send ELMI updates to connected router.

Conditions: It is seen on IGX 8410 running 9.3.36 software version.

Workaround: None

CSCdy89690

Headline: Feeder status changes not logged on BPX hub when BXM runs the protocol

Symptom: BPX does not log feeder alarm change events when the LMI protocol runs on the BXM.

Conditions: The problem only happen when BXM runs the LMI protocol.

Workaround: None.

CSCdy89732

Headline: Software log on standby NPM sometimes cleared after an abort

Symptom:

1. NPM switch over to standby NPM.

2. Event log shows restart reason is a Watchdog Timeout.

3. Abort profile on the standby NPM (dspprf a s t) shows a date and time matching the date and time of the Watchdog Timeout event.

4. The standby error log (abort log in 9.3) is empty.

Conditions: IGX with an abort on the active NPM switches over to the standby NPM.

Workaround: Use the "dmstby" to collect the software log from BRAM on the standby NPM. The software log is from address 0x1010 to 0x19C0.

CSCdz00821

Headline: delshelf is allowed to proceed while there are VSI connections on feeder trk

Symptom: delshelf is allowed to proceed when there are active VSI partitions and VSI connections on the feeder trunk.

Conditions: The problem only happens when there are only VSI but no auto route connections on the feeder trunks.

Workaround: None.

CSCdz02751

Headline: UNKNOWN OAM Cell Rx

Symptom: The field "OAM Cell RX:" on the "dspcon" command shows "UNKNOWN", we expected to see "Clear".

Conditions: Normal operation, no traffic affected, looks like a cosmetic issue.

Workaround: Need to delete the connection and add back.

CSCdz08271

Headline: Rx Port errors on ASI when line is upped but port is not

Symptom: Customer ups a line on an ASI card and after a variable period of time begins to see Rx Port Errors on the output of a dspsloterrs command. Once port is upped the errors immediately cease.

Conditions: None

Workaround: None

CSCdz46757

Headline: SWLOG Error 32 logged continuously

Symptom: SWLOG ERROR: 32 logged continuously

Conditions: Invalid virtual trunk number found in TRUNK_ADDR

Workaround: None

CSCdz48634

Headline: Network clocking split, no warning to user

Symptom: Network Clocking split

Conditions: In the network consisting of IGX and BPX routing nodes assignment of External, Line or Trunk clock references to IGX node may cause network clocking to be split into separate islands consisting of clusters of BPX nodes and IGX nodes

Workaround: Synchronize BPX nodes cluster to IGX nodes cluster by providing reference to one of BPX's nodes using Line, or Trunk coming out from IGX's nodes cluster or use External reference from the same source.

CSCdz53573

Headline: Add an event in node log when ELMI is activated and deactivated

Symptom: Events in the node log indicating when the Relaxed LMI feature (ELMI) enters activated and deactivated states would be useful.

Conditions: Feeder trunk with ELMI enabled, goes into comm fail and clears comm-fails.

Workaround: Look at dsplmistats screen. Set screen updates to 2 seconds.

Further Description: When the Relaxed LMI feature (ELMI) is enabled and a feeder trunk comm failure occurs the feature enters activated state. When comm fail clears feature is in deactivated state. It can also be deactivated for other reasons, such as no traffic polled on trunks, configuration change of feature, and line sampling shut off. These states can be viewed in dsplmistats while they are occurring, but a event log entry would be more reliable to monitor the states.

CSCdz87003

Headline: Test Delay Granularity not accurate

Symptom: UXM testdelay granularity

Conditions: None

Workaround: None

CSCea00485

Headline: Upgrade from 9.2.34 to 9.3.24 APS lines show on their PROT incorrectly

Symptom: Upgrading BPX network from 9.2.34 to 9.3.24 all APS configured BXM 155 DX cards showed to be on their PROT lines after the upgrade. No errors were recorded in either the node or CWM logs, and there was no indication of any switch taking place. Attempts to switch from PROT to WORK had no effect at changing the display, neither did issuing a switchcc. The only way to clear the condition was to switchapsln W-P and then switchapsln P-W using the force option. This suggests the problem is cosmetic only as no user traffic was effected when in the original state. Problem was only found during audit after network upgrade.

Conditions: None

Workaround: Workaround is to switchapsln W-P force, then switchapsln P-W force. Display should then read correctly.

CSCea04404

Headline: HEC line displays t3/636 rather than t3/690 - bandwidth limited

Symptom: UXM T3 lines configured for HEC framing do not reflect the expected bandwidth change from PLCP framing. They display as T3/636 and 96000 cps rather than T3/690 and 104268 cps. The port on such a line does show the bandwidth to be 104268 cps.

Conditions: T3 line on UXM configured to HEC framing.

Workaround: Use PLCP framing for T3 lines on the UXM.

Further Problem Description: This problem does not affect trunks or virtual trunks.

CSCea22154

Headline: upln on BXM-155 logs swerr 5105, inconsistent databases warning on dnln

Symptom:

1. swlog 5105 when upln.

2. dnln on a line gives the following message "Database inconsistency. Inform field support personnel".

3. Checking the CWM network browser shows the ports listed multiple times.

Conditions: None

Workaround: None

CSCea33846

Headline: The point of Slot7 to 7 and 8 on Cross Point is NOT tested by tstber.

Symptom: From 9.2.35, the following two points on Cross Point is NOT tested by tstber.

Active BCC -> Active BCC

Active BCC -> Standby BCC

Conditions: None

Workaround: 'tstber m' command.

Example: tstber m 7 8 0 2 1 20 n;

m:Manual 

7:Primary Slot 

8:Secondary Slot 

0:Destination Port 

2:Qbin Number 

1:destination Channel 

20:BFrams to send 

n:Stop on errors; 

The point of Slot 7 to 8 is tested by this command.

CSCea54762

Headline: AIS not reported by BPX dspcon, until dspchstats is executed

Symptom: AIS not reported by BPX via dspcon command. If dspchstats command is issued on the connection, then dspcon will show the correct AIS state.

Conditions: BPX running switch software 9.3.36. BXM firmware is MFT.

Workaround: Issue dspchstats command prior to dspcon command.

CSCea55566

Headline: dsptrkerrs reporting large amounts of COMM FAIL on trunks after switchcc

Symptom: After a switchcc on an IGX, most if not all trunks reporting large amounts of COMM FAILs using the dsptrkerrs command. The log does not indicate any COMM Breaks however.

Conditions: IGX node is running 9.2.41 SWSW under normal load and condition is reporting large amounts of COMM FAILs after a switchcc is issued. Please note the errors only seem to occur during the instant the switchcc is in progress. The errors do not continue to increment once the switch is complete.

Workaround: None

CSCea56662

Headline: addcon returns Other end QIR out of range for this end card

Symptom: When trying to add a ABRSTD connection type only using ATM classes 1 and 7 (only), the connections returns "Other end QIR out of range for this end card" message.

Conditions: "addcon" using ATM class number 1 and 7. This problem can be seen in 9.3.45 and 9.3.36

Workaround: None

CSCea56907

Headline: inter card connection between two BXMs is not programmed correctly

Symptom: Failed connections on the SES. Channel Alarms on the feeder node.

Conditions: Customer suddenly notice failed connections on the SES. Connections were also in alarm on the feeder node. Rebuilding the BPX segment of the connection fixed the issue. It seems that two BXM cards that has Y-red not communicating to each other. Inter card connection between the two BXM's are not programmed correctly. BPX is running 9.3.36 and SES has 1.1.75 code.

Workaround: Rebuilding the middle segment on the BPX fixes the issue.

Further Problem Description: This seems to be the inter card connection problem between two BXM's. BXM service modules are not communicating to each other.

CSCea58058

Headline: addcon for an SIW conn doesnt work in a job from the Frame Relay side

Symptom: When you have an addcon statement in a job for a SIW connection. The connection doesn't get added correctly if local connection is the Frame Relay side. The conn gets added as an ATFR instead of ATFX. Manually adding the conn with the same parameters on the Frame Relay side and it works.

Conditions: This is only seen when the runjob is carried out under the conditions stated in the description.

Workaround: 1. Addcon manually 2. Run the Job from the ATM side.

CSCea67768

Headline: Non dax connection information is not updated after dax connection is deleted

Symptom: Non dax connection information is not updated in database after dax connection is deleted.

Condition: CWM 9.2.09 (patch 10/13) BPX 9.1.22/9.2.37

Workaround: None

CSCea76950

Headline: Node Abort, following swerr 100, 502, 589 and 504.

Symptom: Following a swerr 100, the node ran into memory management problems with led to an abort. This was indicated by swerr 502, 589 and 504 in quick succession. The abort was 1000003. A basic debug of the errors indicate that the swerr 100 was that the message does match the command and is invalid. Error 589 has Allocated memory block with string ... 1000003 abort has Fault address of FACE

Conditions: There are no specific conditions known to be required at this time. Network running normally with average loading and no reported maintenance or outage activity.

Workaround: There appears to be a memory management error while handling the response mismatch error condition. If you can identify and avoid the mismatch error condition you can avoid the defect in handling the error condition.

CSCin09100

Headline: SWerror 55 was logged in the entire n/w of bpx/igx when fallback

Symptom: On fall back to 9.3.11 on the bpx/igx nodes SW55 was logged on all the nodes in the network.

Conditions: This occurs when the trunk of one of the igx feeder connected to a bpx goes into comm failure.

Workaround: Reset the trunk card on the igx, And the comm failure goes off.

CSCin40238

Headline: Protocol by card field does not refresh on cnftrk

Symptom: Protocol by card field on the cli command cnftrk does not refresh after executing the command.

Conditions: Whenever the user wants to configure the parameter protocol by card using the cli command cnftrk <slot.no>

Workaround: Issue some other cli command and then issue dsptrk.

CSCin42263

Headline: SWLOG 590 - Multiples

Symptom: SW Log seen on BPX

Conditions: None

Workaround: None

Anomalies Fixed in Release 9.3.47

Anomaly Status Changes in Release 9.3.47

The following table lists anomalies that have changed status since in Release 9.3.47. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.

Anomalies Fixed in Release 9.3.45

Anomaly Status Changes in Release 9.3.45

The following table lists anomalies that have changed status since in Release 9.3.45 as of 12/12/02. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.

Anomalies Fixed in 9.3.42

Anomalies Fixed in 9.3.40

Bug ID	Description
CSCdk69912	UFM programming overrides VC_Q settings in non-standard parameters
CSCdm12850	The system idle time can be under-reported to VNS through SNMP
CSCdm60699	Async updates are sent incorrectly when VCQueue fills up
CSCdm75577	100% traffic discard at ATM end of a ATM-FR conn, added from FR side using CWM
CSCdp04164	DC Voltage Alarm - Need to increase upper alarming limit
CSCdr26161	Resetcd h of UXM during burnfwrev leaves card in burnfw state
CSCdr34820	more than 2 connections appear on single channel of DSP
CSCdr43327	If BME card is present we cannot use 0 option to burn firmware
CSCdr64816	VoiceEndptStatus returns offHook for all channels
CSCdr76559	A-bit on NNI ports doesnt clear when LMI removed and added
CSCds03159	BCC4V logged Abort 1011 after reinserting active CC
CSCds10019	Add more information to chklm and dsplm help screen
CSCds10107	New Commands for testing Voice channels (tonegen, dsptone, clrtone, cnftone)
CSCds29404	Enable cell routing is not part of robust message
CSCds37220	after switchcc, dspapsln may show aps deactivated
CSCds66268	copycons does not generate warning message
CSCdt71711	Bad Node Nib error 419 in Flex Switchcc Test
CSCdt86650	RAS: Corporate login to dsptech as default screen
CSCdt88340	Don't allow the M/F switchapsln switch the APS line backward
CSCdt98231	swerr 9098 logged after reinsert back card for VSI part deletion
CSCdu00161	Connection, Line and QBin interval statistic values displayed are incorrect
CSCdu21187	Temp a-bit failure caused by switchcc, even with feeder alert enabled
CSCdu26594	Remove the logging of 3064 when slave detects reduced number of cons
CSCdu34126	UXM trunk configs give incorrect value for selected cable length
CSCdu34853	vlcon shows wrong pref status after rrtcon reroute at master
CSCdu35011	Cannot configure E1 lines for unframed mode
CSCdu36770	memory wrt: rr_bld_cbrt_path() overwritten next long of rrt_path/rrcb_path
CSCdu38022	CLI allows ECN threshold to be greater than VCQ for incomplete set of parms
CSCdu46642	IMA trunk not allocating correct no. of DS0s
CSCdu47810	Need SWSW option to configure UXM/BXM ILMI for number of PVC changes per trap
CSCdu49568	1M3 abort upon using addport
CSCdu50924	Reroute wait timer (CM parm 9) was applied to derouted conns
CSCdu53235	SWERR 2051 logged without the addition or deletion of statistics
CSCdu55802	dspfwrev screen shows incorrect information
CSCdu58349	snmpwalk shows sysUptime 497 days after initialization
CSCdu59473	Not able to add FR conns and config/change FR class
CSCdu65259	CLI for cnfsct name failures does not give adequate help
CSCdu70637	rrtinf inprog output is not usable for text screen captures
CSCdu73638	SNMP: cannot add/mod connection to FAIL IMA port with no ACTIVE line
CSCdu75132	Add controller IP to the dspctrlrs screen
CSCdu75709	Informix DB not updated when UFMU front and backcard replace FRM or vice versa
CSCdu77043	UXM IMA trunk fails when adding line to trunk
CSCdu79181	Code added in wrong place to enable VPI Address config on UXM trunks
CSCdu84969	rt-vbr value for atmPortQueueIndex on IGX is not consistent with BPX
CSCdu85702	UXM/BXM card mismatch during upgrades causes LOS
CSCdu88501	swerr 925 for UVM inactive line when switchcc
CSCdu88771	sw error 55 seen after ddcuse command is issued on non-BNI card
CSCdv00082	No appropriate value information help for cnfport command
CSCdv01544	rrtinf inprog displays NOTHING and can log 526 when trunk count is 7+
CSCdv02043	RAS: Expand standby mem self test to detect parity (1000001) errors
CSCdv02727	Not able to add 2nd VSI controller when 3 or more trks exist on a card
CSCdv03293	Incorrect display of local clock format for dspcurclk
CSCdv03346	switch.m interface atmEndptOeEfciQSize atmEndptEfciQSize inconsistent
CSCdv03428	logical slot used with phycd_get_attr() in get_sonetiftable_int and get_shelfs
CSCdv04095	physical slot pass in to get_line_fmt() which expect logical slot
CSCdv06569	RAS: Expand standby mem selftest to detect parity (1000001) errors- IGX change
CSCdv08233	High LAN traffic can lockup node UI and cause 3M, or 52 aborts
CSCdv08861	Flood of SWerr 9000 when adding voice con on CVM that do not support voice
CSCdv08902	unique error literals needed for bkcdtype_get_name()
CSCdv09343	Code decompression error for IGX
CSCdv10468	addcon with insufficient UBUs causes 1m3 aborts on UVM
CSCdv12068	dspnds does not show all options (missing -q -x)
CSCdv12776	Misc. enhancements for Deferred conn alm gen feature
CSCdv12786	Total BW of VSI partitions on BXM card can exceed its backplane speed
CSCdv13914	Correct spelling of EPD in dspconcnf
CSCdv14343	AR 32K LCN limit and vsi cnf not handled correctly get_unreserved_chan_cnt
CSCdv15863	SNMP agent does not set XLMI default vpi.vci or atmPortMgmtProtoOnCard
CSCdv15924	RAS: enhance swerr info for vsi channel alloc failure
CSCdv16069	Line functions accept feeder trunks as input and can cause errors or aborts
CSCdv16980	Change dsptech login to always show dsptech, not just when no probe
CSCdv17884	move cnfrrcpu command to connection help group
CSCdv18027	Problems with dsptech login mechanism
CSCdv19657	get_free_lcn must use a swerr code rather than failure return value for error
CSCdv19842	Add description for SET operations on ds3ClkSource/sonetIfClkSource
CSCdv21091	BNI Total cells rx stat requested twice in 0x56 msg affects def. con alm gen
CSCdv22642	PROJ: CLI cleanup - Remove obsolete fields/commands
CSCdv24166	F4-F5 mapping enabled even when no available channels on the card
CSCdv24220	ddcuse has wrong code and is probably an obsolete command
CSCdv24530	Reducing IMA retained lnks should be blocked if Max BW becomes < Req. BW>
CSCdv24685	hot standby mismatch causing loss of O.151 OAM and XLMI support on active card
CSCdv25544	dspcd does not show mismatch information for X-LMI feature mismatch
CSCdv26618	dtrkcnfg needs to show if trunk active or not
CSCdv27309	adding a new prefer path should cancel the reroute timer
CSCdv27346	swerr 9082 logged on performing tstconseg or tstpingoam
CSCdv29727	9083 when trunks statistical reserve is set to the trunks line rate
CSCdv30106	STATS missing from TX Clp x DSCD
CSCdv30438	BPX: switchyred on BXMs causes AXIS NWIP to go unreachable via CWM
CSCdv31539	ILMI Neighbor Discovery mismatch cleanup should not cleanup XLMI information
CSCdv31936	Fail to add Master VP-Tunneling connection on IGX/UXM
CSCdv34258	Graceful upgrade from a pre 9.2.35 release does not map post 9.2.35 parms
CSCdv34759	Enhance dspconcnts to display connection endpoints terminated on cards, trunks
CSCdv35146	2 min data hit after switchyred when 2ndary card still programming channels
CSCdv35295	Cisco view shows Active and green color for FAILED UFM ports in IGX
CSCdv36176	vt does not indicate that we are logged into a Standby Controller card
CSCdv37628	polling type toggled to 2 and back to 1 during switchcc
CSCdv38469	tstber fails on BXM if VSI enabled with VPI = 0 or 1
CSCdv38587	Local and remote loopback on individual IMA links fail to loop traffic
CSCdv40684	dsplmistats, does not display the status of protocol, also no Node Status Cntr
CSCdv42399	not able to add aps line after deleting
CSCdv42531	dspctrlrs always shows default ip address 192.0.0.0 of MPLS VSI controller
CSCdv43983	Switchyred job doe not work when VSI is active on BXM
CSCdv44412	Cannot configure stat level on standby card of y-red pair
CSCdv44928	upport on UFMU card does not enforce 24M oversubscription limit
CSCdv45621	[dspprfh] indicates <active> even if invoked from the standby cc
CSCdv48264	Inactive Port Alarm Config is defaulted to ENABLED upon port activation
CSCdv51156	9340REGR: Swerr 9082, and node unreachable after upgrade
CSCdv55045	dspselftst shows CBUS Not Run
CSCdv55322	Usage info for dspviacons not updated
CSCdv55819	enhancement to display load units on user ports
CSCdv55862	PROJ: Add SNMP Support for IGX/BPX Alarm Masking
CSCdv57337	addjob/cnfport aborts (1m3) when the command times out
CSCdv58342	dspcd screen overflows for BXM-E card supp. Trk VC Shaping
CSCdv58824	yred: logical slot does not sync up SR2048 attribute in add/del yred
CSCdv58954	dsplogcd shows UFM port active but dspports shows failed
CSCdv59751	dsptrkutl on a feeder trunk doesnt showing any feeder connections
CSCdv59831	dspchoid displays UXM for URM Cards
CSCdv62358	cannot clear tstpingip counters
CSCdv63422	atmcls for UBR connections does not work
CSCdv67269	Extend Cline Robust Message to include some more useful fields
CSCdv68534	bkcd insert and yred alarm messages are logged during a switchcc
CSCdv68775	Invalid CBA array access corrupts SVC Hash Table protection pad
CSCdv69165	BXM mismatch after the stats level changed and BCC rebuild
CSCdv69576	RAS: Reprogram LMI & IP SAR connections on moving protocol & switchyred
CSCdv69717	Incr CDV & F4/F5 AIS Dect values reset to defaults after upgrade or switchcc
CSCdv70413	X-LMI port comm fail causes remote end cons in alarms after switchcc/rbld
CSCdv70803	Observing SWERR 1128 during degrade mode testing
CSCdv70946	PROJ: VC Merge on UXM - Project Checking
CSCdv71074	swerr 45/3010 upon depletion of card lcns
CSCdv71138	swerr 9082 logged on switchyred
CSCdv74130	New default power voltage threshold
CSCdv75008	Adding a con when feeder is in comm fail causes alarms when defr con is active
CSCdv75658	Code defects caused due to latest merge into 9340 baseline
CSCdv76026	Wrong check in cnftrk for DTR toggling feature
CSCdv76336	Rate values for Txvcdscd are different from other rate values
CSCdv76903	CARD FAILED when bringing up 2048kbps NTM-SR trunk, HW errs logged
CSCdv77061	X-LMI port comm fail should condition the remote end connections
CSCdv78268	Cnftrkparm on NTS Queue Depth Rejected with Unrelated Range Check
CSCdv78474	PROJ: 9.3.40 Unidirectional FCES and Policing
CSCdv78530	Deferred conn alm gen feature doesnot work when LMI protocol runs on the card
CSCdv78776	dsptrkutl: dsptrkutl is blocked after full rebuild and not recovered
CSCdv81030	CLI dspcurclk on bpx node causes sw err. 532, 26, 539
CSCdv81068	re-numbering bpx node causes 254
CSCdv81287	Prefix warning: Analyze uninitialized variable usage in Pis_fw_req_valid()
CSCdv83923	Default configuration for BXM port and feeder trunks should be NO-SHIFT
CSCdv84329	Prefix: Uninitialized fields in MSG_LETTER in abort_ldiag()
CSCdv85306	PROJ: CLI Cleanup - Remove the obsolete Adaptive Voice from display and cmd
CSCdv87061	Send correct field scrm_payload for payload scramble in Cline Object Msg
CSCdv87642	VT Oversubscription chkin
CSCdv88708	SWerr 45 on switchcc - VSI related
CSCdv90733	relaxed lmi (dsplmistats) reports wrong info on a los
CSCdv90966	swerr 384 during F4-F5 config. validation
CSCdv91284	SW ERR 1013 on fallback
CSCdw00642	Null Timer Calculation Should Not Be HUGE_DELAY
CSCdw01517	SNMP Set/Get operations incomplete on NTM-SR trunks
CSCdw07452	31 voice channels are send to cwm for CVM T1 card
CSCdw08309	Command cnfchrps is not listed in alphabetical order in help screen
CSCdw10635	ARP message pointer used before initialized, possible SNMP 1M3 abort
CSCdw10654	Prefix errors in 9.3.40 igx baseline
CSCdw11748	Trunk VC shaping does not work properly on BPX fdr trk
CSCdw11872	potential clocksrc table memory corruption
CSCdw12925	dspcd screen display is difficult to read due to merged strings
CSCdw15039	Command addloclp loops both ends for DAX connections; which is incorrect
CSCdw15054	Allow addlocrmtlp command for DAX connections
CSCdw15064	CBUS message send to BXM for addloclp needs to be corrected
CSCdw15075	addloclp command should not be allowed on connection end points on ASI port
CSCdw16041	cnfbusbw does not work in a job
CSCdw16076	Diff. path delays configured for master & slave end points of a connection
CSCdw16364	SWERR 45 and cannot uptrk on a 60K LCN BXM-E card
CSCdw16899	SNMP set/get not working for ds3LineLclLpbk and sonetLineLclLpbk
CSCdw19247	via/slave node lock up routing
CSCdw19941	swerr 9093 when configure T3 trunk line framing to be HEC
CSCdw22629	Uninitialized var used for LCON update in int_via_updt
CSCdw23663	cnfnodeparm (job lock timeouts) wrong init value between 9.1 and 9.2
CSCdw26065	Modify the command names to cnfintalm and dspintalmcnf, to reflect the age
CSCdw27395	Cannot ADDTRK after changing CNFTRK NTM-SR trk from 2048kbps to lower value
CSCdw29721	prefix: in syntax mode, cnfpref does not init hops
CSCdw30934	Deferred conn alm gen may/may not get deactivated upon full rebuild
CSCdw32389	dspqbinstats and dspcntrstats can show negative values
CSCdw32729	Improve runrev to detect unsafe standby updates
CSCdw32857	Enabling IMA on single T1 uses extra DS0
CSCdw34453	dsptrkstats/clrtrkstats on down BNI card produces SW log 8096
CSCdw34723	CNFTRK does not work in JOB mode
CSCdw39995	APS act line is not sync between SWSW and FW after BCC switch
CSCdw40453	RAS: Improve dsptech and dlcon to list the number of dax cons on the node
CSCdw43792	UAS stats not collected when line in alarm, caused by CSCdk44173 fix
CSCdw45129	Changing the min tx rate at one end of the VT causes 9093 at other end
CSCdw46236	VC Shaping should use VI Max TX rate to work with VT oversubscription feature
CSCdw48298	Can burn CVM firmware onto UVM & vice versa
CSCdw48570	Cannot add a job trigger to a virtual trunk on a BPX
CSCdw49673	Allow VC Shaping on UXM feeder trunks when IGX is a feeder node
CSCdw50142	Max Tx rate rounding off error on added trunks
CSCdw51173	need to document rt-VBR index in atmPortQueueIndex
CSCdw52505	VC Shaping (WFQ) is incorrectly applied to timestamped traffic
CSCdw53935	Use of connection max delay values are inconsistent
CSCdw54838	on off bits changed on one node after bpx sw upgrade
CSCdw55273	Redundant calls to clear mismatch
CSCdw55317	Slot alarms are not generated for Monarch Specific card errors
CSCdw58091	Cpu usage is... message is not logging after graceful upgrade and switchcc
CSCdw58129	BXM went into mismatch after swsw upgrade
CSCdw58704	Free allocated memory errors logged by SNMP process- swerr 502 589 504
CSCdw59553	dspcd screen shows pcr instead of PCR
CSCdw63725	Connection requires 11 hops to route fail to report as failure & CPU idle low
CSCdw64831	Heading for VT Oversubscribe feature appears for physical trunks in dsptrkutl CLI
CSCdw66301	swlog error 50 observed
CSCdw68727	Abort 1000003 logged on BPX after executing dsptrkutl following rebuild
CSCdw68912	dcct LCN information overwritten for DAX connections
CSCdw71520	help for ip commands causes last line overflow for nwipcache entry
CSCdw71912	dsptrkutl shows non-existent connections
CSCdw74281	addlnlocrmtlp on IGX/AF side of trunk causes comm-fail should be Clear-OK
CSCdw75500	swerr 5050 generated upon cba_verify after deleting vp-tunneling daxcon
CSCdw75730	cnfasm change to temp threshold doesnt reflect in dsppwr screen
CSCdw79108	BPX node with SWSW 9.1.24 does not sync up with CWM
CSCdw80264	10 hop cons fail to route when resources available
CSCdw84340	dsputl command does not work for UVM/CVM connections
CSCdw86061	rs_get_vpivci() does not correctly check for LMI/ILMI VCI
CSCdw86065	CNFRSRC will not allow VPI over 255 although port NNI
CSCdw88571	Incorrect feeder trunk channel programming for dax-cons
CSCdw92030	Port speeds above 6144 Kbps on UFMU-HSSI are reported incorrectly to CWM
CSCdw94435	dclk output doesnt get updated
CSCdw95202	SNMP support for Trunk VC Shaping and cnftrkq enhancement for feeders
CSCdx06654	line/trk recovered even the active APS line has LOS
CSCdx07451	AutoRoute channels allocated beyond 32768 when VSI Slave channels used on card
CSCdx08325	Unable to add connection from FR end point to ATM feeder end point
CSCdx08838	IGX reports PRI Loss (CLOCK) when deleting line clock source
CSCdx10239	Memory leak in dsptech (swerr 501, 3000000)
CSCdx10874	Enabling LMI on VSI feeder causes unreachable (always) + comm-fail(9340)
CSCdx16103	Trunk channel programming rejected(9082) when connection has PCR > port rate
CSCdx17275	UXM line looped back after sw upgrade
CSCdx17933	Dangling VLCONs and inconsistent trunk loading/conid
CSCdx18387	dsplns/dspports alarm masking reverse video is not captured on ASCII screen
CSCdx19254	swerror 521 on bpx node in upgrades network
CSCdx20304	addfrcons and dspfrchan no longer exist
CSCdx20323	752 logged when FW upgraded
CSCdx27972	RAS: Incorrect Open space calculation when inconsistent conids exist
CSCdx29500	BPX clock does not go to Tracking mode if current clock source is on port 1
CSCdx36217	connection continuously re-routes after active CC fails with swerr 47
CSCdx38407	dspviacons causes session to lockup, IDLE time of 0 and eventually 1m3 abort
CSCdx47173	Incorrect display of IGX FDR NPMs after an upgd
CSCdx57483	Removed ASM card on a BPX cage displayed as Empty Reserved for BCC
CSCdx57872	FRM port alarms are disabled by default on upgrade
CSCdx58152	addlnloclp/addlnlocrmtlp does not work when secondary UXM-IMA-YRED active
CSCdx63511	Download Aborted logged and UXM to failed status when burnfwrev to A
CSCin10198	CSCdu85702 fix missing from BPX

Anomaly Status Changes from Previous Releases

The following table lists the anomalies that have changed status prior to Release 9.3.42 as of 12/12/02. Changed status means that the anomaly went from open to a state other than resolved. The status field states whether the anomaly is closed, junked, duplicated, or unreproducible.

Additional Deliverables

SNMP MIB

The SNMP IGX/BPX switch SNMP MIB is being provided with the delivery of Release 9.3 Switch Software. The MIB is in standard ASN.1 format and is located in the ASCII text files agent.m, ilmi.m, ilmi_ctl.m, ilmiaddr.m, switch.m, swtraps.m, and errors.m which are included in the same directory as the Switch Software images. These files may be compiled with most standards-based MIB compilers. There were no MIB changes in Releases 9.3.11, 9.3.20, 9.3.24, and 9.3.36.

Switch MIB changes of Release 9.3.35

voiceEndptState

New object

Switch MIB changes of Release 9.3.30

The following Switch MIB changes have been introduced since Release 9.3.30. The changes include modified objects and new objects.

atmEndptTable

Modified objects

New objects

sonetIfTable

Modified objects

atmTrunks

Modified

ShelfRtrSlotInfoTable

New objects

Switch MIB changes of Release 9.3.11, 9.3.20 and 9.3.24

Switch MIB changes of Release 9.3.10

The following Switch MIB changes have been introduced since Release 9.3.10. The changes include obsolete objects, modified objects, and new objects:

switchIfTable

Modified objects

frLportCnfTable

Modified objects

New objects

atmPortTable

Modified objects

New objects

atmPortStatTable

Modified objects

New objects

atmEndptTable

Modified objects

atmTrunkStatsTable

Modified objects

New objects

rsrcPartiTable

Modified objects

rsrcPartiPvcTable

Modified objects

atmQbinTable

Modified objects

vsiCtrlrTable

Modified objects

New objects

Switch MIB Changes to Release 9.3.05

atmPortTable

New objects

Modified objects

atmPortQueueTable

New objects

Modified objects

atmEndptTable

Modified objects

switchShelf configuration branch

New objects

atmTrunks table

New objects

Modified objects

rsrcPartiTable

New objects

Modified objects

Obsolete objects

This object limits the number of LCNs to be reprogrammed in a continuous loop so that other software processes get a fair share of the CPU time.

rsrcPartiPvcTable

This table is only available for BXM cards. The AutoRoute resource partition does not exist for a down line.

New objects

serialPortTable

Modified objects

Switch MIB changes to Release 9.3

The following Switch MIB changes have been introduced since Release 9.2.31. The changes include obsolete objects, modified objects, and new objects:

switchIfTable

Modified objects

atmPortTable

This table provides the manager a detailed view of the ATM ports available on the switch.

New objects

Modified objects

Obsolete objects

atmEndptTable

This table is used to model a PVC endpoint and contains the traffic parameters for the ATM endpoint.

Modified objects

shelfSlotInfoTable

New objects

Modified objects

ds3LineTable

This table provides the manager a view of the DS3 interfaces on the switch and supports SET functions.

Modified objects

ds3StatsTable

New objects

Modified objects

sonetStatsTable

Modified objects

atmTrunkStatsTable

Obsolete objects

vsiCtrlrTable

This new table contains the configuration for VSI controllers. The objects are advertised to all of the VSI slaves on the switch when the configuration is changed.

New objects

Default Values

Cisco BPX 8600 Nodes

BNI-T3

BNI-E3

BNI-155/155E

BXM-T3

BXM-E3

BXM-155

BXM-622

Cisco IGX 8400 Nodes

UXM-T3

UXM-T1-IMA (1 physical line up)

UXM-T1-IMA (4 physical lines up)

UXM-E1-IMA (1 physical line up)

UXM-E1-IMA (4 physical lines up)

UXM-E3

UXM-OC3

NTM-T1

NTM-E1

NTM-SR

Appendix A—BXM Firmware MFX Release Notes

About the Firmware MFX

BXM firmware version MFX supports all existing interfaces and models of BXM hardware. The tables in this section outline various levels of hardware revisions supported for BXM firmware version MFX.

Front Cards

Front Card for APS Compatibility

Back Cards

New Features supported in BXM Firmware MFX

Special Installation/Upgrade Requirements

APS Issues

Upgrading from MEK and lower firmware to MFX when feeder trunks are utilized with APS while the BPX node does not have APS requires the following procedure:

Step 2 After PXM1-based MGX dspapsln shows both lines OK, delete the APS line on the BPX.

Step 5 Reconfigure both PXM1-based MGX and BPX to use the appropriate APS configurations.

BXM cards with MCB/MDA firmware or later can be smoothly migrated to the MFA or above version of firmware by using Y-cable redundancy.

To upgrade a BXM card pair in Y-red configuration, complete the following steps:

Step 2 Do a switchyred to switch to the card with firmware MFA or above version.

Step 3 Burn the other card with the desired version MFA or above firmware. Follow the standard firmware upgrade procedure for downloading and burning the firmware into the cards.

Step 4 If BCC SWSW version is 9.1.18 and dspnovram shows 0 or 4 for Number of Channel Stats, go directly to MFC or above versions from MCC.

For APS (1+1) MEx or MFA image versions are not to be treated as compatible with MFx (minus MFA) image versions. During an upgrade procedure from MEx or MFA image to MFx (minus MFA) image, both cards must be upgraded to the MFx (minus MFA) image with minimal interval between them.

The incompatibility is due to APS intercard messages from one end not being recognized by the other end. See bug CSCdu67053 for the symptoms caused by this incompatibility.

Channel Statistics Issues

While upgrading from firmware, on OC3, 1 port OC12 BXM cards, if stats level on BXM is greater than 1, use one of the following upgrade procedures listed below.

Upgrade from firmware revision MEA or higher.

Upgrade from firmware revisions lower than MEA.

A firmware burn must not be interrupted. A card reset in the middle of burn firmware results in the BXM being maintained in the core state (identified by blinking yellow LED) or failed state (identified by a solid red LED). In this case the dspcds screen reports the card as FAILED. This state can be recovered by reburning the firmware into the card.

Features Obsoleted

2. From versions MFJ to MFN channel statistics level 0 is no longer supported for BXM-155-4, BXM-155-8, BXM-622, BXM-622-2, BXM-T3-8, BXM-T3-12, BXM-E3-8, BXM-E3-12 models. In MFN onwards conditional support for statistics level 0 is revoked. See the Notes, Cautions, and Clarifications section point 13 for more details.

3. In all other models channel statistics level 0 is supported by all firmware versions (BXM-155-8DX, BXM-155-8D, BXM-155-4DX, BXM-155-4D, BXM-622-2DX, BXM-622-2D, BXM-622-DX, BXM-T3-12EX, BXM-T3-12E, BXM-T3-8E, BXM-E3-12EX, BXM-E3-12E, BXM-E3-8E).

Notes, Cautions, and Clarifications

1. BXM Model F firmware is intended for use with 9.3 switch software. BXM Model F firmware may be used to upgrade BXM cards during the upgrade process from SWSW Release 9.2 to 9.3. BXM Model F firmware has not been tested for compatibility with SWSW Releases 8.4, 8.5, and 9.1. It is compatible with IOS version 12.05t2 or greater for MPLS.

3. Protection Switching based on BER on BXM may not comply to standards. The GR-253 and ITU-T G.783 requires that switching be completed within 60 msec from the time the error starts. BXM is unable to detect BER threshold crossing until the next poll, which occurs every 250 msec. Thus, switching time may be up to 250 msec under certain circumstances.

4. In APS 1+1 default configuration, both back card LEDs show green when primary card is active and selection is from PROT line. When primary card is active and it is selecting from PROT, PROT backcard should be green, since it is carrying traffic. WORK backcard should also be green since that is the physical path for the primary (and active) card to pass traffic. Backcard LED green means the backcard is directly or indirectly carrying traffic, and pulling the backcard causes traffic disruption (CSCdm53430).

5. In APS 1+1 default configuration and a manual W->P is on and a switchyred is issued, a manual W->P event is logged. By default, on switchyred the new active card comes up in "clear" state. But in this case since there is a manual W->P on, the APS line switches to PROT and the switching is logged (CSCdm53404).

6. In APS 1+1 default configuration if the selected line is PROT and last user request is clear and a switchyred is issued, line switches to WORK. If the last user request is "clear", full automatic APS switching is in effect with the working line being active by default. When there is no last user switch request to switch to any particular line, the working line becomes active. (CSCdm53420)

7. When APS Annex B is added to local end which has the secondary card active, the APS trunk goes into Comm Failure for few seconds and then clears. If the secondary card is active, do a switchyred to make the primary card active. Then, add APS Annex B (CSCdm46359).

8. MFK and above versions support LCN CAC for Class of Services. The controller reserves some LCNs for control VC as default. These reserved LCNs cannot be used by any Class of Service in MFT. If all the LCNs for the partition have been used in a version earlier than MFK after the MFT version is updated in the switch, some connections may not be added. These connections try to use LCNs reserved for control VC which is not allowed. Configure more LCNs for the partition to make sure enough LCNs exist for all the connections.

10. APS 1:1 is not supported for VSI in versions before MFE. (Bug CSCdp42996) APS 1:1 should not be configured on ports intended to be used by PNNI or MPLS as after switchover traffic flow is stalled on the protection line for releases before MFE. However, in MFE and above, this problem is fixed.

11. Total bandwidth allocated to all VSI partitions on a BXM should not be more that OC12 rate, 1412832 cps. BCC SWSW allows users to configure more than OC12 rate, in which case all the PNNI connection commit requests are NACKed by BXM.

12. In firmware versions prior to MFF signaling bandwidth for an SES controller was not guaranteed. In MFF and above the signaling Qbin feature has been added (with SWSW 9.3.10 and above and SES image 1.0.10 and above) to guarantee signaling bandwidth.

13. Statistics level 0 for legacy BXM cards was obsoleted in Model F releases until MFN. However, in version MFP and above conditional support statistics level 0 for legacy cards is revoked. Statistics level 0 is not supported if VSI configurations exist on the card.

If a card was configured with statistics level 0 with VSI enabled in a previous release of firmware (Model C or E), upgrading to MFP or above revisions causes a mismatch on legacy cards. To avoid impacting VSI operations, reconfigure the card to statistics level 1 or above before upgrading.

14. Excessive BIP-8 error rates (10-3) which escalate into unavailable seconds (UAS) are now reported to Switch Software as red alarms. This feature is not configurable, and may cause failed connections and rerouted trunks in configurations where APS is not enabled, alternate trunk routes do not exist or on UNI ports. This feature is not active when APS is configured and enabled.

Known Anomalies in MFX

Anomalies Fixed in MFX

Anomalies Fixed in MFW

Appendix B—UXM Model C ACJ Firmware Release Notes

Introduction

ACJ is a firmware maintenance release for UXM card on IGX. Firmware is the same for UXM and UXM-E cards.

New Features

Obsolete Features

Compatibility

Bugs Resolved in ACJ

The open bugs known at this stage are listed in the Known Anomalies section of this appendix. The firmware release ACH also contains the bug fixes done in the Model B firmware up to revision ABL.

Upgrade Instructions

If the firmware being upgraded is not revision ACB or higher, then the firmware upgrade to revision ACH requires an intermediate upgrade to revision ABJ. However, before upgrading the firmware to revision ABJ, the boot code must be upgraded to boot revision 8.

If the firmware revision ACB has not been burned, follow these steps to upgrade the firmware to revision ACH:

Step 3 Upgrade the Administration application firmware to revision ABJ or greater.

Step 4 After the card comes up, upgrade the Administration application firmware to revision ACH.

If the firmware revision ACB has been burned onto the card, follow these steps to upgrade the firmware to revision ACH:

Known Anomalies in UXM Model C ACH

Anomalies Fixed in ACH

Boot Code Requirements

Unsupported Configurations or Applications.

2. Port Adapter PA-A3 on the 7200 series router not supported for "multi-vc" configuration.

5. Adding controllers on trunks is not supported. The controllers must be attached to line interfaces.

6. Usage of IMA interfaces is not supported for attaching the LSCs (Label Switched Controllers) or LERs (Label Edge Routers). This restriction is because of the non availability of IMA interface support in IOS software release 12.1.(3)T for LSC and LER interfaces. The IMA interfaces can be used for trunks between IGX nodes.

7. ILMI implementation does not support service registration and address registration.

Notes and Cautions

1. Switch Software Release 9.3.10 or later is compatible with the following versions of IOS and 7200 port adapter hardware:

2. Changing the VPI range on a UXM interface partition is not causing the Xtagatm interface configuration on the controller to be updated.

When the slave ATM switch reports a VPI range change through an "IFC GET CNFG TRAP" the LSC does the following:

3. Only one Xtag interface corresponding to a partition on a UXM interface that has multiple-partitions comes up. Other Xtag interface based on different partitions on the same UXM interface is not coming up.

The following errors display the messages: VPI/VCI in use or VCI in use. Overloading of the 0/32 tag-control PVC has occurred.

Make sure that only Xtag ATM interface uses the default tag-control-vc of 0/32. All other Xtag ATM interfaces on the same UXM interface should use non-default tag-control-vcs using the "tag-switching atm control-vc" command.

The following example shows xtagatm71 configuration on the LSC connected to 3.3 using default tag-control-vc of 0/32

The following example shows xtagatm71 configuration on an LSC connected to 19.3 using configured tag-control-vc of 90/32

When configuring a Cisco MPLS LSC on T3 interfaces, make sure the payload scrambling option on the UXM T3 line matches the config on the LSC. The default for the LSC is OFF, and the default for the UXM is ON since the lines come UP and CLEAR.

Controller 1 on node tagigx3 is connected to 12.6. If the IP address in the CtrlrIP column is correct, you know that the LSC is being seen by the IGX and vice-versa. Otherwise a 0.0.0.0 displays.

Firmware Filenames and File Sizes

Appendix C—UXM Model B Firmware ABU Release

Introduction

UXM ABU is Model-B firmware release for UXM card on IGX. Firmware is the same for UXM and UXM-E cards.

New Features

RCMP Parity Policing

This feature allows the UXM card to continue to be in service under a low rate of parity errors while informing the user of parity event. The card resets if the error rate exceeds a threshold rate.

Obsolete Features

Compatibility

On IMA trunks this version is not compatible with UXMs Model B firmware versions ABA to ABD.

On IMA trunks Model B firmware (AB*) is not compatible with model A (AA*) because model B is Standards compliant and model A is not. Therefore, IMA trunks must be upgraded together.

Anomalies Resolved in ABU

Upgrade Instructions

Boot Code Requirements

Unsupported Configuration or Applications

Firmware Filenames and Sizes

Notes and Cautions

Appendix D—URM Model B Firmware XBC Release Notes

Introduction

URM XBC is Model-B firmware release for URM card on IGX. The URM is an IOS-based routing module for the IGX. This release is an upgrade from XBB.

New Features

RCMP Parity Policing

This feature allows URM card to continue to be in service under low rate of parity errors while informing the user of parity event. The card will be reset if the error rate exceeds a threshold rate.

URM IOS CLI

This feature improves the management of the URM by allowing access to the IOS CLI running on the URM via the IGX CLI. This feature will also enhance Serviceability by further enabling remote recovery of the URM beyond the RRC feature introduced in 9.3.30 software.

This feature allows users to access the IOS CLI of the URM embedded router from the IGX CLI, so that users can access the router without having to be physically connected to the IOS Console port on the URM backcard

Obsolete Features

Compatibility

Anomalies Resolved in XBC

Upgrade Instructions

No special upgrade instructions in upgrading the URM Admin firmware from XBB to XBC.

Boot Code Requirements

Unsupported Configurations or Applications

The 0/1023 is a special VC used by URM for IPC between Admin Processor and IOS. When configuring MPLS network, do not commit any cross-connect or control-vc on the port. Otherwise, SWERRS or non-working configurations might occur.

Firmware Filenames and Sizes

XBC Firmware Boot Code

XAA Firmware Boot Code

Notes and Cautions

1. The URM back card is hot-swappable; however the IOS processor is held in reset when back card is removed.

2. Card Mismatch might occur since XBA supports both BC-2FE2V and BC-2FE. Card mismatch is declared if BC-2FE2V and BC-2FE are swapped out of an ACTIVE URM card. Back cards of two different types can be swapped only in a STANDBY URM card.

3. If Remote Router Configuration feature is used to burn the IOS configuration in the card, the burned configuration cannot be deleted but can be overwritten only by another configuration.

Obtaining Documentation

Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation on the World Wide Web at this URL:

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated regularly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual or quarterly subscription.

Registered Cisco.com users can order a single Documentation CD-ROM (product number DOC-CONDOCCD=) through the Cisco Ordering tool:

All users can order monthly or quarterly subscriptions through the online Subscription Store:

Ordering Documentation

Documentation Feedback

You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

Obtaining Technical Assistance

Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.

Cisco.com

Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com provides a broad range of features and services to help you with these tasks:

To obtain customized information and service, you can self-register on Cisco.com at this URL:

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The type of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.

Cisco TAC Website

The Cisco TAC website provides online documents and tools to help troubleshoot and resolve technical issues with Cisco products and technologies. To access the Cisco TAC website, go to this URL:

All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:

If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:

If you have Internet access, we recommend that you open P3 and P4 cases online so that you can fully describe the situation and attach any necessary files.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:

Before calling, please check with your network operations center to determine the Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R)

Generally Available (GA)	Feature is ready for wide deployment with no restrictions. Customers deploying GA features are supported by the Technical Assistance Center (TAC).
First Customer Ship (FCS)	Feature is available for controlled introduction to selected customers. To trial an FCS feature, contact your account representative. Customers selected for controlled introduction receive assistance with the test plan review and special support from the New Product Team (NPT) in addition to the normal Technical Assistance Center (TAC) support.

Filename(s)	Size (bytes)
ACJ.000 to ACJ.024	65536
ACJ.025	1762
ACJ.img	784

Filename(s)	Size (bytes)
AC09.000	56624
AC09.img	784

Filenames	Size (bytes)
ABU.000-ABU.017	65536
ABU.018	60251
ABU.img	784

Table of Contents