2.0.13 Release Notes for MGX 8850 [Cisco MGX 8800 Series Switches]

Table Of Contents

Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.13

Contents

Introduction

System Requirements

Hardware Supported

AXSM Cards

PXM-45 Cards

PNNI

Software Compatibility

Compatibility Matrix

Release 2.0.13 System Content

Additional Deliverables for Release 2.0.13

Upgrading to a New Software Release

Upgrade Procedure

New and Changed Information

New CLI Commands

Changed CLI Commands

New Features in Release 2.0.13

Obsoleted Features in Release 2.0.13:

Installation Notes and Cautions

Limitations and Restrictions

Important Notes

APS Status Information

Recommendations

Caveats

Known Anomolies in Release 2.0.13

Problems Fixed in Release 2.0.13

Known Anomalies from Previous Releases

Problems Fixed in Release 2.0.12

Problems Fixed in Release 2.0.11

Problems Fixed in Release 2.0.10

Problems Fixed in Release 2.0.02

Related Documentation

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Contacting TAC by Using the Cisco TAC Website

Contacting TAC by Telephone

Service and Support

Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.13

Contents

Introduction

These release notes describe the upgrade procedures for version 2.0.13, software upgrade procedures, hardware supported by the release, network support, and software limitations. The notes also contain Cisco support information. Follow-on releases are planned to add new features, and can be found in the Marketing Road Map.

System Requirements

Hardware Supported

The following table lists support hardware for Release 2.0.13:

Model

800 Part Number

Revision

PXM-45

800-06147-07

B0

PXM-UI-S3

800-05787-02

A0

PXM-HD

800-05052-03

A0

AXSM-1-2488

800-05795-05

A0

SMFSR-1-2488-FC

800-05490-05

A0

SMFXLR-1-2488-FC

800-05793-05

A0

SMFLR-1-2488-FC

800-06635-04

A0

AXSM-16-155

800-05776-06

A0

AXSM-4-622

800-05774-09

B0

AXSM-16-T3/E3

800-05778-08

A0

SMFIR-2-622

800-05383-01

A1

SMFLR-2-622

800-05385-01

A1

SMB-8-T3-BC

800-05029-02

A0

SMB-8-E3-BC

800-04093-02

A0

MMF-8-155

800-04819-01

A1

SMFIR-8-155

800-05342-01

B0

SMFLR-8-155

800-05343-01

A1

APS RDNT CON

800-05307-01

A0

AXSM Cards

The AXSM card is a double height ATM service module that is compatible with release 2.0 and later PXM-45 based versions of the MGX switch. The AXSM card uses the serial line traces on the MGX chassis to access the 45Gbps crosspoint fabric of the PXM-45 card and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.

The AXSM card provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM card on the IGX, and AUSM card of the release 1 MGX 8850. Other Cisco ATM platforms and other ATM manufacturers' equipment have proven to be compatible.

Line Interfaces for the AXSM Cards

•T3/E3

8 ports per back card, 2 back cards per dual height slot

G.703/Accunet Conformance

•OC3c/STM1

G.703/GR-253 Conformance

8 ports optical per back card, 2 back cards per dual height slot

MMF, SMF intermediate and long reach

4 port Electrical back card

•OC12c/STM4

G.703/GR-253 Conformance

2 Ports per back card, 2 back cards per dual height slot

SMF intermediate and long reach

•OC48c/STM16

G.703/GR-253 Conformance

Single port back card, one back card per slot

SMF Short, long and extra-long reach

ATM Layer Information

•Usage policing supported on all interfaces except OC48c/STM16

•T3 interfaces support both PLCP and direct cell mapping

•64 Logical interfaces — ports, trunks, or virtual trunks (future)

•16 Class of Service queues for each class of service

•Supports independent queues for each ATM class of service

Network Management Features

•OAM functionality per ITU-T I.610

•Fault management — AIS/RDI at F4 and F5 flow

•User selectable continuity checking at connection endpoints

•Loopback diagnostics

•Automatic alarm generation and propagation for interface failures

The AXSM card offers a complete ATM feature set and allows the MGX 8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX 8850 platform. The entirely standards-based design and connection protocols enable installation into any existing network, as well as building new ATM infrastructures.

PXM-45 Cards

The PXM-45 card is a 45-Gbps processor switch module. The architecture of the PXM-45 card contains the CellBus fabric that is used in the current PXM-1 card, but adds the functionality of a 45-Gbps crosspoint switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX 8850. The PXM-45 card provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4-based PXM-1 design.

Reliability, Availability and Serviceability Features

The PXM-45 card is designed to be fully redundant: There are two dedicated slots in the MGX 8850 (dual height slots 7 and 8) that house the PXM-45 card. Highlights of the reliability, availability and serviceability (RAS) features are listed below:

•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.

•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow

•Hardware design ensures that if one or both hard disks fail, the cards will still pass traffic with no interruption, although provisioning could be suspended.

•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXM-45 cards in a system. This was calculated at greater than 100,000 hours.

PXM-45 Card Information

The PXM-45 card supports PNNI software. There are two other components that complete the card set:

•PXM-UI-S3

•PXM-HD

The PXM-UI-S3 supports the following interfaces:

•Two RJ45 10Mbps 802.3 Ethernet ports

•Two RJ45 RS-232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:

Pin

Signal

Direction

Description

1

RTS

OUTPUT

Request to Send

2

DTR

OUTPUT

Data Terminal Ready

3

TX

OUTPUT

Transmit Data

4

SG

Signal Ground

5

SG

Signal Ground

6

RX

Input

Receive Data

7

DSR

Input

Data Set Ready

8

CTS

Input

Clear to Send

•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The following connections are supported:

–RJ48. Pinout conforms to Accunet1.5 Specification

–Wire wrap

–BNC

–DB15

•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.

–PXM-HD

This contains the hard disk for the processor.

PNNI

Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and scales to very large networks.

PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.

PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.

PNNI provides dynamic ATM routing with quality of service (QoS) support as defined by the ATM Forum. PNNI uses link-state and source-state route technology, supports aggregation for private ATM addresses and links between switches, and can scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.

The functions of the PNNI routing protocol include:

•Hello protocol (allows adjacent switches to exchange topology information)

•PTSE (PNNI Topology State Elements) database synchronization and management

•PTSE flooding

•Address summarization and advertisement

•Link and nodal aggregation

•Pre-computation of routing tables

•Quality of Service (QoS) based routing

•Multiple Routing Metrics

•Discovery of neighbors and link status

•Synchronization of topology databases

•Load balancing on equal cost paths

•Load balancing on parallel links

•Load balancing with redundant addresses

•Alternate paths

These PNNI features are supported in Release 2.0 of the MGX:

•UNI 3.0/3.1

•PNNI 1.0 Single Peer Group

•ILMI 4.0

•Point to point ATM SVCC and SVPC

•Support for ABR, CBR, VBR, rt-VBR, and UBR

•Alternate call routing (see separate feature description)

•On demand call routing (see separate feature description)

•Native E.164 and AESA (E.164, ICD, DCC) [formerly NSAP] address format

•Enhanced CAC with per service class policy parameter (see separate feature description)

•Per Class of service overbooking

•Congestion control (see separate feature description)

•PNNI connection and path trace

•OAM fault management

•Address filtering (see separate feature description)

•Intelligent CAC (see separate feature description)

•Call processor redundancy

PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.

Software Compatibility

Compatibility Matrix

Board Pair

Latest Boot Code Version

Minimum

Boot Code

Version

Firmware

Latest

Firmware

Version

Minimum

Firmware

Version

PXM-45

pxm45_002.000.013.000_bt.fw

2.0.13.0

pxm45_002.000.013.002_mgx.fw

2.0.13.2

2.0.13.2

AXSM-1-2488

axsm_002.000.012.000_bt.fw

2.0.12.0

axsm_002.000.013.002.fw

2.0.13.2

2.0.13.2

AXSM-16-155

axsm_002.000.012.000_bt.fw

2.0.12.0

axsm_002.000.013.002.fw

2.0.13.2

2.0.13.2

AXSM-4-622

axsm_002.000.012.000_bt.fw

2.0.12.0

axsm_002.000.013.002.fw

2.0.13.2

2.0.13.2

AXSM-16-T3/E3

axsm_002.000.012.000_bt.fw

2.0.12.0

axsm_002.000.013.002.fw

2.0.13.2

2.0.13.2

MGX 2.0.13 interoperates with CWM 10.4

MGX 2.0.13 operates with MGX 1.1.31 and MGX 1.1.32 as a feeder. Please see 1.1.311/1.1.32 release notes for bugs related to the feeder features.

MGX 2.0.13 operates with CiscoView 5.2 (package 3.3x).

Release 2.0.13 System Content

Switch Software and Boot Codes

The following four images apply to the 2.0.13 release:

•Boot Images

–axsm_002.000.012.000_bt.fw

–pxm45_002.000.013.000_bt.fw

•Runtime Images

–axsm_002.000.013.0002.fw

–pxm45_002.000.013.002_mgx.fw

Additional Deliverables for Release 2.0.13

SNMP MIB

The MIB release for this 2.0.13 is mibs2012.

Upgrading to a New Software Release

This section contains installation and upgrade instructions. For complete details, refer to the MGX 8850 Switch Software Configuration Guide, part 78-12629-01, which supports installation of software version 2.0.12 and higher.

Upgrade Procedure

When upgrading your node, upgrade the software in the following order:

Step 1 PXM45 backup boot

Step 2 PXM45 runtime

Step 3 AXSM backup boot—only needed if upgrading from a release earlier than 2.0.12

Step 4 AXSM runtime

The following does not apply if you are upgrading from version 2.0.12:

•If the active AXSM has some non-default interface policy configured with the cnfpnportcac command, then the standby AXSM card might not be in sync with the active card. This affects the upgrade of the cards to the new version. The user will have to follow the procedure for a non-graceful upgrade to the new version.

If the default interface policy is being used, graceful upgrades are supported.

Graceful upgrades are also possible if the interface policy is configured for 3 or fewer ports, because the interface policy for 4 or more ports do not get synced to standby.

Note The PXM-45 upgrade is still graceful; only the AXSM redundancy will be ungraceful if there have been interface policy changes.

•If you are currently using 3 IP addresses to telnet to your node, read the first section in "Changed CLI Commands" on reconfiguring your IP addresses on your node. The Disk IP address must be configured.

Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Redundant Systems)

The following procedure is for redundant systems.

Step 1 Copy files to the switch.

Step 2 Type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command.

Step 4 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().

Step 5 Issue the sysFlashBootBurn <"filename"> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
- enter "y" to confirm
Step 6 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the Active state.

Step 7 Enter the switchcc command. When the former active card comes up standby, upgrade its boot code by following steps 2 - 6 above.

Step 8 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)

Step 9 After the standby card comes back up with the new image in the Active state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)

Step 10 After the redundant card comes up in the standby/Active state, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)

Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev, runrev and commitrev command for each AXSM card.

For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2) 
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.

Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <version>
For example: loadrev <AXSM slot> 2.0(13.2)

Step 13 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <version>
For example: runrev <AXSM slot> 2.0(13.2)

Step 14 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)

Repeat steps 12-14 for all redundant AXSM cards.

Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Non-Redundant Systems)

The following procedure is for non-redundant (PXM-45) systems.

Step 1 Upgrade the PXM-45 boot code.

Step 2 Type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command.

Step 4 Hit return when prompted to do so to stop auto-boot.

Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
enter "y" to confirm
Step 6 Use the loadrev, runrev, and commitrev commands to load the 2.0.13 release:
loadrev 7 2.0(13.2) 
runrev 7 2.0(13.2)
commitrev 7 2.0(13.2)
Step 7 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev command for each AXSM card. For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2) 
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.

Step 8 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <AXSM slot> 2.0(13.2)

Step 9 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <primary version>
For example: runrev <AXSM slot> 2.0(13.2)

Step 10 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)

Repeat steps 9-10 for all redundant AXSM cards.

Upgrading the Boot and Runtime Images from 2.0.11 to 2.0.13 (with No Interface Policy Changes) [Redundant Systems]

The following procedure is for redundant systems.

Step 1 Type sh to go to the shellconn.

Step 2 Issue the sysBackupBoot command.

Step 3 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().

Step 4 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
- enter "y" to confirm
Step 5 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the ready state.

Step 6 Enter the switchcc command. When the formerly active card comes up standby, upgrade its boot code by following steps 1-5 above.

Step 7 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)

Step 8 After the standby card comes back up with the new image in the ready state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to Active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)

Step 9 After the redundant card comes up in standby ready, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)

Step 10 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev, runrev and commitrev command for each AXSM card.

For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2) 
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.

Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <version>
For example: loadrev <AXSM slot> 2.0(13.2)

Step 13 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <version>
For example: runrev <AXSM slot> 2.0(13.2)

Step 14 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)

Repeat steps 12-14 for all redundant AXSM cards.

Upgrade Procedure for Non-Redundant (PXM-45) Systems

The following procedure is for non-redundant (PXM-45) systems.

Step 1 Upgrade the PXM-45 boot code.

Step 2 Type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command.

Step 4 Hit return when prompted to do so to stop auto-boot.

Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
- enter "y" to confirm
Step 6 Use the loadrev, runrev, and commitrev commands to load the 2.0.13 release:
loadrev 7 2.0(13.2) 
runrev 7 2.0(13.2)
commitrev 7 2.0(13.2)
Step 7 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 8 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev command for each AXSM card.

For example:
loadrev <AXSM slot> 2.0(13.2)
runrev <AXSM slot> 2.0(13.2) 
commitrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant AXSM cards.

Step 9 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <AXSM slot> 2.0(13.2)

Step 10 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card.
runrev <slot number> <primary version>
For example: runrev <AXSM slot> 2.0(13.2)

Step 11 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <AXSM slot> 2.0(13.2)

Repeat steps 10-11 for all redundant AXSM cards.

Upgrading theBoot and Runtime Images from 2.0.11 to 2.0.13 (with Interface Policy Changes)

The following procedure is for redundant systems.

Step 1 Type sh to go to the shellconn.

Step 2 Issue the sysBackupBoot command.

Step 3 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().

Step 4 Issue the sysFlashBootBurn <filename> command, where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
- enter "y" to confirm
Step 5 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the ready state.

Step 6 Enter the switchcc command. When the formerly active card comes up standby, upgrade its boot code by following steps 1-5 above.

Step 7 Use the loadrev command to load the 2.0.13 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(13.2)

Step 8 After the standby card comes back up with the new image in the ready state, use the runrev command to load the 2.0.13 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(13.2)

Step 9 After the redundant card comes up in standby ready, issue the command commitrev to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(13.2)

Step 10 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 11 To upgrade non-redundant/redundant AXSM cards with the new runtime image, issue the setrev command for each AXSM card. For example:
setrev <AXSM slot> 2.0(13.2)
Repeat these steps for all non-redundant/redundant AXSM cards.

The following procedure is for non-redundant systems.

Step 1 Upgrade the PXM-45 boot code.

Step 2 Type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command.

Step 4 Hit return when prompted to do so to stop auto-boot.

Step 5 Issue the sysFlashBootBurn <filename> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.013.000_bt.fw"
- enter "y" to confirm
Step 6 Use the setrev command to load the 2.0.13 release:
setrev 7 2.0(13.2) 
Step 7 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(12)
Step 8 To upgrade the AXSM runtime, issue the setrev command for the AXSM card.
setrev <AXSM slot> 2.0(13.2)
New and Changed Information

This section describes new and changed commands in release 2.0.13.

New CLI Commands

The new command dspapsbkplane displays the APS connector status. For example:
U3.6.AXSM.a > dspapsbkplane 6.1.3 
BackPlane: ENGAGED 
 
Golden.3.AXSM.a > dspapsbkplane 3.1.1 
BackPlane: NOT ENGAGED
Changed CLI Commands

No CLI commands are changed in this release.

New Features in Release 2.0.13

There are no new features in this release.

The following features are committed, but not supported in this release:

•AXSM cards with STM1 electrical interface.

•Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).

•Connection density: 50K connections per node. 40K connections are supported in this release.

Obsoleted Features in Release 2.0.13:

No features are obsoleted in this release.

Installation Notes and Cautions

•(CSCdt05425) If the active AXSM has some non-default interface policy configured, then standby card might not be in sync with the active card. This will also affect the upgrade of the cards to the new version. The user will have to follow the procedure for a non-graceful upgrade for the new version.

If the default interface policy is being used, then the redundancy/graceful upgrade is possible.

The redundancy/upgrade will also work if the interface policy is configured for 3 or fewer ports (as the interface policy for 4 or more ports does not get synced to standby).

Note that AXSM Redundancy works after the customer has upgraded to 2.0.12. The AXSM Redundancy problem only exists in versions 2.010 and 2.0.11.

•When removing AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.

•On feeder trunks, confoamseg is required for tstdelay to work. The steps are as follows on PNNI:

Step 1 dpnport <portid>

Step 2 cnfpnportsig <portid> -cntlvc ip

Step 3 cnfoamsegep <portid> no

Step 4 uppnport <portid>

•(CSCdt09608) To prevent database sync problems on CWM, when setting these MIB variables or using corresponding CLI command addcon, the user should always follow these rules:

–from SNMP, cwaChanCDV and cwaChanRemoteCDV should always be set to the same value.

–from SNMP, cwaChanCTD and cwaChanRemoteCTD should always be set to the same value.

–from CLI, the parameters 'lcdv' and 'rcdv' of the addcon command should always be set to the same value.

–from CLI, the parameters 'lctd' and 'rctd' of the addcon command should always be set to the same value.

–do not set above variables on a slave endpoint either from CLI or SNMP.

•(CSCdt09949) Currently the CLI command addchanloop does not store the connection loop state as persistent data. As a result, this loop (ingress and egress) state of a connection will be lost after the following operations:

–resetcd

–resetsys

–dncon followed by upcon

–controller resync (dnport followed by upport)

–switchredcd

–reroute (dnport)

•PNNI default min VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (e.g., MPLS and NCDP). For users who would like to add MPLS controller in future releases of MGX 8850, it is highly recommend to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be established automatically on 0/32.

•By default, 900 cps and 543 cps will be reserved for SSCOP and PNNI Signalling VC respectively, even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.

•The database stores the backplane serial number and back card serial numbers. Therefore if cards are moved from one node to another, the console will display "SHM Alert!! Alert!!." In this situation follow these steps:

Step 1 Enter shmFailDisplay. A display table will show that BRAM is not native.

Step 2 Enter shmFailRecoveryHelp. This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is shmRecoverIgRblDisk.

Step 3 Enter shmRecoverIgRbldDisk.

•Do not execute delcontroller when connections/ports still exists. The impact of executing delcontroller with connections is that the connections cannot be recovered until the controller is re-added via addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in provisioning state). There is now a warning about the impact of the command when there are existing connections/ports.

•(CSCds70478) Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.

•Analysis of the code has identified a situation which has a low probability of occurring and in fact has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, thus minimal bandwidth is available for new SPVC connections, there is a condition which can be encountered where, the initial software check believes there is sufficient bandwidth for the new SPVC connection; however, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.

•To replace one type of AXSM front card with another type, all connections, partitions, ports and down lines must be deleted. In case of AXSM card failure, the same type of AXSM card must be installed in that slot.

•(CSCds11868) If a user is using CWM with their node, the user should use CWM to configure the node name since the restriction on the switch is different than CWM. CWM only supports 11 characters whereas the switch CLI command allows up to 32 characters.

•(CSCdt32198) The dsperr command currently provides proper information only when it is executed on PXM slot. When it is executed on the AXSM slot, the information is incorrect.

Limitations and Restrictions

•If any AXSM cards remain in INIT state and the PXM-45 standby card is reset, the PXM-45 standby card will not transit back to standby. This is a DB server limitation.

•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in Rel 2.0 baseline (2.0.10-2.0.13) with PXM-45 and PXM-45/B is 99.

In future releases of MGX 8850 with PXM-45/B, the maximum number of logical interfaces supported will be 3199. The PXM-45 module will always support a maximum of 99 logical interfaces.

The maximum number of signalling interfaces in Rel 2.0 and future releases of MGX 8850 is 99. Signalling interfaces are those running a protocol such as PNNI, IISP, AINI or supporting SVC/SVP.

Interfaces on standby or redundant cards are not counted.

•(CSCdt32565) APS working line must be 1 line lower than the protection line. For example, 1 is the working link and 2 is the protection line. Having 1 as the protection and 2 as the working line is not allowed.

•If the destination address is reachable for both a IISP and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Since IISP does not support ABR connections, the connection setup will fail.

•SCT can be changed with connections present in this release. However, if service affecting the connections will be rerouted.

•(CSCds41609) Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.

•When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX 8850 PXM-45 as lnPci address.

•For users who would like to add MPLS partition on a port where other partitions have already been added and have set the min-vci value to be 32, then the user has two options:

–After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.

–Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.

•(CSCdr15911) Changing or reseeding the back card several times on the AXSM OC48 card may sometimes cause the front card to reset and cause loss of service. The PhyTask also gets suspended. To avoid this problem, try not to reseat the back card too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring up the system.

Important Notes

APS Status Information

Caution Please ensure the APS connector is correctly installed. Refer to the "APS Backplane" section in Chapter 4 of the "Cisco MGX 8850 Hardware Installation Guide". This guide is part number 78-10351-04, and can be ordered from Cisco Marketplace or downloaded from http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/20x/hig/index.htm. After you install the assembly, verify that the APS connector is properly installed by using the new CLI command dspapsbkplane.

The current APS design has the APS mux (through the mini-backplane) between the framer and the line. Hence, the processor monitors status of the line after the APS mux. As a result, it also reports and displays the APS status of the line that feeds to it. The following CLIs as well as line LEDs are affected:

•dsplns

•dspapsalms

•dspapslns

•dspbercnt

•LEDs

The lines could be mapped "straight" (the line of Back Card X, fed to Front Card X and the line of Back Card Y fed to Front Card Y) or "crossed" (the line of Back Card X fed to Front Card Y and the line of Back Card Y fed to Front Card X). Typically, when one does say dspapslns on Card X, one expects Front Card X to show the status of the Lines of Back Card X. However, in the current design one must note that this is true only the "straight" situation. In the "crossed" situation, dspapslns on Card X will show the status of the lines fed to it, that is, of the Peer Card Y. As long as one is aware of how to interpret the above CLI commands and LEDs in this situatio, everything should be clear.

So how does one determine if the configuration is "straight" or "crossed"?

In card redundancy, initially the Primary card is Active and the Secondary card is Standby, the Working line is from the Primary card and the Protection line is from the Secondary card and the Active Line is the Working Line. If the Primary card is Active and the Active Line is Protection or if the Secondary card is Active and the Active line is Working we are in a "crossed" situation; otherwise we are in a "straight" situation.The dspapslns command shows which line is Active.

Recommendations

We recommend you apply the default values for PCR, SCR, etc. to the Control VC. If the values are decreased to a low value, there is a chance that the Control VC (SSCOP or PNNI) will not come up. Note that you must use the SCT files released with 2.0.11 (number 2 and 3, which are included in the 2.0.13 release) for the Control VC feature.

Caveats

Known Anomolies in Release 2.0.13

The following is the list of known anomalies in this MGX 8850 software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.

Bug ID

Description

S1 Bugs

CSCdr15911

Symptom:

Changing the back card may sometimes cause the front card to reset and cause loss of service. It may occasionally be difficult to bring up the AXSM card.

Conditions:

This problem happens occasionally when someone reseats the back card several times, the front card is reset.

It is also observed that during power on/off testing, sometime the PhyTask got suspended.

Workaround:

Try not to reseat the back card too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.

CSCds86986

Symptoms:

AXSM switchover cause all pnni links on this AXSM go to attempt.

Condition:

This problem occurred after resetting an AXSM non-redundant card and followed by several (some times up to 10) consecutive AXSM switchovers on redundant AXSM pairs on other slots of the same node.

Work around:

Do not do consecutive AXSM switchovers. If the problem occurs, the periodic resync between PNNI controller and AXSM will recover the failure.

CSCdt11867

Symptom:

Ports go to ilmi query after PXM switch over

Condition:

Upgrades the network, then do switchcc

Work around:

None

Recovery:

Down port then up port by using dnpnport/uppnport command

CSCdt12043

Symptom :

After multiple switchcc failed to telnet to a node.

Condition :

Disk IP address not configured for LAN (lnPci0). During switchover, no ARP broadcast sent to declare new IP address <--> MAC address mapping.

Workaround:

Make sure the Disk IP address (lnPci0) of this node is configured.

CSCdt27029

Symptom:

AXSM switchover and PXM switchover when AXSM cards inserted

Condition:

AXSM cards were reseated

Workaround:

UNKNOWN

CSCdt28974

Symptom:

Manual switch from active protection line to working line does not follow aps protocol.

Condition:

Protection line was active.

Workaround:

UNKNOWN

CSCdt28983

Symptom:

aps switching does not meet Signal Degrade Threshold requirements for switching

Condition:

Errors were injected at the threshold levels specified for Signal Degrade conditions to be reported.

Workaround:

UNKNOWN

CSCdt29648

Symptom:

BPX reported no ingress data from MGX

Condition:

aps switch had been performed on BPX

Workaround:

UNKNOWN

CSCdt29711

Symptom:

Adding and deleting APS line on a NNI port caused it to go to building VC state. Condition:

The port is stuck in building VC state and the signalling type is changed from NNi to UNI.

Workaround:

Unknown

CSCdt32565

Symptom:

Failed to add redundancy between AXSM cards. Further summary. This occured during software upgrade to 2.0(13). This only causes a failure for an Intracard APS case.

Condition:

If we have APS line configured with protection line greater than working line we get into this problem.

In the original APS software, the CLI command, "addapsln", did not have any check to prevent adding APS line where the protection line is less than the working line. This will go through even though it is not acceptable. The APS database will not accept this. However, the process called "CEMA" allows it.

Therefore, Intercard APS was not working in the previous release. The bug ID CSCdt08530, that resolved most of the APS problem correct this mistake as well.

However, by fixing what was wrong in the first place, it caused the configurations in the system to be unable to be recognized.

Workaround:

The only solution is that prior to upgrading the runtime image to 2.0(13), the administrator needs to verify that on a stand alone card, there are no Intracard APS configured such that the working line is greater than the protection line.

If there is, then the Intracard APS has to be deleted, along with its ports, partitions and connections. If they prefer to leave the connections, they will have to use another line for APS configuration later on.

Once the Intracard APS is deleted, they can then upgrade the runtime image and then add APS later on. Or they could add it correctly in the old image prior to upgrading to the new image 2.0(13).

If an upgrade is already done prior to deleting the Intracard APS, this would definitely cause the AXSM card to not function properly. Therefore, to fix this problem, they need to downgrade back to the previous image and delete the Intracard APS with the protection line less than the working line. Once that is accomplished, then they could do the upgrade.

S2 BUGS

CSCdr89521

Symptom:

dspcon shows routing cost = 0

Condition:

This will happen after swithcc on connections that are not rerouted

Workaround:

Do a dncon or rrtcon

CSCds24362

Symptoms:

Occasionally, when downing a UNI port (dnport) on AXSM followed by upport, some VSIErr are displayed on the AXSM console.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A connection is established from NODE_EP1 to NODE_EP2.

(3) dnport on the UNI on NODE_EP1.

(4) upport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.

Workaround:

None.

CSCds74175

Symptom:

When bit error are injected on a protection line and if the protection line were to be active (in case of intra card APS), "dspbecnt" would show those errors on the working line stats instead of the protection line stats.

Condition:

This happens only for an intra-card APS case. The problem is still under investigation.

Workaround:

If the working line is active, then the display shown on dspbecnt is correct. If the protection line is active, then use the stats shown on the working line as the protection line bit error stats and vice versa.

CSCds74268

Symptom:

Active AXSM card in a redundant pair spontaneously resets

Condition:

Previous to the reset, a spontaneous switchover from the previously active AXSM card had taken place. The previously active AXSM card did not come into standby mode after the switchover, but stayed in boot state.

Workaround:

UNKNOWN

CSCds74316

Symptoms

The dsplog command displays 0.0.0 for protection line id when the APS pair is deleted.

Conditions

Not all of the APS events show proper protection line index. Some are printed with 0.0.0 as index.

Workaround:

None

CSCds89730

Symptom:

Upon trap verification, cwCardIngSctFileAlarm (60358) does not provide correct value for cmIngressFileId varbind.

Conditions:

User generated trap by configuring the card SCT with an invalid/missing ID using the command (cnfcdsct 56, where 56 is the invalid SCT ID) User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.

Workaround:

UNKNOWN

CSCds89759

Symptom:

Upon trap verification, cwaChanMultipleChanInAlarms (60306) appears to be generated too many times with respect to CLI actions.

Conditions:

User was downing ports and associated multiple channels from CLI. dnport <port #> User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.

Workaround:

UNKNOWN

CSCds89819

Symptom:

Customer reports excessive and varied traffic restore time with redundant AXSM card resets.

Condition:

Excessive and varied traffic restore is observed when a redundant APS connected nni link experiences card switchovers. Traffic restore over the link is ranging from 25 Milliseconds all the way up to one (1) second.

Workaround:

None

CSCds90463

CSCds90463

Symptom:

EM database consistency error during AXSM resync

Condition:

This problem is found in MGX 8850 shelf, after runrev on redundant AXSM card, standby AXSM card try to come up and sync the database with the active AXSM card.

Workaround:

unknown

CSCds92690

Symptom:

Slave conns were in E-Ais/RDI for no apparent reason.

Condition:

aps miniplane connectors and back cards were installed prior to connections going into alarm

Workaround:

UNKNOWN

CSCdt02295

Symptoms:

The J0/Z0 bytes are incorrect when the mode is SONET.

Condition:

None

Work around:

None.

CSCdt02323

Symptoms:

The J0/Z0 bytes in the recd. SONET frame are not correct.

Condition:

None

Workaround:

None.

CSCdt05371

Symptom:

Traps were not generated for HD failure during fault insertion testing.

Condition:

Hard disk failure was simulated on modified PXMs.

Workaround:

UNKNOWN

CSCdt05378

Symptom:

Switchover to faulty standby PXM allowed during fault insertion testing

Condition:

HD failure was simulated on the standby PXM

Workaround:

UNKNOWN

CSCdt05383

Symptom:

PXM switchover did not occur when HD failure simulated on active PXM during fault insertion testing

Condition:

HD failure was simulated on active PXM

Workaround:

UNKNOWN

CSCdt05385

Symptom:

No alarms reported when HD failure on active PXM

Condition:

HD failure was simulated on active PXM

Workaround:

UNKNOWN

CSCdt05387

Symptom:

Hexadecimal characters appeared on telnet session and access to system via telnet and console port access was then lost

Condition:

HD failure was simulated on active PXM

Workaround:

UNKNOWN

CSCdt05429

Symptom:

Node alarms reported on 2.0.10.2 and 2.0.11.3 nodes with switching alarms being the source

Condition:

Xbarerrcnts observed on one node, none observed on the other node.

Workaround:

UNKNOWN

CSCdt06424

Symptom:

OC12 AXSM card does not implement REI-L (M1) byte for generation of near-end error counts to far-end system.

Condition:

None

Workaround:

No workaround.

CSCdt06427

Symptom:

OC12 AXSM card does not declare receiving incoming RDI-P alarm.

Condition:

When OC12 line is receiving RDI-P.

Workaround:

No workaround.

CSCdt07085

Symptom:

SPVCs stayed in conditioning state

Condition:

The node terminating the master end of one of the two failed spvcs was rebuilt

Workaround:

UNKNOWN

CSCdt07366

Symptom:

The pnport on the local side goes to vc building state and sscop is in unknown state. The remote node shows that pnport is up and the pnni-link is in attempt state.

Condition:

The pnport which has Y-red configured goes to building vc state. The sscop is in the unknown state on the local side. The condition occurred with switchcc after the Y-red is deleted.

Workaround:

Bringing the pnport down (dnpnport) and up (uppnport) the pnport come out from the vc building state.

CSCdt07644

Symptom:

Clock alarms for primary clock remain persistent

Condition:

Both primary and secondary clock sources (external bits clocks) were failed. Secondary and then primary clock sources were restored in that order Node continued to show clock alarm for the primary clock, even though the clock status was ok.

Workaround:

UNKNOWN

CSCdt07691

Symptom:

Severe clocking events are shown as info type of events

Condition:

Configuring clock sources and failing the clock sources

Workaround:

None

CSCdt07730

Symptom:

dspclkalms command shows the wrong clock source to be in alarm - secondary instead of primary

Condition:

External bits inputs are used for both primary and secondary Secondary clock source is failed first, then primary clock source. Secondary clock source is then restored. A minor clock alarm is reported for the secondary clock source instead of the primary.

Workaround:

UNKNOWN

CSCdt07739

CSCdt07739

Symptom:

Loss of activity messages are reported by the standby PXM in the event log for a newly active clock source

Condition:

External bits inputs are used for both primary and secondary clock sources Clock switchover is initiated.

Workaround:

UNKNOWN

CSCdt07753

Symptom:

Traps not sent to CWM when primary clock source is restored.

Condition:

Both primary and secondary clock sources are configured to be external bits inputs. Primary is failed, resulting in secondary becoming active. Primary is then restored.

Workaround:

UNKNOWN

CSCdt08059

Symptom:

Telnet daemon allowed user access into switch without authentication

Condition:

Node was reset by resetting both active and standby PXMs, or by power cycle

Workaround:

UNKNOWN

CSCdt09931

Symptom:

After switchcc, newly active PXM goes onto internal oscillator.

Condition:

External bits input is used for both primary and secondary clock sources

Workaround:

UNKNOWN

CSCdt09949

Symptom:

Channel loops are randomly being knocked down.

Condition:

UNKNOWN

Workaround:

UNKNOWN

CSCdt10244

Symptom:

If switchred the AXSM pair is done on OC48 APS lines that has the protection line active, channel mismatch problem is generated. If users switchred the AXSM pair back to the original setting after that, there will be signal low problem on the protection line although lines are ok. Users are forced to delete and add the aps line back to clear the problem.

Condition:

1) Both near end and remote end has OC48 1+1 APS lines enabled with bi-dir and revert set to yes

2) Switchapsln on one end.

3) Switchred on the AXSM pair on one side. Channel mismatch will occur here.

4) If switchred back to the original setting, there will be signalfaillow on the aps line although the lines are ok. Users are forced to delete the aps and add the pair back in.

Workaround:

None.

To recover, delete the aps and add them back in.

CSCdt10970

Symptom:

dspapsln shows the wrong line in alarm.dsplns shows the wrong alarm. LEDs light up incorrectly when a APS line is in alarm.

Condition:

Intercard APS configured and operational, may be card switchovers, APS switchover or line alarms have occurred.

Workaround:

Use the CLI command dspapsln and shell command ATGetState <slot>,<0-based bay>, <0-based port> to figure out which line is in Alarm. Ignore dspapslns output as far as line alarms are concerned.

dsplns/dspln shows MAJOR alarm if either Working or Protection Line is in Alarm. If Line X is connected to Framer in slot Y, the alarm condition on Line X will shows up as a Red LED in port X of front card in slot Y. If the framers are not crossed, they will be connected to the lines of the back cards in the same slot; if they are crossed, they will be connected to the lines of the back cards in the peer slot.

CSCdt11967

Symptom:

Link go to attempt after pxm switchover

Condition:

Multiple switch over cause link go to attempt

Workaround:

Waiting for resync to happen

CSCdt12440

Symptom:

Both AXSM cards reset after runrev or switchredcd

Condition:

UNKNOWN

Workaround:

UNKNOWN

CSCdt12816

Symptoms:

Adtech conformance tests for sscop give an inconclusive result

Condition:

The Adtech does not expect a response to BGREJ pdu in idle state

Workaround:

Unknown

CSCdt13022

Symptom:

Interface go down after deleting AXSM redundancy

Condition:

Delete AXSM T3/E3 redundancy

Workaround:

Remove standby AXSM Y-cable before delete AXSM redundancy

CSCdt13133

Symptom:

Device driver core dumps recorded on PXM

Condition:

Nodes had experienced power outages the previous day, and had to have their PXMs reseated as part of the recovery process

Workaround:

UNKNOWN

CSCdt14012

Symptom:

pnport shows its ILMI state to be undefined

Condition:

This happened on a node that was experiencing spontaneous AXSM resets

Workaround:

UNKNOWN

CSCdt14045

Symptom:

After AXSM card reset, data transfer stopped and LCNs could not be accessed via tstdelay/dspvsicons commands

Condition:

Spontaneous AXSM card reset

Workaround:

UNKNOWN

CSCdt14120

Symptom:

PNNI ports on both nodes on either end of a PNNI trunk are stuck in auto-config mode

Condition:

UNKNOWN

Workaround:

UNKNOWN

CSCdt14687

Symptom:

addlnloop command is not allowed on AXSM lines that have aps enabled

Condition:

aps is enabled

Workaround:

UNKNOWN

CSCdt14860

Symptom:

dsplog shows some event log are getting dropped

Condition:

This occurs when the same event is generated multiple times in a short period of time. The default interval is1 tick = 1/100 second

Workaround:

None

CSCdt15030

Symptom:

PNNI trunk status is sometimes reported incorrectly via SNMP trap.

Condition:

Even though the PNNI port is UpAndNormal via CLI dsppnport command, the SNMP trap 70008 was reported otherwise.This problem occurs only on this particular node. The root cause is being investigate.

Workaround:

None. Use CLI to check the trunk status.

CSCdt19797

Symptom:

After setrev to downgrade from 2.1.x to 2.0.x we see checksum mismatches between the PXM and AXSM.

Condition: With node running 2.1.x used setrev to fall back to 2.0.(11.3) and then used setrev to upgrade to 2.0(12.0).This is not service affecting.

Workaround:

None

CSCdt19813

Symptom:

Software error reset core dumps observed on PXM

Condition:

Cyclic switchccs and fault insertion tests were being performed

Workaround:

UNKNOWN

CSCdt19936

Symptom:

Port stuck in building vc

Condition:

Power off/on or reset node

Work around:

Issue dnpnport portID then uppnport portID command

CSCdt19949

Symptom:

Switchapsln from Protection to Working is blocked.

Condition:

Last User Request was a Working to Protection switch.

Workaround:

UNKNOWN

CSCdt21047

Symptom:

Event logging for aps needs to be improved

Condition:

aps activity

Workaround:

UNKNOWN

CSCdt21157

Symptom:

SPVC did not connect even when crankback occurred

Condition:

Crankback occurred after a connect was issued by the destination node, and a VPI mismatch condition was detected by the originating node.

Workaround:

UNKNOWN

CSCdt26085

Symptom:

Working and Protection lines on the MGX stay in persistent alarm condition

Condition:

aps configuration was deleted on bpx side, switchyred was performed, and then aps configuration was reinstated.

Workaround:

UNKNOWN

CSCdt26481

Symptom:

dspbecnt command stopped working

Condition:

aps line switchover was caused by error injection

Workaround:

UNKNOWN

CSCdt27655

Symptom:

The Cumulative RM fixed round trip time parameter (octet 9) is not included in the ABR setup parameter.

Condition:

When initiating an SPVC ABR call, the cumulative RM FRTT octet is not included in the ABR setup parameter.

Workaround:

None.

S3 BUGS

CSCdp55031

Symptom:

When "clrpncon" command is used to clear a SVC connection, The release cause is sent as #31 (normal unspecified) instead of #16 (call clearing)

Condition:

clrpncon command executed on a port, vpi, vci or for all svc connections on that port.

Workaround:

None.

CSCds17719

Symptom:

No access to node via LAN

Conditions:

LAN port has hardware failure. Driver does not detect and request processor switchover.

Workaround:

None. Could use IP Connectivity interface for management as the primary. If not, a manual switchover or rebuild is required.

CSCds17859

Symptom:

CLI can be held up for up to 10 to 15 seconds when CWM FTPs files from the node.

Conditions:

When CWM FTPs files from the node.

Workaround:

None.

CSCds27446

Symptoms:

When performing SPVC reroute and switchover the UNI (master side) at the same time, connection delete may fail on the standby. After switchover, if the same connection is recommitted, VSIErr will be observed on the AXSM console.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A connection is established from NODE_EP1 to NODE_EP2.

(3) dnpnport on one of the NNI on NODE_VIA.

(4) switchredcd on the UNI (master side of the connection) on NODE_EP1.

(5) When everything is rerouted, perform a switchredcd on the same UNI. Sometime later, some VsiErr are observed on the AXSM console.

Workaround:

Do not perform switchover while rerouting/derouting connections.

CSCds42201

Symptom:

Standby PXM-45 card is in continuous reset loop, all AXSM cards in the shelf are either in Failed state or in reset loop.

Condition:

Injecting a hardware failure on SRAM component of Active PXM-45 card manually.

Workaround:

None

CSCds42505

Symptom:

No Major alarm is displayed against AXSM card in card alarms when the card is in Failed state.

Condition:

Injecting a hardware failure on SRAM component of Active PXM-45 card manually.

Workaround:

None

CSCds43093

Symptom:

switchcc allowed to be executed when the standby PXM-45 card has a hardware failure.

Condition:

Injecting a hardware failure on SRAM component of Standby PXM-45 card manually.

Workaround:

Do not execute switchcc.

CSCds43124

Symptom:

Standby PXM-45 card hardware failure is not reported correctly.

Condition:

Injecting a hardware failure on SRAM component of Standby PXM-45 card manually.

Workaround:

None

CSCds43165

Symptom:

Active and Standby PXM-45 card hardware failure is not reported in the event log.

Condition:

Injecting a hardware failure on SRAM component of either Active or Standby PXM-45 card manually.

Workaround:

None

CSCds43545

Symptoms:

popup message appear on screen, when trying to do a delcon.

Condition:

Deleting connections via snmp.

WorkAround:

None.

CSCds43554

Symptom:

No error log is seen about the BRAM component failure.

Condition:

Injecting a hardware failure on BRAM component of Active PXM-45 card manually.

Workaround:

None

CSCds43560

Symptom:

PXM-45 card status LED is green, when the card is continuous reset loop.

Condition:

Injecting a hardware failure on BRAM component of Active PXM-45 card manually.

Workaround:

None

CSCds43563

Symptom:

Sometimes, Standby PXM-45 card goes to Failed state.

Condition:

Injecting a hardware failure on SRAM component of Standby PXM-45 card manually.

Workaround:

None

CSCds56802

Symptom:

On the standby some ports show the status as ilmi_query even though the ports are up on the active.

Condition:

Node has 50k SPVCs with active & standby controller and active & standby slaves. An upgrade is initiated with "loadrev" and the standby ends up with the updated image. The problem is intermittent.

WorkAround:

After switchover the ports will be up on the newly active and all connections will Ok.

CSCds57354

Symptom:

CiscoView is not able to display the correct Card descriptions for an AXSM card in Failed State. entPhysicalDescr MIB value returns "End of Table" for the Failed card's Daughter cards.

Condition:

AXSM card in failed state returns End of Table for snmp get on entPhysicalDescr for daughter cards. This defect is noticeable in all versions of CiscoView wancv pkgs.

Workaround:

User has to use CLI to view Card Details.

CSCds58518

Symptom:

No loss of redundancy alarm is shown while the redundant set is in the middle of upgrades

Conditions:

After the loadrev is completed on a redundant pair and the standby card goes to standby state, the redundancy alarm is cleared

Work Around:

None

CSCds67426

Symptoms:

Two PXM-45 nodes with one end has primary and secondary clock configured (first node) another end has clocking sources (second node) have been reseated. The first node is up before the second node. The pxm45 resync clocks will get NAK from AXSM card. This will cause clock configuration status to not be configured.

A4A.7.PXM.a > dspclksrc

Primary clock type: generic

Primary clock source: 6:1.1:1

Primary clock status: not configured

Primary clock reason: no clock signal

Secondary clock type: generic

Secondary clock source: 6:1.2:2

Secondary clock status: not configured

Secondary clock reason: no clock signal

Active clock: internal clock

source switchover mode: non-revertive

Conditions:

Anomaly has only occurred when performing resetsys on two nodes at the same time.

Workaround:

Reconfigure the clocks with cnfclksrc commands.

CSCds72852

Symptom:

The PNNI would find the AXSM "inactive"

Condition:

When a controller is added, then deleted, followed by switchcc and addcontroller on the new PXM.

WorkAround:

Delete the controller and add it again.

CSCds73435

Symptom:

Residual database information causes AXSM card state to be interpreted incorrectly. An AXSM card inserted into this slot with the residual database may not successfully come up.

Condition:

Residual database on the disk can be introduced if the active Pxm card or disk is replaced with an older card or disk that has old data on it.

Workaround:

Before replacing an active PXM front card or disk, make sure that there is a saved configuration for that node. After replacing the active PXM front card or disk, restored the saved configuration.

Or to verify if there are residual data on the disk, after the node comes up, perform a list file command (e.g. ll) on the D:/DB2 directory. For every slot that is reserved, there should be a corresponding subdirectory for that reserved slot (e.g. SL7), if there are extra subdirectories for non-reserved slot, these are residual old databases.

CSCds74746

Symptom:

Some memory leak in 256 byte buffers if ILMI is down.

Condition:

ILMI running on 60 VNNIs, pull out cables pert. to the VNNIs will cause the memory leak.

Workaround:

None.

CSCds76238

Symptom:

A Major Clock Alarm is raised to indicate the fact that the Network Synchronization clock for that node is in the Holdover mode after deleting all configured clock sources for that node.

Condition:

This condition can occur after a user deletes all configured clock sources on the node.

Workaround:

None.

CSCds79327

Symptom:

emVsiRamHwRsrcPart error message on standby AXSM card

Condition:

This problem is found on standby AXSM card, while there are a lots of ilmi session (more than 30) on same AXSM card, do AXSM switchover

Work around:

None

CSCds80479

Symptom:

HMM DEV ERROR STATE messages are reported in the event log for PXMs and for AXSM cards.

Condition:

This node has experienced data discards and card reset on one of the AXSM cards

Workaround:

Not known

CSCds80500

Symptom:

ABR SPVC is not placed into failed state when the master and slave ends of the connection do not have matching PCR values

Condition:

The master end of the ABR SPVC does not have the same values for local and remote PCR as the slave end of the SPVC

Workaround:

UNKNOWN

CSCds82523

Symptom:

Customer sees the following error after adding redundancy of AXSM cards. 07-21921 11/29/2000-20:10:22 IFM-4-ERROR E:07216 pnCcb 0x8056e0b4 PnNet/IFM/ifcProcessIfcFailedTrap:Cannot find 0x10c1801Interface in Func tree

Condition:

The problem comes when deleting certain ports on AXSM card and then adding redundancy AXSM card immediately. The problem also happens when we delpart & delport on AXSM card and immediately remove this AXSM card.

Workaround:

We don't suggest doing delpart & delport on the AXSM card which will be added as the redundancy AXSM to another AXSM card.

CSCds86837

Symptoms:

dsperrs on PXM displays pnCallaudit error entry when burning new boot on the card.

Condition:

The error is logged while burning the new boot on the PXM card.

Workaround:

Unknown

CSCds87534

Symptom:

After "switchcc" an AXSM card enters critical alarm and subsequently the entire node goes into critical alarm.

Condition:

The problem occurs on a fully loaded chassis with a large number of connections (around 18 K conns on the AXSM card)

Workaround:

NONE. The problem disappears after resync is completed (within 1/2 hour in this case).

CSCds89138

Symptom:

Adtech/Telecordia SSCOP test release version 1.1.1, Adtech version 3.01 running under Adtech Test Suite Manager version 3.0 is failing 102 out of 128 test cases configured.

Condition:

Test suites are failing.

Workaround:

CSCds90296

Symptom:

Test Case 1.6.1 of the Adtech PNNI Point-to-Point conformance suite (PICs) is not passing.

Condition:

Customer executed test suite and realized failure of section 1.6.1.

Workaround:

None

CSCds91308

Symptom:

Screen output of dspcd command executed on AXSM card does not break after 24 lines, providing an option to quit or continuing viewing display output of the command

Condition:

dspcd command is executed on AXSM card

Workaround:

UNKNOWN

CSCdt02028

Symptom:

The event log entry is misleading when sscop is disabled.

Condition:

disablesscop command executed on a port.

Workaround:

None.

CSCdt04611

Symptom:

Copychan command used to build 1000 connections at a time appears to be causing the ethernet interface to hang.

Condition:

Ethernet chip appears to freeze. User loses connectivity to the switch.

Workaround:

Possibly a PXM switchover may resolve the ethernet connectivity issue.

CSCdt04649

Symptoms:

Both Pxms in the node failed to come up. The shmFailDisplay() command shows the fail reasons to be: BRAM and Disk are declared as Non-Native.

The log will show the following entry:

07-00016 12/21/2000-10:50:27 SHM_-4-NOVRAM_FAIL ShelfMgr 0x803038b8 SHM ERR: NOVRAM Info Read failed for device: Back Plane, slot: 0

To display the log in the ShellConn prompt, type: sysEventDisplay ""

Conditions:

On a node powerup or node reset scenario, the active Pxm failed to read its NOVRAM.

Workaround:

If both Pxm cards are inserted, remove one of them, and reset the other card, try to see if this card will come up. If not, try the same procedure on the other card. If both attempts failed, try swapping the 2 cards and repeat the above procedure. Also, check to make sure that all front and back cards in the shelf are seated securely.

CSCdt04929

Symptom:

Number of channels allowed on 'copychan' command should be limited to 20 channels. The system does not give error message when more than 20 channels are entered.

Condition:

Currently, copychan command allows user to enter a large number of channels to be copied at one time. This may cause some side effect such as ethernet interface hangs if SNMP trap manager is enabled. Another side effect is that not all channels are saved on the disk.

Workaround:

Do not copy more than 20 channels at a time.

CSCdt05372

Symptom:

Popup messages appeared on cli

Condition:

HD failure was simulated during fault insertion testing

Workaround:

UNKNOWN

CSCdt05432

Symptom:

dspxbaralm and dspxbaralms commands have same functionality.

Condition:

Use of cli

Workaround:

UNKNOWN

CSCdt05434

Symptom:

dspcon command presented an error message on cli

Condition:

It was executed on a standby AXSM card

Workaround:

UNKNOWN

CSCdt05704

Symptom:

Receiving UNEQ-P does not cause generation of RDI-P in AXSM OC3

Condition:

When UNEQ-P is received

Workaround:

No workaround.

CSCdt05732

Symptom:

UNEQ-P alarm is not detected and shown by AXSM card.

Condition:

When UNEQ-P alarm is received.

Workaround:

No workaround.

CSCdt05929

Symptom:

Tstsdelay on MGX 8850 should be blocked for the connection which terminates on a feeder node.

Condition:

tstdelay command on a MGX 8850 node.

Workaround:

No workaround. Make sure that the connection doesn't terminate on a feeder.

CSCdt06379

Symptoms:

When "clralmcnt" command is executed, the Path RDI and Path AIS count do not clear.

Conditions:

When line receives RDI-P or AIS-P.

Workaround:

To find out RDI-P and AIS-P count increment between "dspalmcnt" commands, need to remember the RDI-P and AIS-P count of last dspalmcnt.

CSCdt06410

Symptom:

During LOS condition, LOF, AIS-L and RDI-P are seen with dspalm command.

Condition:

When line encounters LOS.

Workaround:

Ignore all other alarms if LOS is present.

CSCdt06919

Symptom:

dspchancnt reports invalid if/vpi/vci for connection in fail state.

Condition:

Take a connection which is in the fail state and dspchancnt on that.

Workaround:

none

CSCdt07370

Symptom:

Command output of a shellcon command popped up on the telnet session of a user who had not executed the command.

Condition:

display_queue_stats was executed on a separate telnet session

Workaround:

UNKNOWN

CSCdt07611

Symptom:

DOSFAIL messages appear in event log

Condition:

UNKNOWN

Workaround:

UNKNOWN

CSCdt09608

Symptom:

There are a couple of symptoms can be resulted from this ddts: a) Setting MIB variables cwaChanMaxCost, cwaChanCDV, cwaChanCTD, cwaChanRemoteCDV, cwaChanRemoteCTD on a slave endpoint fails. b) CWM sync up will fail because of these set failures.

Condition:

The failure happens when users try to set above MIB variables on a slave endpoint. These variables should only be set on a master endpoint.

Workaround:

When setting these MIB variables or using corresponding CLI command "addcon", the user should always follow these rules: a) from SNMP, cwaChanCDV and cwaChanRemoteCDV should always be set to the same value. b) from SNMP, cwaChanCTD and cwaChanRemoteCTD should always be set to the same value. c) from CLI, the parameters 'lcdv' and 'rcdv' of the 'addcon' command should always be set to the same value. d) from CLI, the parameters 'lctd' and 'rctd' of the 'addcon' command should always be set to the same value. e) do not set above variables on a slave endpoint either from CLI or SNMP.

CSCdt09827

Symptom:

Unnecessary errors (warning) message are displayed. This does not affect the functionality of the feature.

Condition:

When switchapsln from active or protected to clear few times, unnecessary error message are displayed even though the command was executed properly.

Workaround:

None.

CSCdt10623

Symptom:

Core dump occurred on one of the PXM, in a node with 2 PXMs.

Condition;

When user enters 'Core' command on Active PXM to display core dump, Following's the output, indicates the recent core dump on January 3.

Workaround:

None.

CSCdt11521

Symptom:

vsiProcessVxlCommitRsp: no leg, but has Pep error message keep pop up on PXM

Condition:

Reset multiple AXSM cards

Workaround:

It'll stop generate error message after AXSM card comes up

CSCdt13711

Symptom:

Node got reset again after power cycle.

Condition:

After user power cycle the node it got reset again.

Workaround:

None.

CSCdt14160

Symptom:

Today when a connection is deleted from the proxy slave, we do not know how the connection is deleted (resync, or explicit VSI Delete)

Condition:

Timing problem or deleted due to slave resync, or the unbind msg never send to the application by PNNI.

Workaround

If the connection is deleted, but the LCN is still bounded. There is no way to reused this GLCN. The only way to correct this is through PNNI resync.

Problems Fixed in Release 2.0.13

Bug ID

Description

S2 Bugs

CSCdt02690

Symptom:

Start sync, End Sync and APS Line Pair Sync with standby in progress popup messages appear at the cli prompt on a telnet session.

Condition:

When switchredcd command is executed

Workaround:

None

CSCdt09459

Symptom:

Unable to 'cc' to active AXSM card.

Condition:

When user enters 'cc' command to initiate session to an active standby card, the following error occurs:

Err: Unable to contact process in specified slot

It is noticed that there are some minor HW alarm on the Humvee device with this problem occurs. This problem occurs once during testing.

Workaround:

None. AXSM card must be reset in order to recover from this failure.

CSCdt20186

Symptom:

Connection cannot be set up.

Condition:

When a Generic Identifier Transport IE of an invalid length (more than 33 bytes including the IE header) is received, the whole message is discarded. Therefore, connection cannot be set up.

Workaround:

Avoid sending Generic Identifier Transport IE of invalid length.

CSCdt30096

Symptom:

SPVCs were stuck in mismatch condition.

Condition:

Associated pnport was stuck in provisioning state

Workaround:

UNKNOWN

S3 Bugs

CSCds90459

Symptom:

Event log has error messages like the following:

05-00017 12/12/2000-17:20:11 SSI-4-TMRCANCELINV E:05246 APSTask 0x80152bbc

SSI Timeout event not found in ssiTaskTimeoutCancel. TmoFunc=0x8027aee8, key=5.

Condition:

Happens when APS is configured.

Workaround:

None.

CSCdt08530

Symptom:

Attempt to add 1:1 apsline between wrong ports doesn't give cause of failure.

Condition:

Normal

Workaround:

N/A

CSCdt32121

Symptom:

Presence of APS mini-backplane installed in MGX node cannot be found with runtime CLI.

Condition:

Customer cannot find APS mini-backplane by execution of CLI commands. MGX switch must be physically inspected to determine presence of mini-backplane.

Workaround:

This in an enhancement.

Known Anomalies from Previous Releases

The following anomolies were identified in versions 2.0.01, 2.0.02, 2.0.10, 2.0.11, and 2.0.12.

CSCdr15133

Duplicate of CSCdr20887 conDelError when SPVCs are de-routed due to dnpnport*25k*

CSCdr15197

Un-reproducible IPC buffer memory leak during swichcc with 10K spvc &1k svc *BLOCK*

CSCdr19636

Verified in 2.0.02 dspalm and dspln cmds show diff alarm status

CSCdr20887

Un-reproducible AXSM: vsi error - Cant delete VC entry

CSCdr22569

Verified in 2.0.01 80 abr failed to route in parallel link situation (SLT)(BLOCK)

CSCdr35241

Un-reproducible AXSM vsiErr 0x502a: Connection reserve failure *25K*

CSCdr43257

Duplicate of CSCdr26669 ORIONSLT:3000 SPVCs fail to reroute even though resources are available

CSCdr19861

Un-reproducible Vsi Err found after one trunk (OC48) down and cnfilmi on the other

CSCdr26669

Un-reproducible H-link associated with a PNNI port missing from the PTSE db.*25K*

CSCdr28772

Un-reproducible ORIONSLT:Many ilmi ports on other cards go down after reset BXM

CSCdr31492

Un-reproducible SPVCs fail to connect after AXSM (UNI side) reboot while deroute*25K*

CSCdr47777

Junked Sonet layer doesn't recover if either of AXSM/BXM (OC3) is rebooted

CSCdr78943

Junked (001206) Interface Policy CAC defects

CSCdr86343

Junked (000801) Failure reason for intf operation trap is wrong

CSCdr87314

Duplicate of 89804 AXSM1(OC3) w/10K conns got reset after establishing signaling

CSCdr89382

Duplicate of 93447 9512 went down. SSCOP switching bet. reset & establish. after reset sys.

CSCdr89804

Junked(000817) OC12 failed keeps pumping ipc message allocate error streams

CSCdr93317

Closed Multiple tasks hanged on mutex semaphore, block cli and shellconn

CSCdr94471

Closed -- not a problem.

CSCds03683

Un-reproducible dsppnni-node does not show the node name

CSCds06186

Duplicate of CSCds58912 en/dis/enabling of cc on con does not result in alarm.

CSCds14824

Un-reproducible upgrade:setrev on PXMs cause endpoint local nsap addr corruption

CSCds15089

Closed -- not a problem.

CSCds15159

Duplicate of CSCds28333: Crossbar errors are observed after switchcc, which is fixed in 2.0.11

CSCds16742

Duplicate of CSCds27372, which is fixed in 2.0.11

CSCds18690

Duplicate of CSCds23525: SLT-sw:PNNI link stays in attempt state, which is fixed in 2.0.11.

CSCds19282

Un-reproducible Sysbootchange Init Parameters Corrupted

CSCds20287

Un-reproducible CLI gets Hang while switching to the AXSM1 card

CSCds20318

Duplicate of CSCds23518: SLT-sw:AXSMs reset due to sar error, which is fixed in 2.0.11

CSCds20527

Duplicate of CSCds87902 - this is a CWM bug.

CSCds21342

Closed -- not a problem.

CSCds22604

Duplicate of CSCds45453: AXSM: stdby axms card keeps rebooting due to syncRamError -- which is fixed in 2.0.11

CSCds22824

Duplicate of CSCds26981: SSI DIO: Recover from task deleted while accessing a file, which is fixed in 2.0.11

CSCds22862

Un-reproducible cc to AXSM OC48 slot with AXSM-Yred fails & exit user from telnet ss.

CSCds22946

Un-reproducible AXSM-RED: AXSM PXM db mismatch causes reroute fail (AXSM-RED-DF)

CSCds23335

Duplicate of CSCds26981: SSI DIO: Recover from task deleted while accessing a file, fixed in 2.0.11

CSCds23586

Duplicate of CSCds00727: Discrepancy in card state between CLI cmd prompt and dspcds output

CSCds23866

Duplicate of CSCds04573: AXSM-red:OC48 failed after switchcc on PXM,Hello msg miss, fixed in an earlier release.

CSCds24168

Closed -- some of the hardware was missing.

CSCds24320

Un-reproducible axsmred:All VTs go down after swithcc on PXM

CSCds24905

Duplicate of CSCds46551: axsmred:Number of SPVCs do not match between crossing ports.

CSCds28506

Un-reproducible SLT-sw: Tlb load exception at task pnCcb

CSCds30648

Un-reproducible Redundant PXM-45 remained in i-state after node reboot

CSCds31341

Closed - not a problem

CSCds31775

Un-reproducible AXSM1(T3/E3) keeps resetting.

CSCds32464

Closed -- incorrect connections were being used on the modems

CSCds33133

Duplicate of CSCds04573: AXSM-red:OC48 failed after switchcc on PXM,Hello msg

miss, fixed in an earlier release.

CSCds35707

Un-reproducible SLT: Cause RcvCount XmtCount repetitively displayed.

CSCds35713

Un-reproducible DAX conns stayed in conditioning after interface recovered

CSCds38742

Closed - not a problem

CSCds43553

Duplicate of CSCdr74850 no redundancy trap send out when do switchcc of PXM45 card - fixed in 2.0.10.

CSCds43557

Duplicate of CSCds33855 Corruption of event log file

CSCds45450

Un-reproducible PXM-45 fails to go standby

CSCds46455

Un-reproducible Switchcc caused standby PXM and all AXSM to fail.

CSCds46524

Un-reproducible All ports on an AXSM in provisioning state.

CSCds52922

Closed - not a problem.

CSCds54248

Closed - problem with the hardware.

CSCds54390

Un-reproducible axsmred:SPVCs stop rerouting - SAR Tx Errors

CSCds54794

Un-reproducible axsmred:sscop state not stable after adding aps line.

CSCds63689

Un-reproducible Core dump - watchdog timeout reset

CSCds63724

Un-reproducible Upg:upgrade axsm cause one nni port go to building vc.

CSCds63745

Closed - not a problem

CSCds64302

Duplicate of CSCds68882 Upg:axsm switchover cause Tlb load exception on both

redundant cards - fixed in 2.0.11

CSCds65195

Closed - user error.

CSCds66741

Duplicate of CSCds65320 Slots show alarms in dspcd after switchcc - fixed in 2.0.11.

CSCds67334

Closed - not a problem.

CSCds68209

Un-reproducible Upg:PXM crash after burn boot code on single PXM

CSCds71721

Closed - not a problem

CSCds80370

Un-reproducible CBR SPVC discarding 50 % of its data

CSCds80406

Un-reproducible AXSM spontaneously reset during data transfer tests

CSCds84734

Un-reproducible PXMB:standby PXM45b reset several times then comes up after restsys

CSCds87811

Un-reproducible UPG-dt:Loadrev cause error log on the active PXM card.

CSCds92690

Closed - not a problem.

CSCdt07751

Un-reproducible After upgrading the node to Dec 19 image pnports in building VC

CSCdt08067

Closed - Spurious environmental alarms for DC supply reported

CSCdt09263

Duplicate of CSCdt08530 Adding 1:1 APS line between wrong ports does not give proper error - fixed in 2.0.13

CSCdt10300

Closed - not a problem

Problems Fixed in Release 2.0.12

Bug ID

Description

S1 Bugs

CSCds46636

Symptom:

When a large number of connections get into alarm (like AIS) there is flood of activity on the cPro task, which also happens to handle the provisioning activity. When there is a simultaneous provisioning activity going on in the card, the task stalls because of a deadlock over resources. This is a very rare occurrence, but when this happens all conn. related CLI hangs.

Solution:

The provisioning activity is separated from the alarm handling activity using two different tasks.

Workaround:

None

Frequency:

One time occurrence.

CSCds55470

Symptom:

PXM crashes after booting. Normally it is attributed to the telnet daemon task.

Conditions:

LAN boot IP address has not been configured.

Workaround:

From console, stop PXM in image startup at the prompt: Press [Enter] to skip initialization...

Execute following commands:

bootChange (setup inet address for lan) sysCardInit (bring the reset of image up)

Once card is completely up, from cli re-execute bootChange command.

CSCds64523

Symptoms:

After adding a port and a partition on the AXSM card, the pnport status shows "building vc" instead of "up".

Conditions:

(1) On AXSM card, perform addport and addpart.

(2) On PXM, perform dsppnport, and the pnport status for the newly added port shows "building vc" forever because the control vc committing fails on the AXSM card.

Workaround:

None.

CSCds65556

Symptoms:

The controller was out of memory and restarted.

Conditions:

Seems a rare scenario caused probably due to links repeatedly going up and down resulting in deroute plus reroute of 50000 spvcs.

Workaround:

None.

CSCds73043

Symptom:

Task suspends during its sync process.

Condition:

Sending a single buffer to peer under ipcMblk resource constrain might cause an exception since syncRam tries to access the memory which is taken by other task already.

Workaround:

None

CSCds84187

Symptom:

After loadrev standby PXM keeps resetting

Conditions:

1. forced download was ON or standby PXM did not have correct image file

and

2. running an old boot code that does not have a fix for CSCds85557

Workaround:

abortrev to bring up standby to old release. Make sure forced download is OFF

CSCds85557

Symptoms:

Standby card continuously reset.

Condition:

When operator replaces the standby card with a PXM which has some upgrade configuration.

Workaround:

Execute "sysClrallcnf" on standby PXM only.

CSCds90529

Symptom:

SSCOP links go to Release/Reset state causing all the connections to be rerouted/derouted or stay in fail state.

Condition:

SSCOP and PNNI links could be reset or released due to errors while re synchronization is happening. The connections are being removed from the Service Module (AXSM) causing SSCOP and PNNI failures.

Workaround:

Downing the port and upping the port again may resolve this problem.

CSCds92652

Symptom:

Active AXSM card of a redundant AXSM pair got stuck in Init state after abortrev

Condition:

The other AXSM card of the pair failed to come up after a runrev was executed. An abortrev was then executed which caused both cards to get stuck in Init state.

Workaround:

reset both cards by using resetcd. Reset the primary first then reset secondary. If they are still stuck in init state, reset both again but now reset secondary first.

CSCdt04166

Symptom:

AXSM card is restarted due to software exception.

Condition:

The AXSM card with 50 VTs resets due to the exception of the VSI slave task

Workaround:

None (Nothing at this point of time, may be reduce the ILMI links)

CSCdt04834

Symptoms:

Some or all cards in the node failed to come up.

The log shows the following errors:

01-00005 12/21/2000-16:38:42 DB2C-5-DBCLNT_CTCAPI dbClnt 0x8017063c Error 0 on call to ctcCntrLSlotNumGet

01-00006 12/21/2000-16:38:43 TRAP-5-TRAPCL_INVSLOT trapClTask 0x802831b4 Invalid Controller logical slot in "Trap Client Resolve Server Name"

Conditions:

Configuring the Node Name through the SNMP interface causes the Pxm logical slot number to be changed to zero.

Workaround:

Do not use SNMP (e.g. CWM) to configure a node's name. Use the CLI cnfname command instead.

CSCdt05425

Symptom:

A number of conns on an AXSM card went into Mismatch state.

Condition: AXSM pair was upgraded from 2.0.10.2 to 2.0.11.3

Workaround:

None

S2 Bugs

CSCdr50289

Symptom:

XBAR plane available Multicast event buffer got corrupted.

Condition:

When XBAR plane available multicast is generated, which happens after standby inserted.

Workaround:

None.

CSCdr90786

Symptom:

When a Primary Clock Source is intentionally deleted with the 0delclksrc command a clock alarm is reported by the dspndalms and the dspclkalms command that states that the Primary clock source is lost.

Conditions:

This symptom will occur when a Primary clock source is intentionally deleted with the delclksrc command.

If a primary clock source is lost i.e becomes unlockable or has loss if signal; without user intervention then this alarm is reported as expected and that symptom is not an error.

Workaround:

None.

CSCds28502

Symptom:

Given that the maximum number of users is 50 (3 default users + 47 users). If CLI command 'adduser' is used to add a total of 50 users on the active card, only the first 49 users will appear on the standby card. And if switchover or the standby card is being reset at this time, the standby card will fail to transition from INIT to STANDBY; 'ctcShow' shows cliRat is CTC_APP_INIT_DONE while the other applications are CTC_APP_STBY_READY. Furthermore, if FTP to the active card, the 50th or last user on the list will be deleted.

Condition:

Switchover, reset standby card, or FTP. (see above for more details)

Workaround:

Have at most 49 users; delete an user and reset the standby card.

CSCds36438

Symptom:

Standby card does not come up after a restoreallcnf.

Conditions:

The database for the Standby card is corrupted.

Workaround:

Perform sysClrallcnf on the standby card.

Frequency:

One time occurrence.

CSCds41624

Symptom:

After DS3 line was configured to PLCP and local loopback has been added, the line does not come up in clear state.

Condition:

When there is a PLCP failure, it should clear the DSX3NonTcaAlmMap bit so that the above symptom doesn't happen.

Workaround:

None.

CSCds47626

Symptoms:

After running script to create 50K SPVC conns, there are some connections in FAIL state. dspcon on PXM45 show Last Fail Cause to be "no route to destination" on one end and "Cross Commit Failed" on the other end.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) Run script to create 50K connections from NODE_EP1 to NODE_EP2.

(3) Some connections might failed to route.

Workaround:

none.

CSCds53634

Symptom:

When a line on an OC-3 MMF back card of AXSM is down (using dnln) the laser is not turned off. The other end of the line does not declare LOS.

Condition:

This happens on all OC-3 MMF back cards of AXSM. This is a hardware issue and the investigation is in progress to determine the root cause.

Workaround:

None

CSCds54440

Symptoms:

Some connections are not passing traffic.

Conditions:

Multiple service modules are reset one after another

Workaround:

Down and up the affected connections

CSCds54946

Symptom:

VP Connections are slow to route

Condition:

There is no reroute handling of SPVCs & SPVPs. The reroute could have failed at the HALF commit if the connections was not previously deleted at the AXSM, due to last deroute failure. In this case, resources (vpi/vci) are not released. The VPI/VCI will stay in use.

WorkAround:

After sometimes, RESYNC detects the error and connection is cleaned up at the AXSM.

CSCds57511

Symptom:

Active PXM may loose communication with all other cards on the shelf. All the links may go down.

Conditions:

This could happen during high activity on the PXM QE1210 sar, typically during resetsys of the node or resetsys of neighboring nodes.

Workaround:

Switchcc on the active PXM.

CSCds60742

Symptom:

Seen log entries about time of date change for standby PXM periodically.

Conditions:

Normal operation

Workaround:

None.

CSCds61188

Symptom:

After switchover from standby to active, the port rate of Resource Manager database is not the same as displayed by "dspport" or "dspports" command. This can cause Resource Manager to reject command that depends on available port bandwidth while the user think the bandwidth resource is OK from dspport.

Condition:

No noticeable condition. IPC failure has probably happened between Equipment Manager and VSI slave.

Workaround:

Use cnfport to force new min/max rate after previously standby card is active.

CSCds61193

Symptom:

After switchover from standby to active, the newly active AXSM card does not report back card as unreserved to Shelf Manager when the last line of bay is downed (i.e. all lines on the bay is downed). When any line of bay is upped again, AXSM does not report back card as reserved to Shelf Manager. The Shelf Manager thinks the back card is reserved all the time.

Condition:

AXSM switchover occurs when at least one line on a bay is upped.

Workaround:

No workaround. Most likely, this effect is not noticed by user.

CSCds62771

Symptoms:

Connection stays fail after port is down and now is up.

Conditions:

addcon when port is down then up the port within 2 minutes may result in connection stays fail (con in CALL_INITIATED state but not in any queue)

Work Around:

switchcc

CSCds63497

Symptom:

TLB exception on one of the ftp tasks.

Conditions:

Noticed only once - on a heavy loaded system. On the PXM card only.

Workaround:

If redundancy is enabled, conduct a switchover.

On a standalone card, you would need to reset the system.

When the exception happens, one of the 4 ftp tasks on the PXM will no longer be available to process requests.

Frequency:

One time occurrence.

CSCds63635

Symptom:

It takes a long time for some connections to route.

Condition:

When some parallel trunks have an insignificant reduction in bandwidth, so that PNNI does not distribute an updated PTSE. The master node continues to choose these trunks (equal to or greater than 3) and the connection cranks back 3 times, after which the same trunks are chosen again.

After 30 minutes the PTSE update clears this problem.

WorkAround:

None

CSCds64258

Symptom:

tstdelay and tstconseg takes an order of 2ms longer in some connection configurations.

Condition:

This occurs with tstdelay on dax connections. It also occurs with tstconseg that have ports physically looped back to another port on the same card.

Workaround:

None.

CSCds64282

Symptoms:

One end of the dax conn doesn't show alarm, when a down port is executed on the other end.

Conditions:

When a dnport is executed, the other end of DAX connections doesn't go into alarm.

Workaround:

None.

CSCds66595

Symptom:

cnfpasswd command does not sync up the standby card with the new password data. The data syncs on switchover, however if logging into the Stby PXM, the old password is still required.

Condition:

The problem is reproducible and occurs each time that cnfpasswd command is executed.

Workaround:

Until a switchover, the old password must be used to log into the standby PXM.

CSCds68426

Symptom:

Sometimes, after non-graceful upgrade, some DAX SPVP stayed in failed state.

Condition:

Occurs sometimes after a non-graceful upgrade which accompanies a system reboot. Happens for DAX connections.

WorkAround:

None.

Additional Information:

dncon and upcon will recover the connection.

CSCds69511

Symptoms:

SVC Based RCC in MPG networks will not get rerouted if the service class NRT VBR is not available.

Conditions:

If the service class NRT VBR is not available on a node in a different peer group or if the bandwidth in the service category is not enough for SVC Based RCC, the SVC Based RCC will not get routed on another service category.

Workaround:

There is no workaround to this situation except to make sure that NRT VBR is available on all nodes with the required bandwidth

CSCds69515

Symptoms:

The Routing failure cause code sent in the Signaling Release message is always Destination Unreachable.

Conditions:

When Signaling on the source node or entry border node (in case of Multi Peer Group) has a problem in routing a call in the network, the cause code will always be returned as Destination Unreachable even though the cause for the routing failure might be different.

Workaround:

There is no workaround to this situation. The Release will not carry the right cause code.

CSCds69518

Symptoms:

SVC Based RCC cannot be established on ABR service category.

Conditions:

When the service categories NRT VBR, RT VBR and CBR are available, PNNI tries to setup the SVC Based RCC with ABR as Service Class. But ABR call will fail at the source node or next node due to invalid IE contents.

Workaround:

There is no workaround to this situation.

CSCds69984

Symptom:

Memory leakage in ILMI.

Condition:

This problem is seen when there is lot of ILMI activity.

One way is to configure 60 VNNIs. dnallports followed by upallports will reproduce the problem.

Workaround:

None.

CSCds72034

Symptoms:

SPVC conns are in AIS

Conditions:

Pull out and put back the cable on an UNI port

Workaround:

down and up the UNI port using dnpnport and uppnport cmd on PXM

CSCds74162

Symptom:

Unable to create APS lines from CiscoView

Condition:

Condition was caused by an internal error in the code generated by SNMP research. After modifying this portion of the code (see SCM-note), the problem was cleared.

Workaround:

None.

CSCds74195

Symptom:

clrchancnts command does not clear all the counts.

Condition:

Pass traffic so that the counters accumulate some counts and then stop the traffic. Now execute "clrchancnts" followed by dspchancnt. Ideally, the counters should show zero as there is no traffic. But the counters show some values.

Workaround:

Use clrchancnts after dspchancnt. The values will be cleared.

CSCds74267

Symptom:

AXSM card did not come up after reset, log shows "failed to download image... reason SHM_DNLD_RMT_OPEN_FAILED"

Conditions:

Card was reset many times while downloading image.

Workaround:

Switch to standby PXM if available See CSCds72007 and make sure that forced download is not ON.

CSCds74270

Symptom:

When performing Bulk Sync (when standby AXSM card first arrives), some VsiErrs were observed on the Active AXSM card and the standby AXSM card might not have all the connections.

Conditions:

This happens when intraslave connections (between two port) were added on the AXSM card. If one of the port was admin downed followed by inserting/resetting the standby AXSM card.

WorkAround:

Initiate another Bulk Sync (by resetting the standby AXSM card) after the port is upped.

CSCds74565

Symptoms:

PNNI node name displayed in dsppnni-node is not the same as command prompt node name.

Conditions:

When the newly configured node name is a matching prefix of the old stored node name, the new node name was not written to the disk. So the PNNI node name won't show the correct node name.

Workaround:

Clear the old node name by typing a completely different node name and then try the new node name.

CSCds75107

Symptom:

No access to node via ATM interface

Conditions:

Node SVC appears to be setup and running. From routers point of view, the SVC is not established, though.

Workaround:

Reset the SVC on the node. svcifconfig atm0 router <atm-addr> reset

CSCds77137

Symptom:

Connection is not routed with master state as down vsi half and not in any queue and admin is up.

Condition:

dncon, upcon, rrtcon while there are lots of connection in the routing queue

Work around:

do another dncon and upcon

CSCds78209

Symptom:

Adtech tester (or any CPE) sees CRC errors in half the ilmi PDUs in receives.

Condition:

qe48sar chip which does the SAr for ilmi connection, has PCI read problem. It sends multiple copies of same data, one correctly and others with no CRC field set.

Workaround:

This problem doesn't effect the normal working of ilmi, expect we may have problems or end up wasting some amount of bandwidth.

CSCds79085

Symptom:

When a dsppnports CLI command is executed, the interface is in the state "building-vc".

Condition:

Multiple AXSM switchovers led to the problem.

Workaround:

Once the interface is in "building-vc" state, it can be got oper-up by doing a "dnpnport" followed by "uppnport".

CSCds79424

Symptom:

Port stuck in building-vc.

Condition:

A card is pulled out and put back-in.

Workaround:

1. Down the port and up it again, OR, 2. Pull out the card and put it back-in.

CSCds81546

Symptom:

what happens with this problem is that on APS line, we transmit node status but the feeder don't see or response it back.

So feeder status on our side is ADMINSTATUS = UP, OPERATION = DOWN, when you dnlmi and uplmi, the feeder status shows ADMIN=UP, OPER = UP, which is not correct. In addition, the feeder statistics show LMI is constantly transmitting DEGRADE msg.

Condition:

This happens when the OPER=DOWN, and you dnlmi and uplmi. The solution is when you uplmi, currently we assume the feeder is up automatically which is not correct. So we will assume the link is down, and it will discover the feeder through the node status.

Workaround:

Don't dnlmi and uplmi if the Feeder OPER=DOWN on AXSM side.

CSCds81990

Symptom:

Upon trap verification, cwAtmIfSctFileAlarm (60356) does not provide correct value for caviFileId varbind.

Conditions:

User was configuring port i/f and sct from CLI. cnfport -if 22 -sct 99 User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.

Workaround:

UNKNOWN

CSCds82333

Symptom:

Call is released on one node but does not get released on the peer.

Condition:

Caused when lot of status enquiry happens when the nodes are highly congested. This happens very rarely.

Workaround:

clearing the connection manually.

CSCds83535

Symptom:

visErr 0x9002 and 0x9003 timer delete error is display on AXSM

Condition:

PXM switchover might trigger AXSM send trap to controller but using incorrect timer value.

Workaround:

None

CSCds84546

Symptom:

dsppnni-link doesn't take physical port id with subslot 2.

Condition:

Pass node index and physical port id (with subslot 2) to dsppnni-link to display nni link information.

Workaround:

None.

CSCds84573

Symptom:

The GUI (CiscoView) and CLI command have inconsistent behavior for addport operation. The CLI did the IfNum checking within the addport command and echo the error message, but the GUI (CiscoView) just ignore the IfNum range checking.

Solution:

The CLI interface specific range checking for IfNum parameter has been removed. Instead the IfNum range checking common to both CLI and GUI has been added. Now the CLI and GUL share the same IfNum range checking behavior.

Workaround

N/A

CSCds86265

Symptom:

summary display of tasks is awkward to get from CLI

Conditions:

Always

Workaround:

dsptask 1 2

CSCds87073

Symptom:

Memory Block Error messages for an AXSM card appeared in the event log after a switchcc was executed.

Condition:

A switchcc was executed.

Workaround:

UNKNOWN

CSCds87127

Symptom:

No SNMP response or lost traps after switchcc is executed on the

redundant node.

Condition:

When user executed switchcc on a node that has redundant PXM, the standby PXM will become active but any communication with the switch via SNMP will not get any response. Or the standby PXM that become active might dropped the first few traps because it couldn't transition fast enough. The above problems above are very rare.

Workaround:

None

CSCds88236

Symptoms:

The SSCOP reset happens after switch over to standby and connections get derouted.

Conditions:

During any resync failures on control VCs in the active, the standby doesn't know the failure and doesn't unbind on the LCNs. This causes an inconsistency with the VSI proxy and causes SSCOP to go down during switchover.

Workaround:

There is no workaround to this situation.

CSCds89112

Symptom:

SPVC connection failed to come up after power cycle

Condition:

Slave connection has not been released while master still try to reestablish the call

Workaround:

Do PXM switchover using switchcc

CSCds89750

Symptom:

Upon trap verification, cwChanAdd (60301) does not provide correct value for cwaChanVpcFlag varbind.

Conditions:

User was adding a slave connection from CLI with the following command: addcon 3 99 99 cbr1 s User then checked CWM GUI OV Event Browser window for traps and expanded varbinds.

Workaround:

UNKNOWN

CSCds90005

Symptoms:

When SONET line medium is changed using "cnfln -sonet x.x -slt x" command, these error messages appear sometime:

0x82c7394c PhyTask 97 0x80373184 OC3 Board: unsupported timing source value...

Condition:

No special condition. This error occurrence is intermittent.

Workaround:

No workaround.

CSCds90091

Symptom:

Card Number [8]: prompt presented on telnet session.

Condition:

This prompt is presented when user first telnets into node. It is a prompt that allows the user to log into a specific slot.

Workaround:

Hit carriage return to go to the default slot.

CSCds90343

Symptom:

OAM traffic exists for deleted connections on ports.

Condition:

Customer added 240 spvcs via cli and deleted the connections using CWM 10.3 connection manager. OAM traffic was present on the ports that previously had the connections after deletion. Execution of dspcons did not show any connections on cards. Execution dspvsicons did show existence of connections.

Workaround:

None

CSCdt00600

Symptom:

Port go to building vc.

Condition:

This is found in MGX 8850 shelf, single AXSM reset (either runrev or reset cd or pull out/in the AXSM card) will cause port go to building vc.

Work around:

dnpnport / uppnport

CSCdt03684

Symptom:

A pnport was stuck in building VC, preventing SVCs and new SPVCs from getting routed.

Condition: An upport/dnport was executed on an AXSM port to get rid of some phony e-ais/rdi alarms

Workaround:

UNKNOWN

CSCdt04580

Symptom:

Node shows PXM-45B card as mismatch when inserted as Standby card.

Condition:

PXM-45A card is Active and PXM-45B card is inserted as Standby.

Workaround:

None.

CSCdt06911

Symptom:

The pnport both side of the pnni-link goes to attempt state. The sscop on both sides is in established state. On one node the pnport goes to attempt state and link shows no remote node with remote node id 0:0:00.0000__.

The other node pnni-link shows that the remote node is different than the node where this node is connected physically.

There are no alarms etc on any of the pnport, sscop, port of the line of both nodes.

Condition:

The PNNI port goes into attempt when a delred, addred is followed very quickly by a switchcc.

Workaround:

The pnni-link remained in the attempted state forever. Then ppnport was brought down and up again.

Recovery: By disabling the PNNI node using cnfpnni-node disable and re-enabling it the link can be brought up. This is NOT service affecting.

CSCdt07011

Symptom:

addapsln allow user add 1+1 aps when working and protection line are in same AXSM card

Condition:

To add 1+1 apsln on intra card

Workaround:

To avoid this problem, user option 2 instead of 1 while adding aps line

S3 Bugs

CSCdp43597

Symptom:

Confusing trap sent when voltage is above threshold.

Condition:

When DC voltage is above threshold an event is logged that specifies an "Above threshold" alarm. However, a "Below threshold" trap is generated.

Workaround:

None

CSCdr50889

Symptom:

-dsplns command accepts junk as input parameter.

Condition:

dsplns command takes no parameters. Enter junk after dsplns on command prompt. It is accepted. dspports command is working fine.

Workaround:

None

CSCdr52270

Symptom:

When a DAX connection is added among different interface ports and the same AXSM card, dnport and then upport on one end of the SPVC connection will cause connection checksum mismatch alarm instead of conditioned alarm.

Condition:

None

Workaround:

Problem is resolved. If it happens on earlier release, dnport and then upport on both connection endpts will bring it back to normal.

CSCdr69957

Symptom:

Addition of New SPVCs are allowed even when number of configured VCCs exceeded Negotiated maxVccs value.

Condition:

When ILMI is enabled and negotiated mxVccs or maxVpcs are less than configured value. Addition of SPVC or SPVP are allowed.

Workaround:

NONE

CSCdr77019

Symptom:

Memory allocation failure detected in stats region on the PXM card.

This is the SNMP region - region2.

Conditions:

On multiple resets on a specific AXSM card in the system, we might get into a situation where we are losing memory per AXSM reset on the PXM card.

Workaround:

None.

Additional Information:

In such cases, conduct a switchover to the other PXM card in the shelf. If you have a single PXM, reset the card. Note: conducting a reset on the PXM card will cause service outage.

CSCdr77941

Symptom:

Debugging 'printf' messages are displayed.

Condition:

These messages are not meaningful to users and they occur, for example, when CLI commands are entered with invalid parameters.

Workaround:

No known workaround.

CSCdr88980

Symptom:

SFrame tic lock errors are generated and the planes are not able to recover.

Condition:

At PXM-45 shell, issue "xbarPxmPioSerClkEnable" or "debugger"

Workaround:

Issue xbarSFrameResync(xbarPslot, plane) at PXM shell to resync. each plane manually.

CSCds01758

Symptom:

An incorrect error message is displayed on the CLI when the setrev command is issued.

Condition:

When attempting to do a setrev on an empty slot, an error message is displayed to indicate the file does not exist. This happens because the card type in the slot cannot be determined (slot is empty).

Workaround:

None

CSCds03436

Symptom:

Call to remove a stats file fails and an event is logged. This is an intermittent problem.

Condition:

Remove fails because for a 15 minute bucket interval, there are two files generated. As they have the same name (same interval), the file gets overwritten and there is only one file in memory. Two entries are registered for the same file as it was generated twice. For the first entry, remove is successful. For the second entry, remove fails. The cause of this problem is that there is a syncing problem with the ticks and the system clock time. Even though timeout happens after the specified number of ticks, the system time shows a lesser time.

Workaround:

None.

CSCds05239

Symptom:

If quit in previous display for dspsarcnt - after that time, if dspsarcnt is done - no output is seen on the screen. The prompt is returned back.

Condition:

Happens every time user quits out of display of dspsarcnt. If however user does not quit - but types CR - then the problem is not seen.

Workaround:

Do not type quit during display of dspsarcnt.

CSCds06083

Symptoms:

addport, addpart, delport or delpart commands can be rejected

Condition:

Vastier port data structure is not initialized at the time of port configuration, this causes garbage to be present in the port data structure, which sometimes turns out that the VSICore thinks that clock is configured, even though it was not.

Workaround:

None

CSCds11605

Symptoms:

When adding connections right after performing a switchcc, occasionally, VSIErr 0x9003 is displayed on the AXSM console even though all connections are successfully added. Please note that this VSIErr is non-service affecting.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) Connections are established from NODE_EP1 to NODE_EP2.

(3) perform a switchcc on NODE_EP1.

(4) Right after the switchcc, add SPVCs on the UNI at NODE_EP1. Occasionally, VSIErr 0x9003 is displayed on the AXSM console even though all connections are successfully added.

Workaround:

Do not add connections right after performing switchcc. Wait for about 0.5 to 1 minute.

CSCds15141

Symptom:

After the AXSM card resets due to watchdog timeout, You enter "dspcd n" command from the PXM console for the AXSM card in slot n shows UNKNOWN REASON reset reason.

Condition:

This is due to an invalid reset reason provided by the boot software from the AXSM card to the "dspcd n" command of the PXM.

We modify the boot software for the AXSM card to provide the appropriate reset reason to the PXM during the AXSM power up. With this fix, you enter "dspcd n" command from the PXM for an AXSM card in slot n, the console displays the correct reset reason for the AXSM card instead of UNKNOWN REASON ass seen before.

Workaround:

none

CSCds15997

Symptom:

When user does an addpart with a partition id > 5, the front end accepts the command but is never applied to the internal data structures.

Condition:

The internal data structures of RM had restricted the number of partitions to 5 (to conserve memory). The partition id mapped one to one with the partition index in the internal RM data structures. Since the partition id is restricted internally, there is no point in allowing for a larger value of partition id in the CLI/SNMP interface.

Workaround:

Do not provision partitions with partition id > 5.

CSCds16572

Symptom:

AXSM card reboots and is stuck in failed state.

Conditions:

Trying to burn non-existent boot code.

Workaround:

None.

CSCds17159

Symptom:

The data transfer fails in MGX 8850 node for data option with aesa_ping command

Condition:

This is caused when LCN binding is done before adding the LCN to LCN table.

Workaround:

None.

CSCds17564

Symptom:

On execution of dsperr command using the "-en <errornumber>" option, data can be displayed for a different error number.

Conditions:

Execution of "dsperr -en <errornum> -sl <slotnumb>" where the shelf has experienced at least 100+ errors logged.

Workaround:

This indicates that the error files, 100 per card, have been overwritten due to the numerous errors being logged by the card. The workaround would be to catch the error as early as possible by doing the dsperr command.

CSCds20339

Symptom:

When "cnfcdsct" command is executed with ports present, the error message is "conns are still present" instead of "down all ports before configuring card SCT".

Condition:

When "cnfcdsct" is called with any port in "upport" state.

Workaround:

Ignore "conns are still present". Go ahead and down all ports before calling "cnfcdsct".

CSCds25447

Symptom:

There should be no visible symptoms for this bug. This bug is raised purely for code maintainability purposes.

Condition:

Not applicable.

Workaround:

Not applicable.

CSCds25483

Symptom:

An active call which receives a Release-Complete message will fail to release the call in a particular case.

Condition:

This case may occur when a badly formatted Release-Complete message is received when the call is active. The data structures associated with the call will remain intact causing a dangling connection. The state of the call will erroneously show N0 state.

Subsequent receipt of a Release message will also fail to clear the call fully.

Workaround:

The audit task which runs in the background periodically will clear the dangling connection.

CSCds26619

Symptom:

When resetsys, dsplog -mod CC shows CC-4-SCALING and "active call already exist" in standby

Condition:

It happens with redundancy node that does resetsys

Workaround:

none

CSCds27960

Symptom:

When working line cable is pulled and active line switches to protection line, "dspapsln" command "Alarm State" shows "Clear" even if "Working Line Pending Request" shows "SignalFailLowPriority".

Condition:

Working line fails.

Workaround:

"Working Line Pending Request" is correct. Ignore "Alarm State".

CSCds29751

Symptom:

In a multi node setup, a call cannot be established fully. Before it is established, it gets released from the network.

Condition:

The CONNECT messages are not arriving in time for the call to be set up.

Workaround:

None.

CSCds30477

Symptoms:

addaddr takes address matching host address.

Conditions:

Adding ATM address using addaddr.

WorkAround:

delete uni address matching host address and add unique address.

CSCds32847

Symptoms:

When user not specify a CBR connection's CTD/CDV value, it shows in PXM as N/A while -1 in AXSM.

Conditions:

When you provision the CBR connection without specify CTD/CDV values.

Workaround:

Provision with CDV/CTD values.

CSCds33218

Symptom:

TLB exception caused by a an invalid parameter. This causes an event to be logged and the interrupted FTP request must be retried.

Condition:

An ftp request is interrupted during logout.

Workaround:

None.

CSCds33855

Symptoms:

Event log header in the event log being created is not complete. Cannot read logs from that file.

Conditions:

When a event log file is being created, PXM has been reset.

Workaround:

Event logs can be read on redundant PXM card.

CSCds35438

Symptom:

The PXM and AXSM card does not support netmask for the IP of the ethernet device. When you issue bootChange command, the "inet on ethernet (e)" field can be entered with the following format:

inet on ethernet (e) : a.b.c.d:ffff0000

a,b,c,d have value from 0 to 255.

ffff0000 is the netmask which is not saved to Non-volatile storage device. When you entered the IP and netmask as shown above, the PXM or AXSM card cannot boot from network on the next power up because an invalid netmask (not the one you entered) is used.

We allocate a portion of the Non-volatile storage device for software to store the netmask. And also software to validate the netmask you entered before save to Non-volatile storage device. This insure successful boot from network for the PXM and AXSM card.

Condition:

none

Workaround:

Do not enter netmask during bootChange

CSCds40655

Symptom:

1. For some successfully routed calls the Master end showed Last Fail cause as Invalid while the slave end showed SPVC Established.

2. No information on how the last fail cause field is being populated.

Condition:

None

Work Around:

None

CSCds43034

Symptom:

A message appeared on the console when AXSM card is in Failed state.

Condition:

Injecting a hardware failure on SRAM component of Active PXM-45 card manually.

Workaround:

None

CSCds45296

Symptom:

dspconinfo was showing x lines of wrong state with x down SPVCs. This was happening because dspconinfo was not handling downed conns. So handling of downed conns will eliminate the problem.

Condition:

When ever there was downed conns and dspconinfo was executed, the Wrong state string used to appear.

Work Around :

None

CSCds45411

Symptoms:

Address search fail errors are sometimes seen in the following setup... 1. NNI ports on different AXSM cards connected back to back with ILMI enabled on both ports. 2. One of the AXSM cards has a redundancy setup and the error messages are seen on that card.

Conditions:

The error messages are seen in the following cases

1. The port is downed (dnport). 2. The AXSM card is switched (switchredcd) 3. The peer AXSM card is reset.

The address tables on the active and standby cards don't get synched up when a new address is added. As a result when an address has to be deleted it is sometimes not found on the standby. This problem does not affect the ILMI servicing any way because when an AXSM card switchover occurs the resynch process synchs up the address tables on the standby card.

Workaround:

None

CSCds53634

Symptom:

When a line on an OC-3 MMF back card of AXSM is down (using dnln) the laser is not turned off. The other end of the line does not declare LOS.

Condition:

This happens on all OC-3 MMF back cards of AXSM. This is a hardware issue and the investigation is in progress to determine the root cause.

Workaround:

None.

CSCds54873

Symptom:

After the axsm switch over, if there were ilmi sessions been enabled, you will see a few ilmi messages.

Condition:

The data pane switch over faster than control pane, so we will start getting ilmi PDU on the newly Active going card just before the card goes to Active Ready. The message indicate them.

Workaround:

None

CSCds55631

Symptom:

Whenever a port state changes - the change is not recorded in the event log.

Condition:

All port state changes.

Workaround:

None.

CSCds55684

Symptom:

Message on AXSM console, RCV_DISP_TSK Rcvfailed due to length err msg.

Condition:

This is a harmless error that may occur anytime. Caused by a cell lost in the maintenance cell bus. Message will be retried.

Workaround:

None

CSCds55940

Symptom:

Card alarm is generated when core redundancy is lost.

Condition:

Even when core redundancy is disabled using cnfndparms.

Workaround:

None

CSCds56244

Symptoms:

The cause code in the Release message will not carry QOS unavailable when the end to end CDV or CTD fails

Conditions:

Whenever a call is initiated with an end to end CTD or CDV value which cannot be supported on the node, the routing failure cause code will be only Destination Unreachable.

Workaround:

Unknown.

CSCds57341

Symptom:

Axsm may consider Multiple Bit error as One Bit error (CRC-8 is not sufficient to detect/correct One bit error) and tries to correct that.

So it will come up with wrong VPI/VCI. If VPI/VCI are configured then data will be sent to the wrong destination. If VPI/VCI is not configured, dsplncnt will show invalid VPI/VCI.

Condition:

In the device configuration HEC is enabled to detect and correct one bit error.

Workaround:

Now HEC is disabled in device configuration. If problem persists then do the following at DIP, if available dad write 0x60= 5

CSCds58507

Symptom:

dpscd and dspcds do not indicate upgrade status for the cards being upgraded

Conditions:

Initiate upgrades on a card set and use the dspcd/dspcds. The card show normal card states.

Work Around:

Look at the Prim/Sec/Current revision using the dspcd for each cards.

CSCds58799

Symptom:

dsppnni-link command takes logical port as the input argument.

Condition:

It is the syntax for this command.

Workaround:

None. Use dsppnport <port> to get the logical port id.

CSCds58912

Symptom:

CC alarm is not always reported.

Condition:

Enabling and Disabling CC multiple times on a connection may cause the CC alarm not to be reported.

Workaround:

None.

CSCds59341

Symptom:

AXSM "dspcd" command always show reset reason as "On Power up".

Condition:

No special condition.

Workaround:

Ignore AXSM dspcd reset reason.

CSCds60757

Symptom:

Crossbar alarm is observed. The alarm can be displayed using the CLI command dspswalm.

Conditions:

When switch cards (XM60, or PXM-45) reset, transient Crossbar errors are present. After the switch cards come up, the error counters should stop incrementing (dspxbarerrcnt). Prior to the revision 2.0.12, the error thresholds are set low. Therefore, a false crossbar alarm might be triggered during switch card reset. The alarm can be ignored as long as the crossbar error counts are not incrementing continuously. This might be observed during upgrade because switch cards are reset during upgrade.

In the revision 2.0.12 or later, the error thresholds are set properly.

Work Around:

None.

CSCds61205

Symptom:

On a T3/E3 front card, it is possible to do an upln without a back card. The line would default to T3 mode. This causes confusion with the

SHM which is not aware of the back card type until the user inserts a card.

Condition:

Stated above in symptom.

Workaround:

Do not "upln" on a T3/E3 AXSM card without inserting its T3/E3 back card.

CSCds62345

Symptom:

System runs out of memory due to a memory leak.

Condition:

In rare cases, when we try to send out a SETUP message, we could have a situation where a packet is held up and never freed.

Workaround:

None.

CSCds63066

Symptom:

One or more AXSM cards fail to come up while Standby PXM is coming up.

Conditions:

When an AXSM card is coming up while Standby PXM is coming up, the applications fail to complete the initialization on the AXSM card. This results in AXSM card failing to come up.

Workaround:

Reset the failed AXSM cards once the Standby PXM is READY.

CSCds63506

Symptom:

No defect will be exposed to user.

Condition:

Not applicable.

Work around:

Not applicable.

CSCds63743

Symptom:

popup of some messages interfere with the scripts. Non service affecting.

Condition:

Issuing the command switchredcd

Workaround:

None

CSCds64292

Symptom:

When you issue sysBackupBoot from VxWorks shell of PXM-45 card (pxm45>), the card reboot and then prompt the following:

Press Return key stop auto-boot, d and Return for Diag... 5

This provides you the options to run (1) boot from LAN, (2) diagnostic, (3) backup boot.

Condition:

This condition occur to provide more boot options during development.

Workaround:

None

CSCds64751

Symptom:

When you issue a bootChange command on the PXM-45 or AXSM card and enter boot information, with the ethernet IP contains netmask as shown:

inet on ethernet (e) : a.b.c.d:fff00000

The netmask field is not saved to non-volatile storage device. Therefore, The next time the PXM-45 or AXSM card power up, the netmask is lost.

We allocate non-volatile storage device to store netmask after you do the bootChange command so that it is available on the next card power up. This software release requires a requisite release which initializes the netmask field in the Non-volatile storage to a valid netmask value.

Condition:

none

Workaround:

Do not enter netmask during bootChange.

CSCds65569

Symptom:

Unexpected popup messages are show on the AXSM console by default.

Condition:

Using the command cnfcdsct.

Workaround:

N/A

CSCds65600

Symptom:

"CM_ASYNC_API: force resync start" msg being displayed on the console

Condition:

Whenever the force resync kicks in.

Workaround:

None.

CSCds66485

Symptom:

dspchancnt gives wrong error message.

Condition:

dspchancnt on a admin down or oper down interface gives a misleading error message. It does not reflect the current state of the interface.

Workaround:

None.

CSCds66753

Symptom:

When you issue bootChange command and enter the boot information for PXM-45 or AXSM card, only a portion of the netmask information is saved to non-volatile storage device. The board network interface remains operational because a copy of the information you entered is saved in RAM. Only the copy saves in non-volatile storage device have incomplete netmask information. Each times the PXM-45 or the AXSM card power up or reset, the boot information is retrieved from non-volatile storage device is with an invalid netmask. Thus, the board network interface becomes non-operational.

We now allocate a portion of the non-volatile storage device sufficient to store the complete netmask information. Before we can use that portion of the non-volatile storage device, we initialize it to a valid netmask value.

Condition:

none

Workaround:

do not enter netmask during bootChange.

CSCds69631

Symptom:

Debug messages are displayed as Error messages in log file

Condition:

With ABR calls and vsvd 0

Workaround:

none

CSCds71026

Symptoms:

aesa_ping setup timing out even after receiving connect.

Condition:

caused by getting wrong index variable.

Workaround:

Unknown

CSCds72007

Symptom:

The AXSM cards always download the firmware image from the Active PXM disk.

Conditions:

If the node was previously running 2.0.2.x and upgraded to 2.0.10.x or later, the AXSM cards always get downloaded the firmware image from the Active PXM disk even though the AXSM cards have the image in their Flash.

Workaround:

Use the shell command gShmForcedSwDnldSet (<slot>, 0), where 'slot' is the physical slot number of the AXSM card, to enable AXSM card download the image from its Flash.

CSCds73161

Symptom:

On Standby side some times we do see Trf Param: Broken link error in event log. No other functional effects

Condition:

This happens when sometimes traffic index is journaled to standby before traffic parameters. This should not have and side effect at all and act-stdby should be in sync. This is just a confusing error message and need not to worry.

WorkAround:

None

CSCds73759

Symptom:

After APS is deleted, the previous working line shows "major" alarm state in dsplns command, but no obvious alarm in dspalm command.

Condition:

APS is deleted when the working line is in no alarm state but the working line is in critical alarm state. Unfortunately, the dsplns command does not show the separate alarm state of working and protection line, the two alarm states are combined to form a "major" alarm state. dspapslns should shown working line as "OK" and protection line as "ALM".

Workaround:

Do something that can change the alarm state of the line. For example pull the line out and in, or used loop command.

CSCds74043

Symptom:

XBAR planes are shut down automatically. This can be displayed using the CLI command dspxbar.

Condition:

When the auto shut-down feature is enabled with the CLI command cnfxbarmgmt and XBAR errors are present. Sometimes, transient XBAR errors can also trigger XBAR plane shut down.

The auto shut-down feature is not supported in 2.0x releases. The feature will be blocked in the release 2.0(12) in CLI.

Workaround:

Always disable the feature in 2.0x releases.

CSCds74734

Symptom:

After using Esc Ctrl 2 to raise the priority of cli, and the session ended to restore the lower priority of cli, one of the tasks remained at a higher priority. This is only visible through "dsptask 1 2" cli command or through the shellconn "i" command.

Condition:

On the debug console only after raising the priority of cli using the Esc Ctrl 2 sequence.

Workaround:

There is no workaround. This will not cause a problem.

CSCds78275

Symptom:

On the PXM console, user see SHM BRAM Checksum Error

Condition:

During bringup of a fresh PXM-45 card with a different release than the existing database version.

Workaround:

None

CSCds79948

Symptom:

The errno value for event logging by QE48SAR_EVENT was always -1.

Condition:

Enable event logging for QE48SAR_EVENT and check the log generated. Instead of displaying a meaningful errno, a "-1" was displayed always.

Workaround:

None.

CSCds80408

Symptom:

cnfndparms CLI command for some options may prompt for value range but that is not the correct range for an option.

Conditions:

CLI command cnfndparms

Workaround:

Look at the help for an option to select value.

CSCds82118

Symptom:

Control chars in file names' are printed as is during listing of the files.

Condition:

Accidental creation of file(s) with control characters in its (their) name(s).

Workaround:

None.

CSCds82216

Symptom:

file descriptor is leaked

Conditions:

Any time an ftp session to the switch is rejected because the maximum session count has been reached

Workaround:

Don't open more than 4 ftp sessions at one time

CSCds83255

Symptom:

No tracing of card-to-card multicast messages

Conditions:

Performing link trace on a slot. Do not see the multicast messages sent to that slot.

Workaround:

None.

CSCds83659

Symptom:

When you dspcons on AXSM card, you will see a partial number of connections ended by a connection of vpi=4095 and vci=65535.

Condition:

This problem is reproducible and happens in any condition.

Workaround:

If the connection of vpi=4095 and vci=65535 is deleted, dspcons works okay then.

CSCds84064

Symptom:

When connection is deleted from the feeder side. dspcons on AXSM card shows the connection as Abit Alarm but no AIS is generated towards the CPE.

Condition:

If feeder connection is deleted, AXSM card shows Abit alarm. But Abit alarm can be generated due to different reasons too. So from AXSM point of view, we cannot say for sure that connection is deleted from feeder.

Workaround:

Do a dspcons on feeder side and verify that the particular connection does not exist.

The fix does not affect the existing behavior. But after this fix, AXSM card will generate AIS towards CPE on receiving a deletion D-bit from feeder. A bit alarm will be seen on the connection as before.

CSCds86283

Symptom:

dsprevs shows current revision for empty slot

Condition:

After AXSM and PXM card removable, issue dsprevs command

Work around:

None

CSCds86860

Symptom:

tSyncRamDb error logged in error file while burning new boot on the PXM card.

Condition:

This condition occurs when a new boot is burnt on the PXM.

Workaround:

Unknown.

CSCds87038

Symptom:

dspdiagcnf, dspdiagerr and dspdiagstatus commands do not break after 24 lines.

Condition:

Normal Operation

Workaround:

UNKNOWN

CSCds87474

Symptom:

Telneting from one node to other node causes displacement of command prompt. It is not service impacting error. It is just a display issue.

Condition:

Using CLI 'telnet' command to telnet from one node to another node.

Workaround:

No known workaround.

CSCds87628

Symptom:

Fan tray alarms not reported correctly.

Condition:

User execution of dspenvalms clearly shows that there are no fan trays present, yet it is not being reported as an alarm. Traps are also not being sent to CWM appropriately.

Workaround:

None

CSCds88098

Symptoms:

When svcifconfig atm0 local 47.0091.8100.5670.0101.0101.0101.0101.0101.0101.01 it gives ERR: svcifconfig: local AESA not in DOWN state (UP) for atm0

Condition:

After giving svcifconfig atm0 local 00.0000.0000.0000.0000.0000.0000.0000.0000.0000.00 dspsvcif atm0 is in Up state.

Then when svcifconfig atm0 local 47.0091.8100.5670.0101.0101.0101.0101.0101.0101.01 it gives ERR: svcifconfig: local AESA not in DOWN state (UP) for atm0

Workaround:

Issue commands to disable and then enable SVC connections on interface to clear condition:

ipifconfig atm0 nosvc ipifconfig atm0 svc

CSCds88721

Symptoms:

When system rebooted without any fan trays, no alarms or traps generated.

Condition:

Both fan trays are uncabled or physically removed.

Workaround:

None

CSCds91241

Symptom:

When there is an active PXM-45 in the shelf and you insert a PXM-45B into the same shelf. The active PXM-45 receive card type from the inserted card as PXM-45 and not PXM-45B.

Condition:

none

Work-around:

none, code fix in place.

CSCdt00594

Symptom:

When Injecting LOF from an OmniBer Test set. Initial dspalm -sonet 1.6 shows Section Alarm State: LOF. This is fine.

However, when clearing the LOF on the OmniBer, it still shows LOF when entering the command "dspalm -sonet 1.6" Condition: The cause of the problem was due to the fact that when LOF is cleared, there were still no messages being sent to EM to update the change of the status.

Workaround:

The fix was implemented in the file, "sonet_line.c" in the section where it sends a message "RED_ALM_CLEAR_EVT". Instead of the "and" condition, the conditional checking should have been "ORed".

Problems Fixed in Release 2.0.11

Bug ID

Description

S1 Bugs

CSCdr70497

Symptoms:

The active PXM card takes over 10 minutes to present the login prompt, and meanwhile, the standby PXM is reset multiple times automatically.

Conditions:

This is a rare condition where the standby PXM has to experience a card reset fault while it is powering up, and the active PXM in is the middle of mastership arbitration with this standby PXM card. Mastership arbitration is performed between the active and the standby PXMs when both PXMs are powered up at the same time.

Workaround:

The active PXM will eventually rebooted itself within 15 minutes and abort the mastership arbitration when the above condition occurred. The node will come automatically afterward.

CSCds07776

Symptom:

The Standby AXSM/PXM fails to come up and is put in FAILED state.

Condition:

After several hundred switchovers, the Standby card fails to come up due to failure of a DB Table Creation. This results in Standby card failing to complete its initialization and hence gets rebooted. After three such attempts, the card is put in FAILED state.

Workaround:

Reset the corresponding ACTIVE card.

Problem Occurrence:

Intermittent or occurs once.

CSCds16063

Symptoms:

SPVCs do not get routed.

Conditions:

When there is a configuration error on two ends of a trunk with a VPI/VCI mismatch, the master SPVCs generated from the node with the lower nodeid with the configuration error will have failed calls. The connections may not get routed even if there are parallel links without any configuration error

Workaround:

The workaround for this problem will be to remove this configuration error.

CSCds22416

Symptoms:

The problem will cause UBR calls to fail

Conditions:

When AVCR for a PNNI link along the route to the destination becomes zero, the route search for that destination will fail even for UBR calls.

Workaround:

None

CSCds24309

Symptom

Switchred repeatedly will cause one of the APS sides to have the following

configuration

J1.3.AXSM.a > dspapsln 3.1.5

Working Index : 3.1.5 Protection Index : 4.1.5

Provisioned Arch : 1+1 Provisioned Direction : bi

Operational Arch : 1+1 Operational Direction : bi

Active Line : working WTR(min) : 5

SFBer 10^-n : 3 SDBer 10^-n : 5

Revertive : Yes Last User Switch Req : ForcedW->P

Bridge State : WChan Bridged Selector State : Selector Released

Protection Line Pending Request : SignalFailLowPriority

Working Line Pending Request : None

APS Trouble Mask : ProtectionSwitchingByte,ModeMismatch

Bit Map Req Field Chan Field

Transmit K1 0xc0 Sig Fail Low Null Channel

Receive K1 0x20 Reverse Request Null Channel

Current Request 0xc0 Sig Fail Low Null Channel

Bit Map Chan Field Arch Field Dir Mode Field

Transmit K2 0x5 Null Channel 1+1 BI

Receive K2 0xd Null Channel 1:1 BI

Alarm State Clear

Condition

Repeated switchredcd causes this condition when APS is provisioned.

Effect - This would prevent APS from switching to the protection line in case of any failure on the working line causing loss of traffic.

Work Around.

Executing forced switch from working to protection using switchapsln <bay> <line> 3 <serviceswitch> on both sides should clear it.

CSCds24374

Symptoms:

The card goes to Failed state after 3 SW/HW error resets, with reason SHM_CDF_MAX_RESETS_REACHED.

Conditions:

The card is getting reset continuously because of some SW/HW error in the card. These three resets have to be within a period of 100 hours

Workaround:

None

Additional Information:

Reset the card by using cli command resetCd <slotNo> for that card.

CSCds26049

Symptom:

Standby Card in continuos reset with HW monitor task crashing with TLB exception

Conditions:

When upgrading from release 2.0(23.1) to 2.0(30)A1 using the graceful upgrade method.

Workaround:

Use setrev to go to release 2.0(30)A1

CSCds28030

Symptoms:

CWM will not be able to read the SCT file from the disk.

Condition:

If the SCT file which is not created by the CWM, is used, the SCT-ID fields are always set to 1 even for SCT files with ID other than 1. This causes the CWM to abort the file read operation.

Workaround:

Use the latest SCT file or use the SCT files created by CWM.

CSCds33324

Symptom:

PNNI can't detect bad clock source.

Condition:

The cause effect of this problem is that the PNNI will not get the trap, when the clock manager report the clock has a problem.

Workaround:

Not available

CSCds34606

Symptom:

switchredcd <from-slot> <to-slot> with large and invalid value for from or to slots would cause PXM to crash then switchover.

Conditions:

switchredcd with invalid slot values.

Workaround:

Don't give invalid slot value. Use only slot number from 1 to 32

CSCds34659

Symptom:

Shelf Manager task got suspended.

Condition:

Exception in the Shelf Manager task.

Workaround:

Pullout the PXM-45 card and re-insert it.

CSCds34714

Symptom:

After executing a "resetsys" command, on a system with 12 standalone (non redundant) AXSM cards and 2 PXM cards (slot 7 and 8), the ACTIVE PXM card coming up (after the resetsys) might experience going into an ACTIVE-F state. This will cause a switchover to the other PXM card as soon as the other PXM card is available (i.e. gone to STANDBY state).

Conditions:

1) fully loaded MGX 8850 shelf (12 standalone AXSM cards and 2 PXM cards).

2) execution of "resetsys" command from cli.

Workaround:

If you need to execute "resetsys" on a fully loaded shelf/node, and you have experienced this problem, you can recover by removing some of your AXSM cards from the shelf before the resetsys is executed. The recommendation is to leave only 3 cards in the shelf before the resetsys command is executed.

CSCds37401

Symptom:

In a redundancy configuration, repeated valid and/or invalid addred/delred commands may corrupt the back card type. This will be seen in dspcd in AXSM or PXM. Subsequent valid addred commands will be rejected because of back card type mismatch.

Condition:

Repeated valid and/or invalid addred/delred commands.

Workaround:

None

Additional Information:

Reboot the Active AXSM card.

CSCds40915

Symptom:

pnCcb task gets suspended

Condition:

Unknown. Till now we have just observed it 2 times in only one network. Have put efforts to reproduce it in the same network but were not successful.

WorkAround:

None

CSCds44402

Symptom:

After a switchredcd, newly active card could not become active ready (see i at CLI prompt) and both cards in redundant pair get reset after a about 5 minutes.

Conditions:

One of the applications on the active card did not transition to active state in time.

Workaround:

None.

CSCds45313

Symptom:

Active PXM card got soft failure (Active-F) when using CLI command of "dspcds". Standby PXM card is also not coming up. The system will come up the error message like pnRedman task is running away CPU.

Condition:

Running many "resetsys" with script file on a node that has more than 20 pnni-links and 14K connections. After about 3 hours the pnRedman task got suspended. The problem is caused by a clocking port coming up and down dynamically, which happens under rare conditions.

Workaround:

None.

CSCds46519

Symptom:

ilmi task crashs and card may reset.

Condition:

There was a problem in Vsicore w.r.t passup and if for some reason vsicore blocked the ilmiPassuptask, ilmiMain was crashing.

Workaround:

Normally this problem used to happen only when we had more than 30 interface on a single axsm with ilmi enabled. So reduce the number of interface with ilmi enabled.

CSCds47673

Symptom:

On the affected interface PNNI protocol will be in "ATTEMPT" state and no connections can be routed over this trunk. SSCOP protocol on an affected interface will show "RESET" state. On a PNNI link either PNNI or SSCOP or both might be impacted.

Conditions:

Under rare conditions, resetting of the PXM card may result in PNNI/SSCOP protocols on some interfaces not being able to communicate with their peers. This results in SSCOP being in "RESET" state and PNNI being in "ATTEMPT" state.

Workaround:

None

Other Information:

When an interface is affected by this problem, downing (dnpnport) and subsequently upping (uppnport) the interface will alleviate the problem.

CSCds50617

Symptom:

The Standby PXM/AXSM card fails to come up.

Conditions:

The control information on the Active PXM/AXSM card used by the Standby PXM/AXSM card is corrupted. This results in the applications on the Standby PXM/AXSM card fail to complete their initialization failing the card to come up.

Workaround:

The Active peer of the failed card should be rebooted.

CSCds51901

Symptom:

Floating point exception and system gets reloaded automatically.

Condition:

If a task is doing floating point operation and in middle of that context switch happens and new task also does the floating point operation and now when original task is scheduled, floating point registers have invalid value for that task vxworks doesn't store floating point vars on context switch if that task in not spawned with some flag set. Due to this that task will create floating point exception

WorkAround:

none

CSCds52919

Symptom:

PXM-45 could crash due to SAR Link list access invalid Pointer. This problem is caused by the changed in CSCds38562, where we cleanup the HUMVEE ILT and ELT table entry The ILT table is not protected so ILT table could delete more than once, once by proxy slave and another by PNNI, when they unbind the GLCN.

Solution:

The solution is to protect the ILT with the reference to refKey, if the refKey is not zero, then we will delete the ILT, after that initialize the refKey to zero.

Workaround:

None

CSCds56700

Symptom:

In a single PXM node, after runrev is done the PXM card resets 2 times and comes back in the older revision

Conditions:

In order to get into this, you have to do a setrev back to the older revision from the higher revision. This causes a rebuild from disk.

Work Around:

Once in the older revision Need to clear the rebuild from disk flag before you do upgrades sh> gShmRebuildFlag 2

CSCds57024

Symptoms:

The sscop is not in Established state or the PNNI link is not up and running though the port status as seen on the controller shows as up and good. The Control VC connections are missing on either or both the slave cards.

Conditions:

After resetsys and when the system is coming up, the ports may look healthy as seen by dsppnport or dsppnports commands.

Workaround:

Reset the card on the switch (AXSM).

CSCds63376

Symptom:

Axsm card resets while attempting to read sct file.

Condition:

The problem happens if the SCT file being read is of size zero (or bad)

Workaround:

Don't leave any corrupted SCT file of size zero bytes, or load latest revision firmware which handles this error case.

CSCds64807

Symptom:

After you add the connections, then you change the number of LCNs in your partition, if the number of the connections is more than LCN number, some of the connections would be failed. If you reset the Service module, the connections failed routing may be no deterministic. That is, before routed connection may be failed while some failed connections may be successfully routed.

Workaround:

Do not change the LCN number below the provisioned SPVCs.

CSCds65556

Symptoms:

The controller was out of memory and restarted.

Conditions:

Seems a rare scenario caused probably due to flaky links resulting in deroute plus reroute of 50000 spvcs.

Workaround:

None.

CSCds68882

Symptom:

When upgrading from 2.0.10 or earlier AXSM image to 2.0.11 image, both active and standby can get reset.

Condition:

Both active and standby running 2.0.10 or earlier image, when loadrev is executed, standby AXSM card may be reset multiple times before finally coming to standby and then active.

Previous active AXSM card may also reset itself before finally come to standby state with 2.0.11

Workaround:

- use vsiChkAll to verify all connections are healthy before running loadrev.

Note:

This is caused by a bug in 2.0.10 or earlier image (now fixed in 2.0.11) where invalid connection information may be sent to standby.

CSCds71908

Symptom:

When you enter sysBackupBoot at the command shell prompt pxm45> of a standby PXM45 (where two PXM45 cards installed in the shelf) or from an active PXM45 (where only one PXM45 installed in the shelf), the command prompt does not come back. Furthermore, the PXM45 does not get into backup boot.

Condition:

This condition occurs because the bootline is not initialized similar to the one shown below.

Unknown.7.PXM.a > bootChange

'.' = clear field; '-' = go to previous field; ^D = quit

boot device : lnPci

processor number : 0

host name :

file name :

inet on ethernet (e) : 0.0.0.0

inet on backplane (b):

host inet (h) : 0.0.0.0

gateway inet (g) : 0.0.0.0

user (u) :

ftp password (pw) (blank = use rsh):

flags (f) : 0x0

target name (tn) :

startup script (s) :

other (o) :

Workaround:

To work around this, you can do one of two things: (1) Initialize the bootline by entering bootChange from the CLI prompt to input the appropriate IP addresses. Then reboot the card with Esc-Ctrl-x keys hold down together. This makes VxWorks recognize the new bootline entries. After the PXM45 comes up, you can then issue sysBackupBoot from the shell prompt pxm45>. (2) At the shell prompt pxm45>, enter "sync" command to synchronize the data in DRAM to the hard disk. Then enter sysToMonitor(0xbbee00c4) to reboot into backup boot.

CSCds76260

Symptom: Traps are not being received from the switch. Some traps are getting lost - or no traps are being delivered.

Conditions:

1. On a redundant system, the standby PXM card is reset.

2. On a redundant system, the standby PXM is removed and never reinserted.

3. On a standalone system, a standby PXM is added but is removed and never re-inserted.

4. On a standalone system, a standby PXM is added but fails.

Workaround:

The conditions above will result in a standalone PXM system. In this case, when traps are not being received, the recovery method is to reset the active PXM card.

Further Problem Description:

Due to the bug introduced in the system, the trap client task will go into a state where it will flush its queues and send a lost trap to the CWM/external world in the case where the shm generates a card removal for the standby PXM. When we get this event, we flush our queues and stop sending out the traps. This persists until a standby card is inserted and we get a card avail event for the standby PXM OR the active PXM card is rebooted.

NOTE: Any time we get a card unavail from the standby PXM we will get into this state until a card avail is received by the trap client task. So, inserting a standby card and unplugging it will cause us to get into this state.

S2 Bugs

CSCdr50503

Symptom:

Command Line Interface (either via a telnet session or via the console port) will hang indefinitely using lkup "bit"'m

Condition:

Issuing the command lkup "bit", lkup "bitstring" or any substring between "bit" and "bitstring" will cause the command line interface to hang on an AXSM card. It is a problem with the underlying symbol table display utility.

Workaround:

None

CSCdr78869

Symptom:

Events of type "CHUNKNOTOWNER" are logged in the event log.

Condition:

CLI does a ssiIpcMessageFree before it assigns the memory to itself. This has been corrected an CLI now assigns the memory to itself before freeing it.

Workaround:

None

CSCdr89686

Symptom:

Upon deletion of a secondary clock source with the primary clock source already bad, the node tries to lock to the Primary (even though it is bad.)

Conditions:

This symptom occurs on the MGX 8850 running release 2.0, 2.0(01) or 2.0(02) software. The use should have both clock sources configured.

Workaround.

Wait for about 300 seconds and do a dspclksrcs command. The node will display the correct status of the clock with the Primary bad and the active being the internal.

CSCdr94471

Symptoms:

Standby PXM-45 card gets reset 3 times and stays in Failed state.

Conditions:

Upgrading PXM-45 image from previous version to a new version.

Workaround:

Reset the standby PXM-45 card

Problem Occurrence:

Intermittent or occurs once.

CSCds01593

Symptom:

After issuing an "upln" or "dnln" command, the CLI prompt does not appear to be displayed.

Condition:

An debug alarm summary (similar to "Alarm summary critical 1 Major 0 Minor 1.") was displayed at the end of the CLI prompt without a return character.

Workaround:

Press the "Enter" or "Return" key in order display the CLI prompt again.

CSCds08941

Symptoms:

While performing SPVC deroute (initiated at NODE_VIA, the AXSM card in node NODE_EP1 (AXSM card slot 2) showed IPC allocation failure.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A connection is established from NODE_EP1 to NODE_EP2.

(3) dnpnport on the NNI on NODE_VIA.

(4) On the AXSM card on NODE_EP1, IPC allocation failure was observed.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds09512

Symptoms:

AIS is not generated when dnport issued on AXSM card

Conditions:

a. Issue dnport for a dax conn where both the UNI ports belong to same slave

b. Issue dnport for a routed connection where both UNI port and Trunk port belong to same slave

Workaround:

None.

CSCds09604

Symptom:

On an initial boot up of two AXSM cards. After both cards are booted, redundancy is added. Then you add APS for the intercard case. With this scenario, the trap generates 60126 when the fiber is already moved prior to adding APS. 60126 implies APS Redundancy Alarm.

Conditions:

Once the APS is deleted and added back on later, it does not generate 60126. This behavior does not correspond to the real behavior and therefore is a bug.

Workaround:

This problem cannot be avoided. However, it is not critical to the system not to see this trap. However, it is an error because it is not report an alarm.

CSCds09708

Symptom:

SNMP GETs on the following variables:

cwspOperMaxSvpcVpi, cwspOperMinSvpcVpi, cwspOperMaxSvccVpi, cwspOperMinSvccVpi, cwspOperMaxSvccVci, and cwspOperMinSvccVci may return incorrect value. And the value mismatches with that shown on CLI command. For instance, 'dsppnport' show MaxSvccVci value is 65535, however SNMP get on 'cwspOperMaxSvccVci' variable shows 255.

Condition:

This occurs when the value of these variables is greater than 255.

Workaround:

None

CSCds12955

Symptom:

Calls not routed after setrev

Condition:

Issue the setrev command when 15.5 k SPVCs connections are established between two MGX 8850 nodes.

WorkAround:

None:

Addition Information:

Down and up the nni port which is in attempt state

CSCds13444

Symptom:

The following message is generated in the event log: 08-06262 08/23/2000-15:06:51 SYS-3-RUNAWAYTASK E:02239 tRootTask 0x80132248 Task 0x3f008c[tTnInTsk01] is running away on CPU - logging task.

Condition:

A telnet client attached to a CLI session with no user input was echoing control characters.

Workaround:

None.

CSCds13984

Symptom:

addlnloop command is getting executed when addln is entered. The parser does not check for the exact command entered. The nearest match is returned.

Condition:

Problem occurs when addln is entered instead of addlnloop.

Workaround:

Enter the exact command "addlnloop" or "dellnloop".

CSCds14832

Symptom:

Two nodes (Feeder and another with T3 line, line type PLCP) are interconnected to each other, upon disconnection of T3 RX/TX cable and reconnecting back, AXSM T3 line showed RcvRAI alarm. Feeder side showed communication Failure.

Condition:

False alarm was generated for EM by which RcvRAI was never get cleared.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds16776

Symptom:

The conn pending congestion counter shows negative values.

Condition:

Calling the free SVC routine again is suspected in case of a particular infrequent error path.

Workaround:

None.

CSCds17876

Symptoms:

The node allows SPVCs with VCI less than 32 to be added.

Conditions:

With the port's minsvccvci set to 32, attempts to add SPVCs with VCI less than 32 are not rejected.

Workaround:

In order to properly use SPVCs with VCI values less than 35 (default), perform the command:

cnfpnportrange <portid> -minsvccvci <desired minimal VCI value> before adding SPVCs with low VCI values.

Since the VCI range below 32 is not recommended by ATM Forum and more control VCs are reserved below VCI=35, a warning message listed below will be displayed when the minSvccVci is changed to be below 35:

** Warning: MinSvccVci HAS BEEN ASSIGNED A VALUE LESS THAN 35

CSCds18258

Symptoms:

Some connections are not able to reroute, reroute is not even being attempted; i.e. connections are not routed.

Condition:

Cables are pulled off at master and via nodes. Reconnect the cables but connections are not routed.

Work Around:

No work around

CSCds18328

Symptom:

The switch has changed the default value of SvccVci from 32 to 35. This has not been reflected in the MIB variable 'cwspMinSvccVci' in "CISCO-WAN-SVC-MIB.my".

Condition: From the MIB, an user would assume the SvccVci value is 32, yet when the user tries to configure SVC or SPVC, the switch only allow configuration for 35 and above.

Workaround:

The user can configure SVC or SPVC with VCI only from 35 or above if the user decides to use the default value. The user can also do an snmp GET of this variable for the interface

CSCds19314

Symptom:

The dsppnports on PXM will show ilmi state as autoconfig but axsm is in UpandNormal state or on pxm ilmi will be showed as disable when it was really enabled on axsm. Condition:

Happens more when axsm is rebooted or node is reset. Normally resetting card/node will solve the problem. or even dnpnport and uppnport.

Workaround:

Reduce the number of ports on this card. Happens more when we have more than 35 ports (vnni) with ilmi enabled on them

CSCds20504

Symptom

This behavior is seen when the APS operates in bidirectional mode. The side which sees a channel mismatch failure will go to the selector released state. The other side remains in the protection line selected state.

Condition:

This could cause loss of data as the other side may not have bridged the appropriate line.

Work around

The only way to get out of this situation is to cause a forced switch to the work line. This is done using switchapsln <bay> <line> 4 <service switch>. Do this on both ends of the line.

CSCds23341

Symptom:

Vsierr 0xe007,... is displayed on the screen

Condition:

Combination of cnfpnportcac, addcon and dnport can cause the bandwidth to go negative.

Workaround:

Disable ingress cac. Need to verify this

Problem Occurrence:

Intermittent or occurs once.

CSCds23518

Symptom:

Cell bus connection between PXM and AXSM card is lost, AXSM card is reset.

Condition:

Problem has occurred during trunk switching when there are more than 25K connections.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds23525

Symptom:

Pnni-link port is in attempt state.

Condition:

Multiple switch overs and reset of slave cards.

Workaround:

Bring the port down and up. The port will be up and pnni-link will be in two-way inside.

Problem Occurrence:

Intermittent or occurs once.

CSCds23579

Symptoms:

Occasionally, when downing a UNI port (dnport) on AXSM card after dnpnport and uppnport on the PXM, some VSIErr are displayed on the AXSM console.

Conditions:

(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A connection is established from NODE_EP1 to NODE_EP2.

(3) dnpnport on the UNI on NODE_EP1.

(4) uppnport on the same UNI on NODE_EP1.

(5) dnport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds24399

Symptom:

switchredcd following by a switchcc could make the old active service module stuck in boot state _ the old standby service module is OK and in active state.

Conditions:

switchcc shortly after a switchredcd

Workaround:

1. Wait until both service modules come back to active/standby pair before doing switchcc.

2. If old active service module is stuck in boot then reset it from active PXM.

CSCds25413

Symptom:

In a node with thousands of SPVC calls, deroute of calls followed by a reroute is very slow.

Condition:

Once the node is in a state of congestion caused by too many calls in the state of being setup or being torn down, we need to process RELEASE messages immediately so as to alleviate the congestion. There was a problem noticed in this path where RELEASE message processing was being deferred.

Workaround:

None

CSCds25534

Symptom:

Connections are not able to route due to running out of trk vpi/vci even vpi/vci should not be running out

Condition:

Reset either master node or via node

Workaround:

reset the trunk card

CSCds26981

Symptom:

The AXSM card fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.

Condition: There are more than 4 AXSM cards in the shelf and the file descriptor list gets corrupted on the ACTIVE or STANDBY PXM.

Workaround:

None

Additional Information:

1. Reset the PXM card which has the file descriptor list corrupted if redundancy is available. 2. Call the support to rectify the file descriptor list to avoid resetting the card.

CSCds28316

Symptom:

A nni port with ilmi on is stuck in auto cfg.

Condition:

A "none" port or "ip" port was reconfigured as "pnni10" port and ilmi is enabled on the port.

Workaround:

Configure the port as "uni31" and then back to "pnni10". The port will come up as nni.

CSCds28453

Symptom:

When a dncon / upcon is performed on an endpoint, the connections' upload counter is not updated. Use dspcons to see the upload counter.

Description:

Whenever there is a change in the conn. cnfg the upload counter is updated. This was caused by a error in coding (which excluded the admin status change as a config change).

Workaround:

None.

CSCds28520

Symptom:

OC48 Card CLI hangs, and one cannot execute any commands.

Condition:

Some event on the OC48 back card such as APS switchover, card switchover and back card pull.

Workaround:

Reset the hung card.

CSCds30075

Symptoms:

The PSB condition caused by any condition other than the invalid code is cleared even though the PSB condition has not disappeared.

Condition:

This problem can be created by causing a PSB condition through any cause other than the invalid code.

Workaround:

None

CSCds30425

Symptoms:

An AXSM card may be reset immediately after a PXM switchover.

Conditions:

If an user executes a switchcc command (graceful PXM switchover) while an AXSM card is in the process transitioning to the Active Ready state, that AXSM card will be reset by the new active PXM after the PXM switches over.

Workaround:

Run dspcds to verify that all cards are in a steady state (steady card states are: READY, FAIL, EMPTY, MISMATCH) before executing a grace pxm switchover.

CSCds30710

Symptom:

Standby OC-48 card stuck in reset init state.

Condition:

Standby card was reset.

Workaround:

None

CSCds30721

Symptom:

LCN resource not available and connection commit keep failing

Condition:

de-routing of connections and switchredcd of the trunk card at the same time.

Workaround:

None

CSCds31496

Symptom:

Root task could not delete a suspended task.

Condition:

When a software download task gets suspended.

Workaround:

Reset the card using resetcd command.

CSCds32205

Symptom:

User adds feeder on an interface on which connections exist

Conditions:

User will not be able to delete feeder unless connections are deleted. This could be a problem since feeder might have being added by mistake. A CLI prompt should be added to warn users about this.

WorkAround:

Before adding feeder on a particular interface, make sure it is the right interface especially if there are previous connections on it.

CSCds32276

Symptom:

No immediate symptom. Over time when many addapsln/delapsln/dspapsln commands have been executed, we may get IPC message allocation errors.

Conditions:

Execute addapsln, delapsln or dspapsln commands.

Workaround:

None

CSCds32318

Symptoms:

Line shows that there are some statistical alarms, although, the line has no defects. There are no adverse effects of this.

Conditions:

On a t3 line, when line is enabled.

Workaround:

None.

CSCds32413

Symptom:

After a addred or switchredcd, there may be alarms on some channels in the Active AXSM card.

Condition:

Happens after a addred or a switchredcd

Workaround:

None.

CSCds34183

Symptom:

The symptom is that the VSICore and RM database are not in sync. The vsicore indicates the connection is in committed state, and RM is in reserved state.

Condition:

This situation will happen when the Commit timeout, VSICore will Nak the controller, instead of putting the connection is NULL state, the connection is put in commit state.

Workaround:

None

CSCds34687

Symptom:

The VPI range will be 0-255 for NONE port even the AXSM port is a NNI. This blocks the user to use the VPI bigger than 256.

Condition:

None.

Workaround:

None.

CSCds35591

Symptom:

swichred on PXM, standby becomes active, reset the newly standby PXM,

Condition:

Couple of connections stay in failed state

Work Around:

reroute the failed cons (via rrtcon)

CSCds35710

Symptom:

In a node with thousands of calls, we see that the unacknowledged status enquiry counter is beyond the threshold value. This is seen using the command dspintfcongcntr for a particular interface.

Condition:

We might get into this condition due to PXM switchover. The effect of this is that status enquiry can no more be initiated for audit purposes resulting in erroneous dangling connections being present forever.

Workaround:

none

CSCds36145

Symptom:

Getting incremental RAM Sync send error after line/port/partition commands are executed. See description for display details.

Condition:

Card redundancy are setup. Both active and standby are in ready state. Then standby card is removed.

Workaround:

Do not execute line/port/partition command in redundancy setup when standby card is absent.

CSCds36182

Symptom:

During AXSM switchred, previously standby card gets PHYTask exception while transitioning to active. Ports go into provisioning state.

Condition:

This happens on non-OC3 AXSM cards. Should not be problem for all AXSM card if there is no redundancy.

Workaround:

Do not switchred.

Problem Occurrence:

Intermittent.

CSCds36677

Symptoms:

After AXSM card sends a passup command to the controller, the message counter doesn't increment for the passup cmd message.

Conditions:

(1) On AXSM card, perform addcon, causing a passup command to be sent from the AXSM card to the PXM.

(2) After the command is transmitted, perform the shell command vsiPduCountShow. The counter for passup command is not incremented.

Workaround:

-none.

CSCds37301

Symptom:

ports in standby card stay in "vc failure"

Condition: with multiple switch over of two controller cards

Workaround:

none

CSCds37761

Symptom:

The Active PXM gets a software exception and resets unexpectedly when a file is transferred onto the Active PXM using FTP.

Conditions:

When a file is transferred using FTP onto the Active PXM hard disk to a directory that is replicated to the Standby PXM, at times, the Active PXM completes the replication of the file to the Standby PXM at the same time as an internal software timeout. This results in Active PXM generating a software exception which causes the Active PXM to reset.

Workaround:

None

CSCds38135

Symptom:

dspenvalms shows DC Level outside of threshold range, but no node alarm generated

Conditions:

Power entry module being used to generate power supply voltage. When voltage drops below 3 volts, monitoring software declares that the inputted voltage for threshold check purposes is zero.

Workaround:

None. Under this condition there is no alarm. Should this voltage had been generated in a system with a resident power supply module, an alarm would be generated.

CSCds38320

Symptom:

Some SPVC connections will not be routed and stays in fail state

Condition: Unknown

WorkAround:

Delete SPVC end point and re-add it again.

CSCds38562

Symptom:

Two GLCN programs the same ELT Entry in HUMVEE. HUMVEE will indicates ELT Mismatch, no traffic will be passing through.

Condition:

PNNI try to commit the same SSCOP/RCC/IP connection on two different GLCN.

Workaround:

dnpnport and uppnport to check whether problems goes away, if not, please reset the PXM-45.

CSCds39375

Symptom:

A nni port has a vpi range of (0-255) available instead of the complete range (0-4095).

Condition:

When ports are provisioned to controller, the default interface type is UNI which at release 2.0.30(D) takes on an enforced range of 0-255. Add nni ports with vpi range 0-4095 on AXSM card. Ilmi is turned on these interfaces. The interfaces on used as nni links.

WorkAround:

Use "cnfpnportrange" cmd to increase the range to (0-4095).

CSCds41314

Symptom:

Alarms show up in dspcdalms <slot> for the standby card after a switchred.

Condition: Occurs intermittently after switchred.

Workaround:

Another switchred can clear the condition.

CSCds41496

Symptom:

Resources are not updated for a trunk even after connections have routed along them. This is visible in the dsppnportrsrc command. Connections may not route along expected paths.

Condition:

Upon AXSM reset, addcontroller-delcontroller, AXSM switchover.

WorkAround:

None

CSCds41592

Symptoms:

Before switchcc, take the physical connection out (ex. 3:1.1:1).

dspclksrc

Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: no clock signal Secondary clock type: generic Secondary clock source: 14:1.1:1 Secondary clock status: ok Secondary clock reason: locked Active clock: secondary source switchover mode: non-revertive

After switchcc

Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: not configured Secondary clock type: okay Secondary clock source: 14:1.1:1 Secondary clock status: not configured Secondary clock reason: okay Active clock: internal clock source switchover mode: non-revertive

Conditions:

During switchover (the clock resynchronization), If we get NAK from AXSM card, the existing code did not assign the right slave id. This cause the set clk message did not send to the clk manager. The display never been updated according to clock manager current status.

Workaround:

Make sure the clock port is up (or make sure the port physically connect the clock source), before doing switchcc.

CSCds41617

Symptom:

Receive RAI count is not cleared by clralmcnt command.

Condition:

For each instance that RDI is received, RAI count is incremented. This can happen in T3/E3 and SONET AXSM cards.

Workaround:

Keep a log of the current"Num of RAI" in order to recognize new RDI received.

CSCds41628

Symptom:

Power supply failure does not generate a node alarm.

Conditions:

External DC power source is used to generate power for node. Circuit breaker is tripped on the power source.

Workaround:

None. Software declares a missing power source normal if it has a power reading of zero volts.

CSCds41931

Symptom:

Connection routing failure due to AvCR being zero on PNNI link that previously was out of LCNs.

Conditions:

In addition to the above symptom the condition for this problem to occur is that the LCN availability remains under 8 on the link of interest.

Workaround:

None.

CSCds42022

Symptom:

Trap 60004 cwShelfRestart was not received after a node reset from CLI "resetsys" command.

Condition:

Upon CLI "resetsys", "reboot", or "resetcd"; On certain hardware, the SNMP master agent takes longer to read the disk DB to extract the trap manager ip addresses and configure the trap communities. Thus, by the time the trapserver needs to send traps out, the community strings are not configured and the traps are dropped.

Workaround:

No known workaround.

CSCds44016

Symptoms:

When SPVCs are tunneled through an DAX-SVP connecting two VTs configured with different VPIs, the connection will not be accepted.

Conditions:

When there is a configuration error in provisioning different VPIs across VTs connected via DAX-SVP

Workaround:

The workaround for this problem will be to remove this configuration error and use the same VPI across the VTs

CSCds45150

Symptom:

Port gets stuck in down in progress.

Condition:

The network should have 50k routed spvc connections. Multiple nni links on a node.Down a a nni port on axsm on one of the node.

Workaround:

No work around.

CSCds45453

Symptoms:

Standby AXSM card gets reset multiple times before it becomes standby ready

Condition:

When the syncRamElementAdd fails while connection bulksync, the code erroneous released the iovPtr, which was still used by the higher layer for adding connections into the list. This corrupts memory and when syncRamIovSend is attempted on this bogus iovPtr, the send fails and the active card calls for ramSyncFatalError which resets standby card.

Workaround:

None.

CSCds46551

Symptoms:

When a large number of IISP trunks are configured on the node and a switchover is attempted, system goes into busy state.

This might cause some mismatched connections across the IISP trunks.

Conditions:

When there is a a large number of IISP links are configured on the node and a switchover is attempted.

Workaround:

None

CSCds47500

Symptom:

No event logging is done for APS.

Condition:

None.

Workaround:

None

CSCds47575

Symptom:

Any command on the PXM that accesses the disk will pause for a couple of minutes and displays nothing. Also, any file transfer to the PXM disk will fail. Also, an AXSM card fails to load an SCT file and uses default traffic parameters.

Conditions:

When the dsplog attempts to access the log files that have been corrupted, it fails to close the associated file descriptor. This results in exhausting all the file descriptors available on the system over a period of time.

Workaround:

The PXM card should be rebooted.

CSCds50779

Symptoms:

Some connections are derouted and rerouted continuously.

Conditions:

When the SPVCs are provisioned across IISP and the slave endpoints are in the same node of the IISP link, and the IISP is the user side.

Workaround:

Do not provision the SPVC slave endpoint in the same node with the IISP User side.

CSCds51173

Symptom:

-In a MGX 8850 node, we might have a case where traffic on an SPVC DAX connection cannot be passed though the connection is in OK state on the PXM.

Condition:

This case may occur when the line card containing a DAX connection is removed and re-inserted. After the card-reinsert, the cross connects are not committed to the AXSM card in a specific case.

Workaround:

None.

CSCds52449

Symptom:

Configuration on active AXSM card is destroyed.

Conditions:

Redundancy is added with active AXSM card declared as secondary card.

Workaround:

Make sure that no configuration is enabled on AXSM card before adding to redundancy.

CSCds52468

Symptoms:

The ILMI address will not be sent to PNNI for advertisement.

Conditions:

During switchover, the new active will not send the ILMI addresses to PNNI and the addresses will not be visible in the system address tables. The calls for these addresses will not get routed.

Workaround:

There is no workaround to this situation except to reregister the ILMI addresses or switch over the system again.

CSCds52601

Symptom:

With T3 back card, "addport" or "cnfport" commands fail with min/max port rate at max T3 cell rate (96000 for PLCP mode, 104268 for ADM mode). "dsplns" does show the lines as T3 lines and not E3.

Condition:

The AXSM card was reset with E3 back card in the past, but no "upln" is done using the E3 back card, i.e., back card is not reserved for E3. Then the E3 back card is replaced with T3 back card and "upln" is done so that ports can be added.

Workaround:

If AXSM T3/E3 back card is not reserved for a particular type (T3 or E3), reset card when new back card is inserted before upping lines.

CSCds52916

Symptom:

VTs are still up even when the uni endpoints on spvp tunnel are brought down.

Condition:

Two Virtual trunks are connected through a SPVP tunnel. The uni ports the VTs connected are brought down on the controller.

Workaround:

Bring down the ports on the axsm and VTs will stop communicating.

CSCds53212

Symptom:

Active and Standby system were out of sync with each other from PNNI controller point of view. Active side of controller doesn't know that standby is exist.

Condition:

WIN_TIME_OUT means active tries to send but it timesout before it can send. Workaround:

None

CSCds54891

Symptom:

Previously standby AXSM card cannot transition to active ready state after switchred is performed.

Condition:

The AXSM switchred is executed on PXM while AXSM card is still in the middle of provisioning ports (using scripts, so once it starts, it does not stop until all ports are done).

Workaround:

Do not switchred until AXSM provisioning is completed. Safer still, wait a few seconds after provisioning before switchred.

CSCds55452

Symptoms:

The problem was handling crankback when VP resources are not available.

Conditions:

Under rare conditions, when VPC resources (like VPI values) was not available for outgoing calls, the release was not generated with a crankback and so an alternate route was not selected.

Workaround:

The workaround for this would be to increase the number of crankbacks or increase the VP resources on the failed link.

CSCds55584

Symptoms

SPVC connections FAILED to route. the Last Fail Cause to be Call Rejected.

Condition:

When adding the partition on AXSM card, it is required to configure the maxConns for the partition. The maxConns is constrained to the number of channels supported by a port group. CLI detects, for a given partition ID, if the maxConns entered by the operator exceed the total supported channels with the port group. However, if the operator is adding partitions for different ports that fall within the same port group, as long as each individual partition does not exceed the total supported channels, CLI does not complain the aggregation number exceeding the total supported channels. The problem can be solved by reporting the available channels to PNNI based on the port-group availability which is more accurate.

Workaround:

None

CSCds57279

Symptom:

No traffic passes, PNNI link does not come up, when NNI trunk is configured with a minimum Vpi greater than 255 over an OC48 line.

Condition:

Problem caused by Vpi greater than 255 on OC48 line.

Workaround:

Use a Vpi less than 255 on OC48 lines to avoid this problem.

CSCds57791

Symptoms:

Failure to configure the clock source.

Conditions:

The static memory information has been overwritten by unknown function.

Workaround:

1. goto shellConn by sh command. 2. d &ncdpClockingDb 3. modified the address at &ncdpClockingDb+0xa4 m &ncdpClockingDb+0xa4 (clear to zero). 4. This way will cause the internal code to reallocate new memory to store privateData ptr. 5. In this way, we can continue to configure the clock.

CSCds58806

Symptoms:

The problem was an unexpected routing failure where some calls never get routed.

Conditions:

Under rare conditions, when the node has many parallel links and many calls using up a small bandwidth, the routing may choose some of the links which cannot support the bandwidth which a new call has requested. This is because the bandwidth change due to previous calls was not significant and so routing doesn't know that the link cannot support the requested bandwidth. In such scenarios, the path table update relies on crankback. With many parallel links, the crankback might not update the path table.

Workaround:

The workaround for this problem is to disable the path table and bring it back up.

CSCds61572

Symptom:

When "dsplns" or "dspln" is executed, there is a "?" in the Frame Scramble field. The line does not come out of alarm by adding physical loopback on back card or terminal loopback with "addlnloop" command. Resetting card does not get rid of problem. "dspcds" on PXM shows "Active-F" for the slot.

Condition:

This is seen with 2.0(92)A1 sanity label build. It does not happen with earlier build. At some point, "addlnloop" or "dellnloop" has been executed with this label software, after which the Frame Scramble field becomes a "?".

Workaround:

Do not use "addlnloop" or "dellnloop" commands with this build.

CSCds62686

Symptoms:

Some of the ports are in Building VC state after one of the service module cards are reset.

Conditions:

After one of the AXSM cards are reset or reloaded, then the ports may go into Building VC state and never recover.

Workaround:

Reset the card on the switch (AXSM) again.

CSCds63119

Symptom:

When SHM could not update its database to standby PXM, SHM just logs an error. It should reset standby PXM to recover.

Conditions:

N/A

Workaround:

NONE

Further Problem Description:

NONE

CSCds72181

Symptoms:

1) when the active PXM powers up, it stays at the pxm45> prompt with an error message printed saying SHM_BRAM_VER_MISMATCH.

Conditions:

1) The above problem will occur under the following scenario:

a) move a PXM-45 card that is running Release 2.1 or greater to a node running release 2.0.11.0 or less

b) insert this card as a standby card in the release 2.0 node

c) when the card becomes standby, make this new standby card the active PXM card in the node.

d) sometimes in the future, reset the node with new active PXM in it.

e) This new active PXM will fail to come up as the active card afterward. It can only be brought up as a standby card only.

or

2) Performing an abortrev or setrev from release 2.1 to 2.0 on the PXM slot on a node can cause the above problem.

or

3) Performing a loadrev/runrev from release 2.0+ to 2.1+ using the standby PXM that was previously already running release 2.1. The database will not be upgraded from release 2.0 to 2.1 when a 2.1 PXM card is inserted as a standby card into this 2.0 node.

Workaround:

1) avoid moving PXM-45 cards that are running different software releases (2.0 versus 2.1).

S3 Bugs

CSCdr45241

Symptom:

Selecting the front card for testing based in the command syntax given by diagnostics produced an "Invalid syntax" message.

Condition:

Selecting the front card for testing.

Workaround:

None

CSCdr45875

Symptom:

Even with "pagemode off" in effect some CLI command output still pause in the middle with the prompt "Press <CR> to continue, Q<CR> to quit:"

Condition: An off-by-one error in scanning of output caused an inadvertent miss of the Continuation string. This caused the output to be incorrectly halted waiting for user input.

Workaround:

There is no known work around. It is necessary to enter a <CR> in order to continue output. This will allow the output to complete or until the off-by-one error case is once again encountered.

CSCdr86751

Symptom:

AXSM card does not detect loss of cell delineation (LOCD), therefore not generating RDI as a result.

Condition:

Line signal with LOCD is injected into AXSM card.

Workaround:

No workaround.

CSCdr91962

Symptom:

No mechanism to clear a portion of a node's configuration.

Conditions:

PXM will full configuration including ports, lines and connections. No mechanism to clear provisioning config without also clearing shelf config

Workaround:

None. New mechanism needs to be supported. New command will be clrcnf.

CSCdr95809

Symptom:

When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name.

Condition:

Service affecting command such as switchcc, resetsys, resetcd display the confirmation prompt.

Workaround:

Avoid using command abbreviations.

CSCds05064

Symptom:

Revereved BC(Back Card) alarm missing alarm persists.

Condition:

Even when the cards have been unreserved.

Workaround:

Do shmAlarmUpdate on the for the slot.

CSCds05178

Symptom:

Under certain situations, the restoreallcnf may fail and the node's configuration is not restored.

Conditions:

In a node with both PXMs inserted, if the user performs a restoreallcnf of a database that was saved using a different S/W version, the restoreallcnf may not be successful.

Example:

DB Configuration saved with saveallcnf while the active PXM is running S/W version 2.0.1.0.The PXM F/W is then upgraded and is now running 2.0.2.0. The user then perform a restoreallcnf of the database that was saved from 2.0.1.0.

Workaround:

Remove the standby PXM from the node, then perform the above restoration.

CSCds12357

Symptom:

pnCcb takes too much (75-85%) CPU time

Condition:

When nni ports are brought down in a network with 50K routed connections.

Workaround:

None

CSCds13955

Symptoms:

The dspcds, dspcd and dspcdalms do not show the same alarm information.

Conditions:

Alarms reported on an AXSM card is not integrated into the dspcd and dspcds command.

Workaround:

Use dspndalms to find out the different alarms reported under the different categories.

Use the dspcdalms command to show alarms reported under "Alarms From Cards" category.

Use the dspcd/dspcds commands to show alarms reported under "Shelf Slot Alarms" category by the dspndalms command.

In this version of the Software, the above dspcdalms/dspcd/dspcds commands do not show the combined alarm state from

"Alarms From Cards" and "Shelf Slot Alarms".

CSCds15147

Symptom:

The connection summary information displayed by command dsppnport wraps after 80 columns (the output exceeds 80 columns).

Condition:

None.

Workaround:

None.

CSCds16241

Symptom:

output from CLI command dsptasks scrolls off screen

Condition:

Always

Workaround:

None

CSCds16452

Symptom:

dspnodalcongth/cnfnodalcongth: some keyword does not match. The threshold names in these commands were different. For consistency and documentation purpose, the threshold names were made same.

Condition:

None

Work Around:

None

CSCds17195

Symptom:

dsppncon command displays SCR and MBS values for CBR and UBR calls.

Condition:

When CBR and UBR SPVC or SPVP are added, dspcon is not displaying SCR and MBS value where as dsppncon is displaying the same.

Workaround:

None

CSCds17592

Symptom:

Configuration commands

cnfspvcprfx cnfilmienable cnfnodalcongth cnfabrtparmdft cnfrrtparm execution is allowed on standby card.

Condition:

Command Descriptor table of ccb showing ANYSTATE for the above commands.

Workaround:

None

CSCds21295

Symptom:

dsplog -task dbClnt will show error sometimes during switchcc of two MGX 8850 PXM cards.

Condition: happen during switchcc

Workaround:

none

CSCds21451

Symptom:

User is allowed to add feeder on a VNNI trunk.

Conditions:

The above should not be allowed since this is not a valid configuration. CLI should be blocked. A feeder should be added only on a physical interface.

Workaround:

Do not add feeder on a VNNI trunk.

CSCds26368

Symptom:

AXSM card remains in Init state.

Conditions:

When AXSM card is reset, AXSM card remained in INIT state with the following error message:

EmTask - emInitFeeder fails for feeder x because ILMI is enabled.

This occurs if ILMI is enabled on an interface and feeder is added on another interface on the same AXSM card.

Work Around:

Do not enable ILMI on the same AXSM card if feeder is added on that card.

CSCds26640

Symptoms:

cannot configure the clock sources.

Conditions:

During ncdp resync.

Workaround:

1. Go to ShellConn. 2. ncdpResetNcdpState

CSCds27986

Symptom:

When "dspapsln" command is executed using protection line ID as input, the working line ID is same as protection line.

Condition:

No special condition.

Workaround:

Use "dspapsln" with working line ID to find out protection line ID.

CSCds31066

Symptom:

Risky commands such as shutdisk are available and are not needed.

Condition: Users with cisco access level can access these commands.

Workaround:

Avoid using commands, shutdisk and format.

CSCds31146

Symptom:

No mechanism to display current community string value.

Conditions:

Issue cnfsnmp command. Display shows garbage instead of valid community string.

Workaround:

None.

CSCds32730

Symptom:

Programming the backplane NOVRAM on an MGX 8950 backplane fails with a write error.

Condition:

ATMEL AT93C66 parts are installed on the MGX 8950 backplane.

Workaround:

None

CSCds33798

Symptom:

On a resetsys, the event was not logged indicating the command and username.

Condition:

Enough activity on the system so the lower priority CLI did not run before the system was reset.

Workaround:

None

CSCds33824

Symptom:

Currently when we try to delete clock, it is an implicit set. This will take longer for the clock manager to re-lock the clock source.

Condition:

When user try to use the command "delclksrc" on PXM-45, the implicit set clock will happen.

Workaround:

Don't use the "delclksrc" to del clock source. The new fix will only delete the clock source. It will not try to re-lock the clock.

CSCds34234

Symptom:

When PNNI controller sends a msg which is not recognized by the slave, we send a general Response error msg to the controller. Within the response msg, there is slaveCode which VSI Slave copy the msg header sent. Since the Msg header contains LLC-SNAP header, so VSI Slave copy that as well. But PNNI controller don't interpret SNAP Header.

Condition:

PNNI controller could send a msg which is not supported on VSI SLave.

Workaround:

Make sure that the msg is supported by Slave, if not, the VSI master might not be able to handle the response probably.

CSCds34340

Symptoms:

When you give incorrect value for the line option, it complains about incorrect value for the following option instead. There is no destructive effect of this error.

Condition:

Happens when you do "cnfapsln" command with incorrect value for working line.

Workaround:

There is no workaround.

CSCds35712

Symptom:

PNNI link is in attempt state.

Conditions:

After Y red switchover.

WorkAround:

None

CSCds37762

Symptom:

After executing addlnloop command on axsm card - the event is not recorded in event log.

Condition: Executing addlnloop command.

Workaround:

None.

CSCds40637

Symptom:

SNMP responses and SNMP traps being sent out the incorrect network interface.

Conditions:

Node is being managed by only one CWM or has only one trap manager. During operation, the network interface being used for connectivity is changed.

Workaround:

For traps, create a second trap manager.

CSCds43543

Symptom:

When a switchcc is executed, the following messages appear on the console port of the PXM that transitions from standby to active:

go_active, sync_flag=1 SPVC transiting from Standby to Active

Condition:

None

Workaround:

None

CSCds43550

Symptom:

Pop up messages were seen during configuration of SPVC with cnfcon command

Install has both Legs A(1011801,13,102) and (10c1801,0,42)Configuration successful

Condition:

When trace mod PNNET 1 1 is enabled on the node for debugging purpose, above pop up messages use to appear on the screen

Workaround:

Moved the corresponding debug statement to be seen only when CM debug is enabled.

CSCds44287

Symptom:

No particular symptom. AXSM Diagnostic may cease to run.

Condition:

When some error triggers AXSM diagnostic to print out error traces.

Workaround:

Disable AXSM Diagnostic task traces.

CSCds48531

Symptom:

This was noticed in a customer beta trial. The dspcons on AXSM does not show any alarm. However the dspcdalm <slot> on the PXM-45 would display chan alarms for that particular slot. This would translate to a node level alarm in the system;

Solution:

Clearing of card level alarms were not being synchronous with the clearing of channel alarms. This was the cause of mismatch.

Workaround:

Rebooting of the AXSM card will clear the alarms.

CSCds48589

Symptom:

Multiple switchred can trigger XBAR remap twice error. The error is also reported to alarm manager. "Card Crossbar" major alarm will be registered.

Condition:

The problem is intermittent. It is rarely observed. The experiment indicates that the spurious errors can be generated when programming XBAR ASIC even though XBAR remap configuration is correct.

WorkAround:

None

CSCds49105

Symptom:

Taking the standby PXM from one node and placing into the standby of another node can cause the LAN interface of the old node to become disabled.

Conditions:

On a node with redundant PXMs, the boot IP and disk IP addresses for the LAN are the same.

Workaround:

Pull ethernet cable when switching cards between nodes.

CSCds51524

Symptom:

The different values of K1 when doing switchred and when removing cards is cleared when the redundant card comes up.

Condition:

This condition is created by the inconsistent values transmitted on K1.

WorkAround:

A higher priority command such as lockout of protection of forced switch might clear this condition.

CSCds51688

Symptom:

dspcdalms shows alarms for a card in a particular slot (reported by the card) and dspslotalms shows alarms for the slot reported by the shelfmanager.

Condition:

dspcdalms and dspslotalms show different alarms for the same card.

Workaround:

In order to view alarms for a particular slot, dspcdalms and dspslotalms CLIs need to be used.

CSCds57341

Symptom:

Axsm may consider Multiple Bit error as One Bit error(CRC-8 is not sufficient to detect/correct One bit error) and tries to correct that. So it will come up with wrong VPI/VCI. If VPI/VCI are configured then data will be sent to the wrong destination. If VPI/VCI is not configured, dsplncnt will show invalid VPI/VCI.

Condition:

In the device configuration HEC is enabled to detect and correct one bit error.

Workaround:

Now HEC is disabled in device configuration. If problem persists then do the following at DIP, if available dad write 0x60= 5

Problems Fixed in Release 2.0.10

Bug ID

Description

S1 Bugs

CSCdr70591

The SRCV task in AXSM gets an address exception.

CSCdr74831

Receive 60905 or 60904 trap as soon as CWM requests for a config upload file.

CSCdr87841

Vsi master fails to recover on trying to commit a connection on an existing vpi/vci.

CSCdr88211

PXM-45 fails to send config message to slave.

CSCdr89807

Configure an address filter and associate it with a port. Do not have any addresses added to the filter. Make incoming and outgoing svc/spvc calls through the port. System may restart.

CSCdr99509

SNMP MIB Walk fails even though the cards are in active state.

CSCds01070

CWM did not receive trap 60901 to let CWM know that File creation has been started.

CSCds03375

Cpro shows status indicating AIS state when no AIS state exists.

CSCds05585

When addpart or and "set partition" type command is executed for VT (VNNI) ports, AXSM card gets SW exception and resets.

CSCds07804

The problem is an unexpected system reload.

CSCds09032

When connection reroute is triggered from CWM, the operation would fail

CSCds09374

When pulling out an active AXSM, PXM goes into reset

CSCds24374

The card goes to Failed state after 3 SW/HW error resets, with reason SHM_CDF_MAX_RESETS_REACHED. These three resets have to be within a period of 100 hours.

S2 Bugs

CSCdp73120

When adding asymmetric connections, meaning local traffic parameters are different from remote traffic parameters, AXSM card doesn't handle it correctly. Inconsistent traffic load info will be seem be doing dsppnportrsrc.

CSCdr50497

dspsct command does not display proper information.

CSCdr71440

Currently, if a SHM/CTC message protocol timeout occur, only an error is logged. The card will eventually be reset. The timeout for this may be up to 1.5 hours. If the protocol error occurred during a node power up against an AXSM card, the AXSM will be stuck in the INIT state; in addition, the STANDBY PXM card may be affected by this, and may get stuck in the INIT state also.

CScdr74604

On one of the nodes in a devtest network, a few connections were reporting an egress AIS alarm even though the connection was perfectly passing traffic. This gave a false impression of failure to the user.

CSCdr74850

Trap managers don't see any trap for PXMs switch over.

CSCdr75239

During the powering up of a standby PXM, the disk is marked "disk not ready" temporarily while the disk sync is being performed. During this time, the Disk Not Ready alarm is reported under the slot alarm category. There is also an alarm category called disk alarms which is not being utilized at the moment. Thus the disk alarms count is shown as zero.

CSCdr75434

Some SPVCs will appear as failed even though the connections are active

CSCdr77408

uni or nni port state goes up and down intermittently.

CSCdr77525

To reproduce this problem,

1. add a partition, and pxm cli> cnfpnportcac port-id cbr -minbw 50 axsm sh> rmPartDtlInfoShow.

2. axsm cli> cnfpart.... -emin 100000

3. axsm sh>rmPartDtlInfoShow will shows the interface policy info in each cos has been reset to wrong values.

CSCdr82076

dspcdalms command does not break after 24 lines to give user an option to either continue display or quit.

CSCdr85279

SVC connection is constantly torn down and rebuilt. This causes intermittent outages between node and CWM.

CSCdr86184

Applications complaining about IPC message allocation failures due to IPC message leak.

CSCdr86324

Standby card will be waiting in Init state

CSCdr86680

Event log entries indicating IPCONN could not send message to vcid 0.

CSCdr89700

When dspswalms/dspslotalms commands are used to display alarms, displays are inconsistent when there are alarms present compared to when they aren't present.

CSCdr90786

When a Primary Clock Source is intentionally deleted with the delclksrc command a clock alarm is reported by the dspndalms and the dspclkalms command that states that the Primary clock source is lost.

CSCdr91277

A redundancy-deleted trap is sent with secondary slot number set to zero.

CSCdr93427

The Cross bar status displayed by the command dspxbarstatus does not reflect the correct status.

CSCdr93676

getone on an instance of caviStatEgressTable object does not return the value.

CSCdr94049

The message "Function ssiTaskDelay called by ISR." may appear in the dsplog output.

CSCdr94469

Message Of IPC Allocation failure seen on the console

CSCdr94654

Event log messages are not generated.

CSCdr96243

After about 75 (out of the 100) ports issued the above error message, PXM would temporarily lock up (for about 40 sec) and then continue.

CSCdr97659

For a Service Module that supports master agent/subagent agent architecture, its subagent MIBs need to be un-registered from the master agent when it is removed, reset, failed, switchredcc, etc. Otherwise, MIB walk will hang/timeout since the master agent sees the registered subagent MIBs and continue to send requests to a Service Module that may be physically removed, failed, or rebooted/reset and did not come back up successfully.

CSCdr97665

Failure condition for addred/delred from CWM will always indicate a general error.

CSCdr99149

Frame discard field comes as 0 when it is disabled. It should be 2.

CSCds01843

Link goes down and up when ilmi is enabled in IISP

CSCds02379

After a setrev or a soft reset, a NOVRAM will be corrupted. The specific symptom is a failure of the checksum verification.

CSCds03654

When the networking controller NAKs a connection provisioning request (due to lack of resources/invalid parameters), the proper error string is not presented to the user. This happens only when using the CWM.

CSCds03787

User can't modify cdvt of slave endpoint of dax con. Also, in the case of MGX 8850 node, when user modifies cdvt of master endpoint of dax con, the slave endpoint then is assigned cdvt = -1.

CSCds03927

setrev causes a card reset regardless of card state when the command is issued at the CLI prompt. Card will become unusable during the burnboot since the flash is corrupted.

CSCds03954

When user enters the command "dspvsicons -cksm 0" the CLI task would take an exception.

CSCds04883

The trap oid for cwIfIndex is wrong.

CSCds05071

MIB Requests(Get,Set, Get-next) comeback with NO SUCH INSTANCE error.

CSCds06500

1. When adding signalling channel, ingress ecr is not calculated.

2. After change booking factor, only ingress card load changes, ingress part load stay the same.

CSCds07835

OC12 card result in wrong cell delineation because of the wrong C2 byte configuration.

CSCds09194

If tstdelay is not successful for a given connection, then all subsequent attempts for performing tstdelay on that connection will fail with the reason "test in progress".

CSCds09375

When pulling out an active AXSM, PXM goes into reset

CSCds10319

There was buffer overflow in one of trace msgs. if the attachment point change doesn't happen, then ilmiTask will be fine. The ilmiTask fails only when it tries to print an error message.

CSCds10564

When connections enter into "mismatch" state on the AXSM, alarm traps are generated to the CWM to indicate this. Also an alarm file on the card should be updated to indicate this failure condition. This did not happen.

CSCds11187

Operational status of Protection line is not displayed correctly

CSCds13606

SSI event logged as EVENT_ERROR with stack trace of event.

CSCds13978

dspcd and dspcds show a card is in failed state but no alarm is raised.

CSCds14777

Update port sig parameters when the port status is up, it will cause the inconsistence in information display between the dsppnport and dsppnportsig.

CSCds16773

Standby PXM-45 fails to come up after a PXM switchover or new Standby PXM-45 insertion.

CSCds18258

Some connections are not able to reroute, reroute is not even being attempted; i.e. connections are not routed.

CSCds19129

Calls with AAL parameter IE octet 12.1 (i.e. partially filled cells method) set to 0 are rejected.

CSCds22540

When performing SPVC reroute and switchover the UNI (master side) at the same time, connection delete may fail on the standby. After switchover, if the same connection is recommitted, VSIErr will be observed on the AXSM console.

CSCds22868

Provision spvcs through an IISP link. On repeated setup and release of spvcs, it was noticed that the user side IISP had some connection data structures which were not getting cleared when the call was released.

Problems Fixed in Release 2.0.02

Bug ID

Description

S1 Bugs

CSCdr22185

VsiErr message with a string explaining the error such as "Interslave timeout" and others get displayed; these messages are indications of a recoverable condition and are not meant to be displayed.

CSCdr23168

Resetting the AXSM UNI card in the edge node while the PNNI is establishing connections on it might intermittently cause the tVsiSlave task to crash on the AXSM UNI when it eventually comes up.

CSCdr27919

Performing PXM-45 switchover while derouting 25k SPVCs by downing one of the nni port in the edge node might intermittently cause a lot of vsierrs (0xcoo3, 0x5011...etc) to be displayed on the corresponding UNI AXSM on the same node, and may even cause its tVsiSlave task to stop working which may results system reload.

CSCdr34387

A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost.

CSCdr36772

Bucket statistics file name has incorrect file name.

CSCdr36954

VC Failure due to insufficient LCNs used up by the user conns. The port stays in VC failure forever.

CSCdr37025

Some of the provisioning command operation does not get reflected on standby and disk.

CSCdr37302

Unable to ping/telnet to the node intermittently.

CSCdr38809

After restoring the configuration using restoreallcnf command, and controller card switchover happened, the some of the SPVC end points may be missing and/or the attributes of some of the VCs may be changed.

CSCdr39120

Reset of AXSM cards and switchover will cause SPVC to reroute.

CSCdr40126

If there are more than 31K connections on a single AXSM in a VIA node, the connections on the AXSM are not deleted when PNNI deroute the connection.

CSCdr40620

NO SPVCS. After PXM rebuild some interfaces might disappear.

WITH SPVCS Every time PXM card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception.

CSCdr43586

'ssiIpcMessageAllocate fails' appears on screen periodically.

CSCdr43665

The call does not routing with VPI/VCI assignment error.

CSCdr45695

Could not run "dspln", dspports, etc. Could not walk mib tables.

CSCdr46104

Exception in pnCcb task causing the active processor to reset.

CSCdr47782

Standby PXM reloads

CSCdr47834

Connection add / delete problems when number or connections is around

30,000+. Possible error message includes, delete failure, non-existing ConnID entry.

CSCdr47947

After resetting the AXSM (UNI) card in endnode, and performed PXM45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed.

CSCdr50312

Standby card will be reset and come back in the higher revision (2.0(1)). The card will then transition to the failed state.

CSCdr55652

provision the SPVC, the conn is ok but the cell dropped.

CSCdr56267

Standby PXM-45 waits indefinitely in INIT state.

CSCdr61082

The applications on Active PXM-45 fail to communicate with other applications on the same card and other cards due to lack of IPC message buffers.

CSCdr61204

dspcds will show that the card is in the BOOT state.

CSCdr67620

Intermittently, AXSM cards will get reset due to MCAST_MSG_LOSS.

CSCdr71695

Node and card redundancy configuration is lost.

CSCdr73806

dspcds and many other CLI commands will not work.

CSCdr75500

SPVCs will fail to route.

CScdr78831

After clrallcnf, access to the node via TCP/IP makes connection to the standby card rather than the active.

CSCdr80279

When a VPC connection is added a connection add trap is sent to the CWM. In this trap a MIB object cwaChanVpcFlag is set to indicate if the connection is a VPC or a VCC. This was erroneously set to indicate VCC instead of a VPC.

CSCdr80807

System restarts.

CSCdr82611

When a large number of endpoints are provisioned and if all of them had stats collection enabled, then it is impossible to login or cc to the AXSM card.

CSCdr82868

IP connectivity cannot be established and remains in SETUP state.

CSCdr85316

IP connectivity setup fails with cause ATM_CAUSE_VPCI_UNAVAIL (35).

CSCdr87319

PNNI Link might occasionally go down or remain in oneWayInside/Attempt state. Connections may reroute on any other available trunk or stay derouted in case no other trunk is available.

S2 Bugs

CSCdr25037

Many [vsierr] messages and [egress ConnID add failure] messages are reported by the trunk card on NODE_EP1 while the rebooted UNI card does NOT have error messages.

CSCdr27033

Clock source does not revert back to primary bits clock when revertive mode enabled. This can also appear in the form that clock is not switched to a valid clock source that should have a good clock signal.

What is really the case is that the clock source has been previously declared as unusable/unlockable by the clock source manager. This clock source will not be chosen again until after clock source reconfiguration.

CSCdr27718

The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.

CSCdr28033

When performing dnpnport on a certain ports with SPVC connections which has stats enabled, some dal/stats error are observed on the UNI AXSM side.

CSCdr28767

The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.

CSCdr29013

Much lower via node reroute rate when attempting to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value.

CSCdr32624

Any operation involved in file creation or file opening on the Active controller card will start failing continuously.

CSCdr34225

Cell drops are noticed on OC3 with default line rate.

CSCdr34707

Calls will not go through.

CSCdr34851

After addpart with incorrect parameters, the partition gets added on AXSM, but dsppnports on PXM-45 either doesn't show the port, or it shows the IF status as provisioning.

After delpart, dsppnports shows the IF status up for the port on the PXM-45, although dspparts on the AXSM doesn't show the partition anymore. There is no error message displayed.

CSCdr36903

ILMI fails to transition to a steady state and PNNI ports may not come up. As a calls might fail to route or use another available heathy trunk.

CSCdr39329

Few connections will be in fail state at one end point (either master end or slave end)

CSCdr39684

Cannot display link selection configured on PNNI port.

CSCdr39892

The symptoms of this problem is that all traffic that is coming into the axsm card is being discarded. Specifically, ingress traffic does not go into the switch planes and since the queues in the QE48 gets full, the incoming traffic reaches the maximum cell threshold and all cells are discarded.

CSCdr40167

User see sometimes SPVC fail to route spvc connection on AXSM card resets

CSCdr40333

User did not have the granularity to find out why the clock when bad.

CSCdr40484

User did not have the granularity to find out why the clock when bad.

CSCdr40821

Some SPVC conns are in AIS-FAIL in standby

CSCdr41012

Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections.

CSCdr41170

After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM.

CSCdr41708

After the switchover, the new active Pxm still shows that the above inserted back cardback card is still missing. This will eventually cause an extra switchover when a healthier standby Pxm is ready.

CSCdr42075

port(s) in "vc failure"

CSCdr43945

One can exceed the peak cell rate up to line rate thereby starving all resources to other connections. This is due to the fact that OAM and RM cells do not get policed.

CSCdr44255

Svc call on uni port getting released.

CSCdr44537

The connection does not pass the data traffic.

CSCdr44566

Dax connections are in FAIL state

CSCdr44741

An unsupported card will stay in the Boot state, and the standby Pxm will stay in the Init state.

CSCdr45063

The address or address prefix associated with a PNNI node at a lowest level peer group, if not summarized by any of the default or configured summary address, may sometimes be failed to be advertised across the peer group boundary even when its advertising scope is wide enough.

CSCdr45896

The problem is not observable, but the problem can be identified/observed when the traffic parameters are verified by doing "dalConnParamsShow" after de-routing the connections from one trunk to another on a different card

CSCdr45962

Some SPVC conns are in AIS-FAIL in active PXM after switchover

CSCdr46262

When switchover occurs, all the master / slave endpoints are attempted to route / half commit, and it will hit congestion, which will not recover dspnodalcongflags will show connpendingflg set to TRUE.

CSCdr46770

The clock is marked as unclockable.

CSCdr46945

The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link.

CSCdr47590

After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before.

CSCdr47916

Connection may not be routed on best path.

CSCdr47931

System allows calls to use VPI/VCI below the provisioned minimum value.

CSCdr48075

CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB.

CSCdr49287

Connection resync will be stuck in one place and so connections will be mismatched between controller and slave

CSCdr49592

A user adds a connection without specifying mbs/cdvt, this programs the hardware with values that are shown by dspmbsdft/dspcdvtdft. But when user does "dspcon", the value shown for both mbs/cdvt is -1.

CSCdr50477

The addcontroller command fails.

CSCdr50497

dspsct command does not display proper information.

CSCdr51668

1.switch gives status.14.0000000000000 as the response to

getnext request on netprefix

2.get negative number in ILMI PDUs from HP test

CSCdr52913

While the node is running, a couple of error messages are shown in the log. When Line Failure occurs, it was not identified by an easily understandable message, the line that failed was not printed.

CSCdr53438

cnfchan on slave dax con for cc enable, pnni controller doesn't send vsi msg to SM

CSCdr53470

SPVCs will fail to route.

CSCdr54146

Calls will not get routed through the nodes in the network.

CSCdr54798

When 2 mandatory events were sent to the children at the same time, the RAT only kept the last one.

CSCdr55821

Certain connection will not establish. If you can trace the

signaling message, you'll see the switch received connect and sends status message with cause 100 (invalid IE contents).

CSCdr55832

See the following misleading messages: "+bad length+" and

"Send Status Enquiry"

CSCdr55928

AXSM STM1 card will not handle over 32K connections.

CSCdr56173

SPVP connection(s) are not allowed.

CSCdr56897

Resetting the UNI AXSM on the edge node of a three node network with 50K+ connections may cause the tVsiSlave task cpu utilization to go above 90% for a few seconds after it comes up.

CSCdr57071

Bad IPC messages detected caused by unreported SAR CRC errors.

Unexplained behavior or errors in the shelf.

CSCdr57276

SHM FAILURE ALERT message is displayed on the console

CSCdr58626

See a continuous Trap messages indicating IPC memory leaks.

CSCdr59353

The dspclksrc command shows inaccurate clock information

CSCdr59423

Switchcc results in clk switch to priority 0 msg.

CSCdr59709

No event logs when there is a PXM switchover.

CSCdr60068

If a resetsys or a switchcc is preformed on the PXM, a

core dump would be preformed during the boot of the formerly active PXM card. When the core dump logs are observe the reason would be a device driver error.

CSCdr62126

clralmcnt doesn't clear LOS/LOF alarm counters.

CSCdr63104

dspcdstatus shows "No Alarms" for PXM-45/any inapplicable slots. When slot number is not specified, it defaults to PXM slot.

CSCdr64230

In a multi slave system with combined DAX & routed cons (50K), pnccb task is suspended when reset of the uni-AXSM card is followed by DAX con being modified (committed).

CSCdr64564

When the optional parameter, shelf #, was provided in the CLI commands, the commands fail.

CSCdr65883

If the active PXM's disk is not synced (e.g. not all data on the disk is valid), the node is allowed to come up. This will result in lost of database configuration.

CSCdr66184

DAX Conns are not in AIS when connection is down

CSCdr66781

dspcdalms shows alarms whereas dspcdstatus does not.

CSCdr66802

switchcc generates a syntax error message inappropriately

CSCdr67264

When a connection (which is in alarm) gets cleared of all the alarms, a connActive trap is sent to the CWM. This trap contains a bit map of conn. alarms in a mib object cwaChanAlarmStatus. When all the connection alarms clear this bitmap takes a value of zero. This was not documented in the MIB. Hence the confusion.

CSCdr71350

CLI dsppnni-path displays node name incorrectly

CSCdr72570

Some connections exhibit unexpected behavior such as "cannot resolve passthru".

CSCdr72621

Some connections exhibit unexpected behavior (see related bug CSCdr72621) such as "ERR: Could not resolve passthro id" when "dspcon" is executed on some connections.

CSCdr73169

SNMP MIB Walk or Sending Traps results in failure(Event Log contains this information)

CSCdr73423

When the cnfpasswd command is executed, and the enter key is hit twice, (instead of actually entering in a new password), the password is set to the defaults.

CSCdr75227

dsplns will show "other" for Medium LineType instead of "ShortSMF" etc.

CSCdr76402

Board (e.g. PXM-45) fails to boot and issues a NOVRAM checksum error.

CSCdr78869

Events of type "CHUNKNOTOWNER" are logged in the event log.

CSCdr80772

Log does not report successful switching of clock source.

CSCdr81154

dsppnport does not show active connections after dnpnport on a UNI port.

CSCdr83752

? is taken as the node name and modified the node name to?

Related Documentation

This section lists documentation related to the installation and operation of the MGX 8850 Release 2 switch and associated products in a Cisco WAN switching network. Table 1 lists the product documentation for the MGX 8850 Release 2 switch.

These documents can be ordered or downloaded. Both procedures are described later in this document.

Table 1 MGX 8850 Switch Release 2.1 Related Documentation

Documentation

Description

Cisco MGX 8850 Routing Switch Hardware Installation Guide, Release 2

Provides a detailed description for installing the MGX 8850 switch in a restricted access location.

Cisco MGX 8850 Routing Switch Command Reference, Release 2

Describes and lists the user-accessible command line interface (CLI) for the MGX 8850 switch.

Cisco MGX 8850 Routing Switch Software Configuration Guide, Release 2

Describes how to configure the MGX 8850 switch to operate as an ATM core switch or as an ATM edge switch.

Cisco MGX 8850 Routing Switch Software Release Notes, Release 2

Describes new features and limitations for the software. Maintenance releases are supported with additional release notes.

Additional documentation for the Cisco WAN Manager (CWM) network management system that works with the MGX 8850 Release 2 switch is listed at our web site.Platform-Specific Documents

Obtaining Documentation

The following sections provide sources for obtaining documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following sites:

•http://www.cisco.com (for example, as of this printing, MGX 8850 documentation is located at http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/index.htm)

•http://www-china.cisco.com

•http://www-europe.cisco.com

Documentation CD-ROM

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

Ordering Documentation

Cisco documentation is available in the following ways:

•Registered Cisco Direct Customers can order Cisco Product documentation from the Networking Products MarketPlace:

http://www.cisco.com/cgi-bin/order/order_root.pl

•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/go/subscription

•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).

Documentation Feedback

If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.

You can e-mail your comments to bug-doc@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Attn Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.

Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.

To access Cisco.com, go to the following website:

http://www.cisco.com

Technical Assistance Center

The Cisco Technical Assistance Center (TAC) website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:

http://www.cisco.com/tac

P3 and P4 level problems are defined as follows:

•P3—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

•P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.

To register for Cisco.com, go to the following website:

http://www.cisco.com/register/

If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:

http://www.cisco.com/tac/caseopen

Contacting TAC by Telephone

If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

P1 and P2 level problems are defined as follows:

•P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.

•P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

Service and Support

For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.

Cisco MGX 8800 Series Switches

2.0.13 Release Notes for MGX 8850

Hierarchical Navigation

Downloads

Table Of Contents

Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.13

Contents

Introduction

System Requirements

Hardware Supported

AXSM Cards

Line Interfaces for the AXSM Cards

ATM Layer Information

Network Management Features

PXM-45 Cards

Reliability, Availability and Serviceability Features

PXM-45 Card Information

PNNI

Software Compatibility

Compatibility Matrix

Release 2.0.13 System Content

Switch Software and Boot Codes

Additional Deliverables for Release 2.0.13

SNMP MIB

Upgrading to a New Software Release

Upgrade Procedure

Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Redundant Systems)

Upgrading the Boot and Runtime Images from 2.0.12 to 2.0.13 (Non-Redundant Systems)

Upgrading the Boot and Runtime Images from 2.0.11 to 2.0.13 (with No Interface Policy Changes) [Redundant Systems]

Upgrade Procedure for Non-Redundant (PXM-45) Systems

Upgrading theBoot and Runtime Images from 2.0.11 to 2.0.13 (with Interface Policy Changes)

New and Changed Information

New CLI Commands

Changed CLI Commands

New Features in Release 2.0.13

Obsoleted Features in Release 2.0.13:

Installation Notes and Cautions

Limitations and Restrictions

Important Notes

APS Status Information

Recommendations

Caveats

Known Anomolies in Release 2.0.13

Problems Fixed in Release 2.0.13

Known Anomalies from Previous Releases

Problems Fixed in Release 2.0.12

Problems Fixed in Release 2.0.11

Problems Fixed in Release 2.0.10

Problems Fixed in Release 2.0.02

Related Documentation

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Contacting TAC by Using the Cisco TAC Website

Contacting TAC by Telephone

Service and Support