Cisco MGX 8800 Series Switches

2.0.16 Release Notes for MGX 8850


Table Of Contents

Release Notes for Cisco MGX 8850 Software Release 2.0.16



PNNI Features in Release 2.0.16

System Requirements

Hardware Supported

AXSM Cards

PXM45 Cards

Compatibility Matrix

Release 2.0.16 System Content

Additional Deliverables for Release 2.0.16

Upgrading to a New Software Release

Upgrading PXM45 Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15

Upgrading AXSM Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15

New and Changed Information

New CLI Commands

Changed CLI Commands











New Features in Release 2.0.16

Obsoleted Features in Release 2.0.16

Installation Notes and Cautions

Limitations and Restrictions

Important Notes

BITS Clock Source Configuration

APS Management Information


Documentation Correction — Feeder Configuration

Known Anomalies in This Release

Problems Fixed in Release 2.0.16

Problems Fixed in Release 2.0.15

Known Anomalies found In Previous Releases

Problems Fixed in Release 2.0.14

Problems Fixed in Release 2.0.13

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

Technical Assistance Center

Contacting TAC by Using the Cisco TAC Website

Contacting TAC by Telephone

Service and Support

Release Notes for Cisco MGX 8850 Software Release 2.0.16



These release notes describe the PNNI features, system requirements, upgrade procedures, command Line Interface (CLI) changes, and limitations that apply to Release 2.0.16. These notes also contain Cisco support information. Follow-on releases are planned to add new features, and can be found in the Marketing Road Map.

PNNI Features in Release 2.0.16

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

System Requirements

This section describes the hardware supported in this release and the software compatibility requirements.

Hardware Supported

The following table lists supported hardware for Release 2.0.16:

800 Part Number


























































AXSM Cards

The AXSM card is a double-height ATM service module that is compatible with release 2.0 and later PXM45 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 PXM45 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 on the BPX, the UXM card on the IGX, and the AUSM card of the MGX 8850 Release 1. Other Cisco ATM platforms and other ATM manufacturers' equipment have proven to be compatible.

Line Interfaces for the AXSM Cards

The AXSM cards supported in this release can provide the following types of line interfaces:


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

G.703/Accunet Conformance


G.703/GR-253 Conformance

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

MMF, SMF intermediate and long reach

4 port Electrical back card


G.703/GR-253 Conformance

2 optical ports per back card, 2 back cards per double height slot

SMF intermediate and long reach


G.703/GR-253 Conformance

Single optical port back card, one back card per double height slot

SMF Short, long and extra-long reach

ATM Layer Information

The AXSM cards supported in this release provide the following ATM features:

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

The AXSM cards supported in this release provide the following 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.

PXM45 Cards

The PXM45 card is a 45-Gbps processor switch module. The architecture of the PXM45 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 PXM45 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 PXM45 card is designed to operate with another PXM45 card in a redundant configuration. There are two dedicated slots in the MGX 8850 (double height slots 7 and 8) that house the PXM45 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 PXM45 cards in a system. This was calculated at greater than 100,000 hours.

Compatibility Matrix

The following compatibility matrix lists the software that is compatible for use in a switch running Release 2.0.16 software.

Board Pair
Boot Software
Boot Software
Runtime Software

PXM45, PXM45/B















Cisco MGX 8850 Release 2.0.16 interoperates with CWM 10.4.01.

Cisco MGX 8850 Release 2.0.16 supports feeder connections from Cisco MGX 8850 Release 1.1.34. Please see the 1.1.34 Release Notes for feeder feature issues.

Cisco MGX 8850 Release 2.0.16 operates with CiscoView 5.2 (package 3.44).

Release 2.0.16 System Content

The following software files are supplied with the 2.0.16 release:

Boot software



Runtime software



Additional Deliverables for Release 2.0.16

The SNMP MIB for this release is mibs2014.

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 describes the installation of software Release 2.0.12 and higher.

Tips Before upgrading, turn off PXM45 online diagnostics. There was a problem (CSCdt46582) where the AXSM card reset during a switchcc. This problem has been fixed with Release 2.0.15.

Note Note, after upgrading from 2.0.14, customers may notice channel alarms (mismatch of the connections for a few connections up to about 200 connections. Also, the customers may see a traffic drop on the same connections. This may last for 15 to 30 minutes depending upon the number of channel alarms. This problem has been fixed with the 2.0.15 release.

Note In this release, you can upgrade the boot or runtime software on only one AXSM card at a time. (See CSCdt51884) For example, you cannot start a burnboot command on one AXSM card if the burnboot command is still operating on another AXSM card.

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

Step 1 PXM45 boot software

Step 2 PXM45 runtime software

Step 3 AXSM boot software

Step 4 AXSM runtime software

The following sections describe how to upgrade PXM45 and AXSM cards.

Upgrading PXM45 Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15

The following procedure is for redundant PXM45 cards.

Step 1 Copy files to the switch.

Step 2 On the standby card, type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command. This will reboot the standby card

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.015.002_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 Standby/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 Release 2.0.15 software on the standby card (this command is executed on the active PXM45 card):

loadrev <slot number> <version>

For example: loadrev 7 2.0(15.2)

Step 9 After the standby card comes back up with the new image in the Standby/Active state, use the runrev command to load the Release 2.0.15 software 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(15.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. Once commitrev is issued, abortrev is no longer valid. Note, you should issue the commitrev before provisioning any more connections.

commitrev <slot number> <version>

For example: commitrev 8 2.0(15.2)

The following procedure is for non-redundant PXM45 cards.

Step 1 Copy files to the switch.

Step 2 On the PXM45 card, type sh to go to the shellconn.

Step 3 Issue the sysBackupBoot command. This will reboot the standby card

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.015.002_bt.fw"
- enter "y" to confirm

Step 6 Reset the card by issuing the reboot command. Wait until the card goes to the Active state.

Step 7 Use the loadrev, runrev, and commitrev commands to load the Release 2.0.15 software on the card. Once commitrev is issued, abortrev is no longer valid. Note, you should issue the commitrev before provisioning any more connections

loadrev 7 2.0(15.2)
runrev 7 2.0(15.2) 
commitrev 7 2.0(15.2)

Upgrading AXSM Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15

The following procedure is for redundant AXSM cards.

Step 1 Copy files to the switch.

Step 2 To upgrade the AXSM boot code, issue the burnboot command on the standby AXSM. For example:

burnboot <AXSM slot> 2.0(15)

Step 3 Issue switchredcd command.

Step 4 Upgrade the AXSM boot code on the new STANDBY card.

burnboot <AXSM slot> 2.0(15)

Step 5 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(15.2)

Step 6 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(15.2)

Step 7 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.

For example: commitrev <AXSM slot> 2.0(15.2)

Repeat these steps for all redundant AXSM cards.

The following procedure is for non-redundant AXSM cards.

Step 1 Copy files to the switch.

Step 2 To upgrade the AXSM boot code, issue the burnboot command. For example:

burnboot <AXSM slot> 2.0(15)

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

For example:

loadrev <AXSM slot> 2.0(15.2)
runrev <AXSM slot> 2.0(15.2) 
commitrev <AXSM slot> 2.0(15.2)

Repeat these steps for all non-redundant AXSM cards.

New and Changed Information

This section describes new and changed commands since the 2.0.12 release.

New CLI Commands

The following new CLI commands have been added since the 2.0.12 release:

dsppathtracenode, which displays the configuration created with pathtracenode

dsppathtraceport, which displays the configuration created with pathtraceport

dsppathtraceie, which displays the configuration created with pathtraceie

Changed CLI Commands

The following sections describe CLI commands that have changed in this release.


The addcon error message that appears when provisioning an SPVC to use a previously configured (duplicate) vpi and vci has been changed from "ERROR: No Such Connection endpoint present" to "ERROR: Specified vpi/vci not available."


The clrxbaralms command has been removed. It is a duplicate of clrxbaralm.


The dspalm command has been modified to display an additional row of alarm information. For example:

APS Alarm State: Major 

The Alarm State will be same as that shown for dsplns. For non-APS lines, the alarm state is "N/A" The rest of the Alarm values shown apply to the 'Active Line'.


The display for the dspalms commands is similar dspalm.


The dspapsln command needs to be entered with both the WLineID and the PLineId. The 'Alarm' shown is not an integrated alarm but is for the LineId that was entered. The 'Alarm' will now show the following are the alarm levels:

SF-L: signal fail low

SF-H: Signal fail High

SD-L: signal degrade low

SD-H: signal degrade High

PSBF: Protection Switch Byte Failure

MIS: Directional mismatch, architecture mismatch, or Channel mismatch (Note that although this is configuration mismatch. APS should still function properly)

OK: No Alarm

The Alarm states shown are independent of the APS line 'cross.'

Note During an AXSM card switch over, there might be a brief period during which MIS is reported. This means the APS operation has gone to 1+1 unidirection mode temporarily.


The dspapslns command previously reported two alarm states: OK and ALM. This command now shows the same alarm levels as the updated dspapsln command. The alarms shown are independent of the APS line 'cross.'


The dspln command displays an 'Alarm' column that shows the integrated alarm status for the APS line pair. It only shows line level alarms. The possible levels are:

Critical -- If Active line is in Alarm

Major -- If non-active line is in Alarm

None -- If both lines are free of line level alarms

N/A -- If there is no APS configuration on this line


The dsplns command displays the same alarm status as dspln.


The dspxbaralms command has been removed. It is a duplicate of dspxbaralm.


The saveallcnf command response has changed to the following:

Unknown.7.PXM.a > saveallcnf -v
The 'saveallcnf' command can be time-consuming. The shelf 
must not provision new circuits while this command is running.
Do not run this command unless the shelf configuration is stable 
or you risk corrupting the saved configuration file.
The save command will only store the 
2 most recent saved files in C:/CNF directory. 
If you have 2 or more files already saved in C:/CNF, 
the older ones will be deleted by the current save, 
keeping the 2 most recent.
saveallcnf: Do you want to proceed (Yes/No)? y

New Features in Release 2.0.16

There are no new features in this release.

Obsoleted Features in Release 2.0.16

No features are obsoleted in this release.

Installation Notes and Cautions

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

(CSCdt05425) If the active AXSM has some non-default interface policy configured, then the 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, tstdelay works only when the OAM cells are disabled on the segment endpoints. To disable OAM cells, use the following procedure:

Step 1 dpnport <portid>

Step 2 cnfpnportsig <portid> -cntlvc ip

Step 3 cnfoamsegep <portid> no

Step 4 uppnport <portid>

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



dncon followed by upcon

controller resync (dnport followed by upport)


reroute (dnport)

PNNI default minimum VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes such as MPLS and NCDP. For users who would like to add an MPLS controller in future releases of the Cisco MGX 8850 switch, it is highly recommend to set the minimum 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 signaling VC for MPLS will be established automatically on 0/32.

By default, 900 cps and 543 cps will be reserved for the SSCOP and PNNI signalling VCs, respectively, even when you disable SSCOP and PNNI. These values are configurable through 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, and the card tries to become ACTIVE, 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 or ports still exist. If you do enter delcontroller and later want to recover the connections, you must re-added the controller using addcontroller and reset the AXSM cards or the entire node (otherwise ports remain in provisioning state). There is now a warning about the impact of the command when there are existing connections or 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 reduce the usage of that link.

To replace one type of AXSM front card with another type, all connections, partitions, and ports must be deleted, and all lines must be brought down. If an AXSM card fails, the same type of AXSM card must be installed in that slot so that communications can be resumed or so that the configuration can be changed to prepare for a new card type.

Limitations and Restrictions

The following are known limitations or restrictions for this release:

The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in Release 2.0 baseline (2.0.10-2.0.16) with PXM45 and PXM45/B is 99.

The maximum number of signalling interfaces in Release 2.0 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.

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 through both IISP and PNNI links on 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.

A port or card SCT can be changed while connections are present in this release. However, if the SCT change affects active connections, those 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 use to manage the network, the IP address 10.0.x.x cannot be used as the LAN address (lnPci) for the switch.

If you would like to add an MPLS partition on a port where other partitions have already been added and the minimum vci value is 32, you have 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 minimum vci to 35 for all partitions on the port.

(CSCdr15911) Changing or reseating an AXSM OC48 back card several times may sometimes cause the front card to reset and interrupt service. The PhyTask also gets suspended. To avoid this problem, try not to reseat the back card too often. If the front card does not start when the switch power is turned on, try to reseat the front and back card to bring up the system.

Important Notes

The following sections provide additional information on BITS clock source configuration, APS operation in this release, and recommendations for setting the control VC parameters.

BITS Clock Source Configuration

The Cisco MGX 8850 Software Configuration Guide incorrectly lists four port numbers for the two BITS clock ports on the back of the PXM-UI-S3 card. During configuration (using the cnfclksrc command), the correct port number to use for the upper clock port is 35. The correct port number for the lower clock port is 36.

APS Management Information

The following tips apply to the use of the dspapsbkplane command and the APS connector which is sometimes call a back plane. The APS connector must be installed to enable intercard APS.

The dspapsbkplane command shows whether the APS connector is plugged in properly. It should be used only when the standby card is in Ready state. When the standby card is booting or fails, intercard APS cannot work properly and this command displays "NOT ENGAGED."

APS must be configured on a line pair before the dspapsbkplane command can display the APS connector status. If APS is not configured on a line, the dspapsbkplane command displays the message "Aps Line Pair does not exist."

The dspapsbkplane command needs to be executed on both the active & standby cards to ensure that APS connector is engaged properly. This command can show different values for each of the two cards, which indicates the APS connector is seated properly on one card but not on the other.

The APS connector status is the same for all lines in a single bay. This is because the APS connector interconnects two back cards within the same bay. To check the APS status for an AXSM card that hosts ports in the upper and lower bays, you must enter the dspapsbkplane command twice, once for a line in each bay.

Caution When using intercard APS, 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 After you install the assembly, verify that the APS connector is properly installed by using the new CLI command dspapsbkplane.

Note (CSCdu19732) If there are APS configurations on a card and some lines are disconnected, avoid performing switchredcd, front card removal, or back card removal. Before removing an active front card or back card, which results in a card switch over, switch cards with the switchredcd command.


Cisco Systems recommends 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.11and above (number 2 and 3, which are included in the 2.0.16 release) for the control VC feature.

Documentation Correction — Feeder Configuration

In the Cisco MGX 8850 Software Configuration Guide, Chapter 4, Step 2 in the Feeder Configuration Quickstart incorrectly states that an IP address must be entered with the cnfpnportsig command to support CWM management. The correct syntax for the command is:

pop20two.7.PXM.a > cnfpnportsig <portid> -cntlvc ip

The ip component of the command should be entered as shown above. Do not replace this component with an IP address.

Known Anomalies in This Release

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
S1 Bugs


Symptom: OC12 p-p jitter amplitude exceeded the 0.10 UI pp.

Condition: Unknown

Workaround: None


Symptom: Connections went into conditioning state after a switchcc was executed.

Condition: switchcc was executed after PXM45s were replaced.

Workaround: UNKNOWN


Symptom: 1000+ SPVCs failed during a 2.0.12-2.1.00 upgrade.

Condition: burnboot procedure was executed on standby PXM45 and switchcc was then executed.

Workaround: UNKNOWN


Symptom: APS working lines and protection lines in alarm.

Condition: Removing the front card.

Workaround: None


Symptom: Traffic loss, PNNI links resetting.

Condition: Problem is caused by hardware failure.

Workaround: switchcc may help if load sharing is not enabled.



Symptom: dspcon shows routing cost = 0.

Condition: This will happen after swithcc on connections that are not rerouted.

Workaround: Do a dncon or rrtcon.


Symptom: Upon AXSM reset, ILMI on some ports on the said AXSM may go into "disabled" state.

Condition: This is a very rare situation and has been observed twice in the past six months of testing.

Workaround: Bring down the port and then bring it back up.


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

Condition: (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.


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

Condition: This happens when intraslave connections (between two ports) were added on the AXSM. If one of the ports was admin downed followed by inserting or resetting the standby AXSM.

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


Symptom: Traps were not generated for hard disk failure during fault insertion testing.

Condition: Hard disk failure was simulated on modified PXM45s.

Workaround: UNKNOWN


Symptom: Switchover to faulty standby PXM45 allowed during fault insertion testing.

Condition: Hard disk failure was simulated on the standby PXM45.

Workaround: UNKNOWN


Symptom: PXM45 switchover did not occur when hard disk failure simulated on active PXM45 during fault insertion testing.

Condition: Hard disk failure was simulated on active PXM45.

Workaround: UNKNOWN


Symptom: No alarms reported when hard disk failure on active PXM45.

Condition: Hard disk failure was simulated on active PXM45.

Workaround: UNKNOWN


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

Condition: Hard disk failure was simulated on active PXM45.

Workaround: UNKNOWN


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

Condition: When OC12 line is receiving RDI-P.

Workaround: No workaround.


Symptom: Channel loops are randomly being knocked down.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Device driver core dumps recorded on PXM45.

Condition: Nodes had experienced power outages the previous day, and had to have their PXM45s reseated as part of the recovery process.

Workaround: UNKNOWN


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


Symptom: Node alarms and traps are not generated on High Speed serial link errors.

Condition: High Speed serial link error injected during Fault Insertion Testing.

Workaround: UNKNOWN


Symptom: APS switching is blocked for 1+ minute after alarm cleared.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Incoming RDI-L, RDI-P not declared and cleared within 100usec.

Condition: Incoming AIS-L.

Workaround: UNKNOWN


Symptom: RDI-L and RDI-P clear times are greater than 100usec.

Condition: LOS is cleared.

Workaround: UNKNOWN


Symptom: RDI-L and RDI-P clear times are greater than 100usec.

Condition: LOF is present and then cleared.

Workaround: UNKNOWN


Symptom: LOS alarm condition is displayed during LOF.

Condition: dspalms and dspalmcnt show LOS condition.

Workaround: UNKNOWN


Symptom: OC12 line code violations do not increment.

Condition: Incoming B2 errors.

Workaround: UNKNOWN


Symptom: OC12 incorrectly generates RDI-L and RDI-P.

Condition: B2 errors are received.

Workaround: UNKNOWN


Symptom: RDI-L and RDI-P clear times after LOF cleared greater than 100usec.

Condition: LOF condition has been cleared.

Workaround: UNKNOWN


Symptom: OS reports Line AIS, Section LOS, LOF and Path RDI.

Condition: Incoming LOF condition.

Workaround: UNKNOWN


Symptom: Watchdog timeout reset core dump observed on PXM45.

Condition: Customer was executing Fault Insertion testing.

Workaround: UNKNOWN


Symptom: PNNI neighbor PTSE database synchronization and other problems after flash failure test during Fault Insertion testing.

Condition: Flash failure test was being conducted.

Workaround: UNKNOWN


Symptom: Device driver error core dumps.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: LOF criteria is not met per R5-225, for AXSM OC12 interface.

Condition: OOF condition is cleared at the presence of three consecutive error free patterns rather than two.

Workaround: UNKNOWN


Symptom: PXM45 did not switchover and all cards went into a continuous reset, during Fault Insertion testing.

Condition: QE0 failure test was being conducted.

Workaround: UNKNOWN


Symptom: Reset type and reset reason observed by user did not match Cisco report.

Condition: PCI bus error Fault Insertion tests were being conducted.

Workaround: UNKNOWN


Symptom: No indication for PCI bus error on active PXM45.

Condition: PCI bus error fault insertion testing was being conducted.

Workaround: UNKNOWN


Symptom: Alarm reporting different for PCI bus errors on standby vs. active PXM45.

Condition: PCI bus error Fault Insertion Testing was being conducted.

Workaround: UNKNOWN


Symptom: Master end of routed connections shows OK, but slave end shows Condn.

Condition: N/A

Workaround: None


Symptom: EPD/PPD value defaulted to disable in SCTs.

Condition: None

Workaround: Create new SCT via CWM with EPD/PDD enabled.


Symptom: QE48 SAR error messages and memory block assignment messages observed in error and event log files.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Node rebuild occurred when switchcc was executed during Fault Insertion testing.

Condition: QE1 failure test was being conducted.

Workaround: UNKNOWN


Symptom: QE1 failure not recorded during Fault Insertion Testing.

Condition: QE1 failure testing was being done.

Workaround: UNKNOWN


Symptom: Faulty card did not go into continuous reset during QE1 failure.

Condition: QE1 failure testing was being undertaken.

Workaround: UNKNOWN


Symptom: PXM45 did not switchover on LAN port failure.

Condition: Fault Insertion Testing was being conducted.

Workaround: UNKNOWN


Symptom: No indications presented to user when LAN port failure on standby PXM45.

Condition: Fault Insertion Testing was being conducted.

Workaround: UNKNOWN


Symptom: No access to node via LAN.

Condition: LAN port has hardware failure. Driver does not detect and request processor switch over.

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


Symptom: No indication provided via event log or alarm reporting for crossbar failure.

Condition: Crossbar Failure Insertion tests were being conducted.

Workaround: UNKNOWN


Symptom: Serial Link Path failure (Severity 7) is not logged into the event log.

Condition: Serial Link Path Failure Insertion tests were being conducted.

Workaround: UNKNOWN


Symptom: Inconsistent alarm reporting in case of Serial Link Path Failure (should be Major).

Condition: Serial Link Path Failure Insertion tests were being conducted.

Workaround: UNKNOWN


Symptom: Faulty card did not go into continuous reset when encountering parity error on internal Utopia bus on the Active PXM45.

Condition: Utopia bus failure testing was being undertaken on the PXM45.

Workaround: UNKNOWN


Symptom: Faulty card did not go into continuous reset when encountering parity error on internal Utopia bus on the active PXM45.

Condition: Utopia bus failure testing was being undertaken on the PXM45.

Workaround: UNKNOWN


Symptom: Faulty card did not go into continuous reset during Utopia bus parity error failure.

Condition: Utopia bus parity error fault insertion was being undertaken.

Workaround: UNKNOWN


Symptom: APS line went to protect after clearing it under a scenario.

Condition: Change mode when active line is protection line.

Workaround: Execute a clear instruction after the cnfapsln command.


Symptom: dsppnports shows 3 more DAX connections after switchredcd.

Condition: This could happen if there are some failed connections before switchredcd.

Workaround: None


Symptom: APS protection line temporarily going into alarm.

Condition: Issue the switchredcd command.

Workaround: Unknown


Symptom: APS Service Switch request propagates to all bays in APS pair.

Condition: switchapsln command supplied with service switch set to 1.

Workaround: Apply switchapsln command per port instead of service switch.


Symptom: Connection commit failure reported on the standby AXSM.

Condition: During bulkSync, if controller performs massive deroute or reroute activity on the active AXSM, the connection request forwarded to standby may fail.

Workaround: None.


Symptom: dspln shows critical alarm, but dspapsln shows OK.

Condition: None.

Workaround: switchredcd will recover it.


Symptom: switchredcd results in line alarm.

Condition: switchredcd causes both lines to go into alarm.

Workaround: NONE


Symptom: APS lines: disconnected the cable on working line, then switchredcd, most of the time, when the standby card came up, both the working and protect lines were in alarm, and pnport/PNNI link were down.

Condition: This is the double fault APS issue, and it interrupts traffic.

Workaround: None


Symptom: APS switched protection line to working line.

Condition: Issue the switchredcd command or remove and reinstall the back card.

Workaround: Unknown


Symptom: Standby PXM45 card keeps giving the qcPurgeVc fail error message.

Condition: Not Known. Login to standby PXM45 card and message keeps popping out.

Workaround: Not Known


Symptom: Critical alarm seen on the other end after reinsertion of backcard.

Condition: Removal and reinsertion causes critical alarm on the other side.

Workaround: None


Symptom: switchredcd results in line switching. In the case of APS, with the working line removed, a switchredcd would cause the far end to switch back to the working line.

Condition: Data loss as a result of switchredcd.

Workaround: Do not remove the lines when switching cards.


Symptom: AXSM-2/B Off-Line Diagnostics fails.

Condition: This failure occurs whenever the Off-Line Diagnostics is invoked. (The Off-Line Diagnostics is invoked via the cnfdiag command).

Workaround: None


Symptom: 1) For spvc, the fail cause for master ABR spvc (using dspcon) shows Unsupported combination of traffic parameters but the service type and all the traffic parameters match between master and slave.

2) For svc, the release cause is #73 (Unsupported combination of traffic parameters).

Condition: For an ABR connection, if local PCR is greater than remote MCR OR remote PCR is greater than local MCR this problem occurs.

Workaround: Set (localPCR > localMCR) AND (localPCR > remoteMCR)

Set (remotePCR > remoteMCR) AND (remotePCR > localMCR) in ABR connections.


Symptom: DAX connection did go to Fail state

Condition: When removing the card that has the master side of the connection

Workaround: Unknown




Symptom: No access to node via LAN.

Condition: 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.


Symptom: When performing SPVC reroute and switchover on 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.

Condition: (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 or derouting connections.


Symptom: Standby PXM45 card is in continuous reset loop, and 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 PXM45 card manually.

Workaround: None


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 PXM45 card manually.

Workaround: None


Symptom: switchcc allowed to be executed when the standby PXM45 card has a hardware failure.

Condition: Injecting a hardware failure on SRAM component of standby PXM45 card manually.

Workaround: Do not execute switchcc.


Symptom: Standby PXM45 card hardware failure is not reported correctly.

Condition: Injecting a hardware failure on SRAM component of standby PXM45 card manually.

Workaround: None


Symptom: Active and standby PXM45 card hardware failure is not reported in the event log.

Condition: Injecting a hardware failure on SRAM component of either active or standby PXM45 card manually.

Workaround: None


Symptom: No error log is seen about the BRAM component failure.

Condition: Injecting a hardware failure on BRAM component of active PXM45 card manually.

Workaround: None


Symptom: PXM45 card status LED is green, when the card is continuous reset loop.

Condition: Injecting a hardware failure on BRAM component of active PXM45 card manually.

Workaround: None


Symptom: Sometimes, dtandby PXM45 card goes to Failed state.

Condition: Injecting a hardware failure on SRAM component of standby PXM45 card manually.

Workaround: None


Symptom: Two PXM45 nodes. One end has primary and secondary clock configured (first node) and the other end 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 be "not 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

Condition: Anomaly has only occurred after performing resetsys on two nodes at the same time.

Workaround: Reconfigure the clocks with cnfclksrc commands.


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 PXM45 card or hard disk is replaced with an older card or hard disk that has old data on it.

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

To determine if there is residual data on a PXM45 hard disk, after the node comes up, perform a list file command (for example, 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 for residual databases.


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

Condition: This node has experienced data discards and a card reset on one of the AXSM cards.

Workaround: Not known


Symptom: Command dsperr doesn't give the syntax when the command is just typed in.

Condition: Issuing the dsperr command.

Workaround: None


Symptom: Nwbrowser does not show any hardware related information on AXSM card.

Condition: Every time.

Workaround: No workaround.


Symptom: Popup messages appeared on CLI.

Condition: Hard disk failure was simulated during fault insertion testing.

Workaround: UNKNOWN


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

Condition: When UNEQ-P is received.

Workaround: No workaround.


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

Condition: When UNEQ-P alarm is received.

Workaround: No workaround.


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.


Symptom: cnfcon on maxcost with 2147483648 (0x80000000) to 4294967295 (0xFFFFFFFF) will round it down to 2147483647 (0x7FFFFFFF).

Condition: When the maxcost of the connection is changed.

Workaround: When connection is initially added, don't specify maxcost value. The default is -1, which translates to 0xFFFFFFFF. If it is changed, it will be bound to the range of 0 to 2147483647. The only way to have maxcost set to 0xFFFFFFFF is to delete and re-add the connection with default value.


Symptom: Backup boot on standby PXM45 checks for file size alignment after downloading file from active PXM45.

Condition: When runtime file from active PXM45 gets downloaded and its size is not 8 bytes align, errors get displayed on console port.

Workaround: None


Symptom: dsperr on non-PXM45 slot provide incorrect information.

Condition: dsperr currently provides proper information only when it is executed on PXM45 slot. When it is executed on the AXSM slot, the information seems incorrect.

Workaround: None.

Additional Information:

The information is actually correct. CA/TAC needs to do the following to read the dsperr information:

1. FTP the error log file to a UNIX workstation as explained below:

For an error with E:xxxXX number on slot Y, FTP the file:

C:/LOG/slotY/errorXX.log (XX are the last 2 digits of E:xxxXX number, and Y should be preceded by 0 if Y is single digit). For example, FTP "C:/LOG/slot07/error94.log" if you are interested in say, error 23394 on slot 7.

2. Use "dsperr2" tool on the UNIX workstation to display the error.

If the binary image running on the shelf is say, pxm45_002.001.050.000-D_mgx, use the command:

dsperr2 error94.log pxm45_002.001.050.000-D_mgx

to display the correct trace information.


Symptom: After setrev to downgrade from 2.1.x to 2.0.x, we see checksum mismatches between the PXM45 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


Symptom: Configure an intercard APS with the working line index on the active card and the protection line index on the standby card. Let us have the working line as the active line to begin with. Now perform a switchapsln so that the protection line is active. At this point, the active card is working off the protection line (which is physically connected to the standby's back card) and vice versa. Now, pull out the working line (which is the line going to the back card of the active AXSM). Notice that the standby AXSM's LED goes RED. This is because the standby card is "tuned" to the working line. However, this is confusing to the user because it gives a false impression that the line connected to the standby AXSM has failed.

Condition: As explained above.

Workaround: The user needs to be aware that in an intercard APS case where the active AXSM is working off a line which is physically connected to the standby's back card and vice versa, the LED reports may be misleading.


Symptom: APS CLI error messages gives prints system level error messages.

Condition: Error conditions on CLI command like wrong parameter etc.

Workaround: none


Symptom: Console port baud rate is not shown correctly using the dspserialif command.

Condition: User sees a "0" baud rate when executing dspserialif command. Terminal server connects to console port fine with a baud rate of 9600. A cnfserialif is then executed to set the port to 9600. A subsequent execution of dspserialif then shows the value correctly as 9600.

Workaround: Use cnfserialif.


Symptom: Switch driver error messages appeared in the event log.

Condition: AXSM cards were reseated.

Workaround: UNKNOWN


Symptom: dspcd output showed the failed reason is UNDECODED.

Condition: When the card is in failed state.

Workaround: None


Symptom: dspalms showed unterminated interfaces that were in admin down state to be in LOS, LOF state

Condition: Lines had been put in admin up while still unterminated, and then put into admin down state.

Workaround: UNKNOWN


Symptom: Popup messages on user sessions.

Condition: OC48 cards were removed and inserted.

Workaround: UNKNOWN


Symptom: No CLI command to clear the channel count.

Condition: No CLI command to clear the channel count.

Workaround: None


Symptom: Confusing error message when conntrace fails.

Condition: conntrace was run from the slave end.

Workaround: UNKNOWN


Symptom: dsplns, dspports, and dspcons commands on standby AXSM do not show correct status.

Condition: AXSM is standby in a Y-cabled redundant pair.

Workaround: UNKNOWN


Symptom: Incorrect usage statement is presented to user for addport command.

Condition: addport command with invalid parameters is used.

Workaround: UNKNOWN


Symptom: addpart usage statement is incorrect.

Condition: addpart command is executed with invalid parameters.

Workaround: UNKNOWN


Symptom: Popup messages: DMA currently active appear on telnet sessions.

Condition: QE0 Fault Insertion tests were being conducted.

Workaround: UNKNOWN


Symptom: Err: Card reset/removed/failed popup messages appeared.

Condition: QE0 failure test was being conducted.

Workaround: UNKNOWN


Symptom: Event log messages for VC lookup failed observed.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: CTC app event handler failed messages observed in event log.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: halfLeg removal failed messages are observed in event log.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: sr_proto_unblock_app:Failed allocating resource IpcMessage Err=0x26037 message appears in event log.

Condition: Messages were logged against an AXSM after 2.0.11 upgrade.

Workaround: UNKNOWN


Symptom: OC3/OC12 J1 byte does not provide trace patch to FE NE.

Condition: Unknown

Workaround: Unknown


Symptom: Line information is incorrect when inserting both T3 and E3 back cards in the same slot.

Condition: Inserting T3 and E3 back cards in the same slot.

Workaround: None.


Symptom: QE48 SAR error messages and Memory block assignment messages observed in error and event log files.

Condition: None

Workaround: None


Symptom: Different level of alarm reported by dspxbaralm and dspswalms.

Condition: When there is crossbar errors.

Workaround: None.


Symptom: addred command is executed on AXSMs of differing code levels with no warning to the user.

Condition: 2.0.13.

Workaround: Unknown.


Symptom: It takes 10 minutes to reset AXSM card after QE48 is disabled.

Condition: QE48 is disabled.

Workaround: None.


Symptom: Some of the events logged to BRAM are not visible on standby card.

Condition: None

Workaround: BRAM events are sent over to the standby card at recurring intervals.


Symptom: A line is missing in dsplns output.

Condition: This happens sometimes when a user does restoreallcnf on a T3E3 card.

Workaround: None


Symptom: dnallports will stops all traffic flow, and this bug is a request for a new CLI feature that will forewarn the user when he or she downs all ports.

Condition: Users issue dnallports command.

Workaround: UNKNOWN


Symptom: Switch fails sometimes when the operating mode is bi -directional.

Condition: APS switchover fails.

Workaround: To provision 1+1 uni direction on at least one side.


Symptom: Port in Building VC after cnfpnportcac command.

Condition: Bring down the port on AXSM and run cnfpnportcac command on PXM45.

Workaround: Bring up the port on AXSM.


Symptom: Line LOS alarm on line in local loopback does not clear.

Condition: When back card is removed and re-inserted (line RX is not connected), for OC48 card only.

Workaround: dellnloop and addlnloop again.


Symptom: AXSM2 takes long time to detect serial link failure and thus may have some cell loss.

Condition: Serial link error injected during Fault Insertion Testing.

Workaround: None


Symptom: cnfsig returns syntax error

Condition: Interface in provisioning state does not accept some values for t310

Workaround: Bring the port operationally up and then issue cnfsig with desired t310 values.


Symptom: CLI enhancement to provide one command to show amount of bandwidth available and overbooking factors.

Condition: 2.0.13 code.

Workaround: Use all CLI commands.


Symptom: Manual switch to working line from protection line does not work.

Condition: APS had been configured between MGX and BPX. LOS was created on working line and then cleared.

Workaround: UNKNOWN


Symptom: VBR.2 connections for both rt and nrt types are allowing more CLP1 cells than should be.

Condition: This could potentially result in network congestion.

Workaround: unknown


Symptom: Working connections can indicate erroneous alarm "E-AisRdi" on working connections after AXSM OC-3 back card has been removed and reinserted with neighboring back card with APS connector present.

Condition: Neighboring 8 port OC-3 backcards with APS backplane present are removed as a set and reinserted. APS is not activated. Some connections may show alarm as "E-AisRdi" using the command 'dspcons -filt 2' on the active AXSM. This alarm indicates receipt of an Alarm Indication Signal from the opposite end of the connection, however no corresponding alarm exists at the other end and the connection is passing cells between the end devices.

Workaround: Leaving standby side in place and secured, remove the active side, reinsert and secure screws. Some or all alarms may clear.


Symptom: dsplog shows uninitialized string associated with the working line index when Protection Switch Byte Failure (PSBF) events occur.

Condition: APS failure event occurs associated with PSBF.

Workaround: None.


Symptom: SignalFailLowPriority does not clear for long time.

Condition: SignalFailLowPriority shows up for long time with dspapsln.

Workaround: Unknown


Symptom: Max Cost value of a connection cannot be got back to -1 again; if changed to another value once.

Condition: A cnfcon was done on the connection to change the value of Max Cost.

Workaround: Make the Max Cost value as high as possible.


Symptom: Ports, partitions, and connection configuration appeared on a previously empty and unconfigured slot when an AXSM card was inserted.

Condition: 2.0.13.

Workaround: Unknown.


Symptom: Protection line is in alarm when it is OK on APS line redundancy testing.

Condition: AXSM OC12 secondary front card is active, primary front card is in standby. On back card, upper and lower bay working lines are active.

Workaround: Delete and re-add APS redundancy.


Symptom: Alarm integration problem on AXSM OC12.

Condition: Reading from dad shows alarm not displayed in dspln and dspalms.

Workaround: Unknown


Symptom: dspconalarms command to be introduced on AXSM CLI.

Condition: None, because the requested command is a new one.

Workaround: None.


Symptom: dspapsln command doesn't give details of MIS status.

Condition: When the APS line go to different mismatch status.

Workaround: N/A


Symptom: The line admin state is down because either:

- there is NO DISK RECORD on the line, the line is defaulted to admin state down; or - the disk record is there but it shows admin state down.

Condition: Upgrading from older version to newer version and doing setrev's on multiple cards at the same time.

Workaround: Do setrev on each card and wait until that is complete before doing the next card.


Symptom: Online diag did not fail

Condition: When faults are injected on all XBAR switches

Workaround: None


Symptom: Xbar remap failed after executing a node rebuild.

Condition: By executing the commands resetcd 7 and resetcd 8.

Workaround: none


Symptom: Xbar remap failed after executing a node rebuild.

Condition: By executing the commands resetcd 7 and resetcd 8.

Workaround: none


Symptom: popup message - relMsgCount: 0 endpoints 100 time swo 70

Condition: After doing a series of switchcc, and resetcds.

Workaround: None


Symptom: Some SCT related AXSM CLI commands' display need to be changed with up-to-date information. Some fields have been deprecated and some have changed.

Condition: AXSM CLI commands on SCT.

Workaround: None.


Symptom: After setting the node name using SNMP (system.sysName.0), any of the following symptoms occur:

- existing CLI sessions do not immediately reflect the changed node name - the standby PXM does not reflect the changed node name - attached feeders do not reflect the change node name

Condition: Whenever node name is changed using SNMP.

Workaround: Change the node name using the CLI command "cnfname".


Symptom: dsplog syntax accepts invalid option values

Condition: Issuing the dsplog command

Workaround: None


Symptom: Keeps getting VCM-4-INTERNAL error on logs

Condition: Normal operation

Workaround: N/A


Symptom: ll command with argument doesn't give file details

Condition: Execute ll command with some argument

Workaround: When the file details required always use ll command.


Symptom: PnPort stuck in building VC

Condition: After cnfpart (with max cons less than existing cons), dnpnport and uppnport.

Workaround: for recovery reconfigure cnfpart with max cons greater than existing no. of cons then dnpnport and uppnport.


Symptom: abr conn fails if cdvt is changed from default.

Condition: changing cdvt value of the abr conn.

Workaround: None


Symptom: AXSM card reset with software error reset reason but no core collected

Condition: AXSM card was running out of memory and could not cc to it.

Workaround: None


Symptom: Inappropriate Error message for dspchancnt

Condition: If you specify a vci (values other than 0) and vpi used for a vpc.

Workaround: Unknown


Symptom: Line stays in alarm after adding a soft loop

Condition: Unknown



Symptom: Extra entries in dsplog

Condition: If you run a severe category command on CLI the say No when asked to confirm the action



Symptom: File not saved after saveallcnf

Condition: If there is already two configuration files saved with a more recent date.

Workaround: delete one of the existing files then do 'saveallcnf'.

Problems Fixed in Release 2.0.16

Bug ID
S1 Bugs


An error can occur with management protocol processing. Please use the following URL for further information:

S2 Bugs


IPCONN: changes to handle low network memory problems


Workstation or network management system cannot reach node via TCP/IP. Ping, telnet, etc. no longer work.


IP Connectivity cache and IP routing in an inconsistent state. IP route exists for atm interface (routeShow) but corresponding interface cache entry does not exist (dspipifcache)


IP route must be manually deleted using routeDelete command.

Problems Fixed in Release 2.0.15

Bug ID
S1 Bugs


Symptom: Connections cannot be added.

Condition: Unknown.

Workaround: None


Symptom: Ports not work properly (some in building vc, some in down in progress) The problem is cause when resync is happening, ILMI down the port. If resync fail to commit, resync will call back to vcm, and vcm will recommit the vc without checking the current vc status. If the current vc status is not in PVC_CONNECT, this problem could happen.

Condition: The ports are stuck in building vc and down in progress after resetsys on peer node.

1. hardware: two POPEYE node with ILMI enabled on nni link

2. Manually kicks in resync in one node, and reset the peer node may cause this problem happen, but it depends on timing.

Workaround: Down and up the port works for most cases


Symptom: dsppnportrsrc command for the port shows MinTx Cellrate and Min Tx Cell rate same as the Max Tx Cell rate for each service category.

Condition: When partition minimum bandwidth is configured the same as the partitions maximum bandwidth and when the interface policy is not applied in the service module (AXSM).

Workaround: cnfpnportcac for the port again will fix it.


Symptom: System reset occurs when trying to setup a connection.

Condition: When two or more TTL IE's (identifier = 237), each of size a few hundred bytes, are included in the Setup message or the Connect message.

Workaround: Avoid using more than 1 TTL IE and keep the size within 400 bytes.


Symptom: All connections and pnni-links were down. Can not cc to a service module slot.

Err: cliSipcPsrWrite(): ssiIpcMessageSend(): failed

Condition: After a core dump on AXSM card, IPC paths for a random slot are deleted

Workaround: None

Additional Information:

Reset the SM that user can not cc to


Symptom: No core dump

Condition: Stanby card reset.

Workaround: None


Symptom: 100K routed b/w orses7 and orses9. orses6 is the via node. When standby is reset, journaling congestion is still on.

Condition: journaling congestion flag stays on at orses7 when standby PXM crashed and went into fail status. Congestion is not released for 5 hours unless resetsys.

Workaround: none


Symptom: Switchredcd caused the node to reset

Condition: Whenever a switchredcd is done the shelf gets reset.

Workaround: None.


Symptom: Connection reserves keep failing because of bandwidth CAC.

Condition: Bandwidth leakage happens (mostly on the ingress data structures)

Workaround: None


Symptom: OAM cell flooding causes AXSM lockup.

Condition: OAM loopback cells are injected to a uni interface at a high rate. AXSM card locks up after unspecified time. Other shelf management functions such as CCing to another card are also affected.

Workaround: None


Symptom: Connections failed with causes like destination out of order, No user responding etc.

Condition: Lot of rerouting across the network.

Workaround: None


Symptom: The configuration is observed lost after the card/node rebuilds (after a card/node reset).

Condition: When a card/node is configured while Standby PXM is coming up (not yet ready), it may not be written to the Standby PXM disk nor may it be synchronized from the Active PXM disk. This loss of configuration is not observed until PXM switchover is performed. When the PXM switchover is performed, the Standby PXM becomes Active. When the old Active PXM becomes Standby PXM and synchronizes from Active PXM, it deletes this configuration that was missing on the new Active PXM. Once, this PXM switchover happens, the configuration missing on the old Standby PXM is permanently lost.

Workaround: There is no workaround once this problem happened. As a preventive action, do not configure the node (any card) while the Standby PXM is coming up. Wait till the Standby PXM comes to READY state before configuring the node.


Symptom: Standby PXM fails to come up due to the TLOGD task suspending itself

Condition: When the hard disk on the Standby PXM is replace or reformat or the "C:\LOG" directory and the current firmware is delete from the "C:\FW", tLOGD will suspend itself while trying to boot up.

Workaround: One of the work around is:

1) copy the firmware that is running on the active PXM to the C:\FW directory of the standby PXM hard drive.

2) At the backup boot prompt of the standby PXM, issue sysVersionSet "firmware that is running on the active PXM"

3) Reboot the standby PXM card.


Symptom: Active PXM resets during a loadrev to upgrade Standby.

Condition: DbSvrIO Tlb Load Exception on Active PXM.

Workaround: None.


Symptom: PXM1, PXM45, AXSM, or AXSM-E cards keeps resetting due to Watchdog time-out. The stack in the core dump indicate that the function ssiExceptionLog() is being called recursively within a task context.

Condition: One of the possible conditions for this problem to occur is if a software exception occur on a card that have memory corruption.

Workaround: None.


Symptom: AXSM hardware reported Full coverage failure for offline diagnostic tests. Need to change UPD48 Memory test to take memory size.

Condition: Offline diagnostic coverage was executed 2.1(10) and 2.0.

Workaround: UNKNOWN


Symptom: Cards went to fail state because of the memory problem

Condition: Cards went to fail state because of the memory problem

Workaround: None


Symptom: Trap IP address on a node observed to change.

Condition: Hard drive backcards have been swapped with other nodes, and switchccs were executed on days when IP address was observed to change

Workaround: When insert HD backcard to the standby PXM, make sure to delete the DB on the card before insert into the node. This will force the standby PXM to sync up DB with the active PXM.


Symptom: abr conn not getting their mcr during congestion.

Condition: Whenever there is congestion.

Workaround: None


Symptom: AXSM-2/A Off-Line Diagnostics fails. Note that this only fails with the Model-A (pre model-B).

Condition: This failure occurs whenever the Off-Line Diagnostics is invoked. (The Off-Line Diagnostics is invoked via the cnfdiag command).

Workaround: None


Symptom: All the links went to attempt state and connections failed.

Condition: Turn on offline diagnostics on standby PXM

Workaround: None


Symptom: IPCONN task crashes

Condition: Upon receiving an invalid version 4 LMI request

Workaround: None


Symptom: POPEYE1 sends a node status with Version 4, but the IE length is version 3.

Condition: This problem happens if MGX1 negotiates with MGX2 for Node Status Version. If MGX2 sends MGX1 that is running Version 4, then MGX1 will send the node status version 4, even though it does not support it. If MGX2 initiates the negotiate, then there is no problem.

Workaround: (1) First down the dnpnport on the PNNI to disable IPConn.

(2) Next down/up the port on AXSM or feeder, this will force the node status negotiation. On the AXSM shellconn, use the command, lmiDisplayFdrInfo 0, 1, ... if the corresponding feeder shows it is still running version 4, then it did not succeed. So repeat step 2.

(3) uppnport on PNNI, so IPConn will be up.


Symptom: The switch is not sending the modified values for SCR and MBS of SPVC connections on BPX-SES nodes.

Condition: Modify the SCR and MBS values of SPVC connection on BPX-SES using CWM. The modified values are reflected on the switch, but the modified values are not sent to CWM.

Workaround: None.


Symptom: All PNNI links went to failed state and connections failed to reroute

Condition: Not known

Workaround: None.


Symptom: Can't 'cc' to some AXSM cards.

Condition: active card continues to send standby updates after receiving a standby reset

Workaround: none

S2 Bugs



Symptom: ILMI log message flooding the log file

Condition: Unknown

Workaround: None


Symptom: Install Cross Connect fails with out of range VPI.

Condition: When succeeding node id is higher than preceding node id, VPI/VCI assignment is done by succeeding node and preceding node's min VPI is greater than that of succeeding node's min VPI.

Workaround: Change the succeeding node's min VPI to be the same as preceding node.


Symptom: After switchcc, newly active PXM45 goes onto internal oscillator.

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

Workaround: UNKNOWN


Symptom: AXSM OC12 does not report LOCD alarm.

Condition: When cell delineation is lost on incoming OC12 SONET signal.

Workaround: No workaround.


Symptom: After upgrading BXM fw from MF07 to MFJ at orion node(svcbpx26), the link 12:1.4:4 at MGX node(p2spvc4) is not listed in pnni-link.

Condition: The link 2.4 at orion node(svcpop2) is connected to 12:1.4:4 at MGX node(p2spvc4). there are 100k spvc routed connections between two nodes.

Workaround: UNKNOWN


Symptom: Events regarding chunk corruption are logged.

Condition: The particular next chunk is corrupted during the initialization processes of applications when an invalid index is used to reset the value of the end magic word of the chunk header.

Workaround: None


Symptom: Statistics files are being generated on the switch, though statistics collection is disabled on CWM.

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Burning backup boot to PXM45 flash causes the system to hang when the flash device is not working.

Condition: Bad flash device causes the system to hang while the flash is being programmed.

Workaround: none


Symptom: Card stuck in programming due to momentary flash failure.

Condition: Inserted flash failure by changing the switch 2-8 to ON position.

Workaround: Unknown


Symptom: after resetsys at MGX node p2spvc3, found out the tmon task is using 54% CPU usage.

Condition: MGX nodes p2spvc3 has standalone pxm45 and p2spvc4 has standalone PXM45-B card. 100K spvc connections have been established between p2spvc4 and orion node svcpop2. all the spvc connections are routed thru two via nodes(svcpop3 and p2spvc3).

Workaround: UNKNOWN


Symptom: dspapslns on standby card does not show all APS-enabled lines as on active card.

Condition: After multiple delapsln/addapsln on same APS line and standby is reset.

Workaround: Reset standby card.


Symptom: When dspswalms is used, crossbar fabric alarms are displayed with slot numbers, but they should not be associated with any slot number.

Condition: Whenever dspswalms is used, the above problem is seen.

Workaround: none


Symptom: After switchcc, the active AXSME OC3 card shows up empty reserved in dspcds although it is active in the shelf. In addition, the standby AXSME did not take over and stays in standby state.

Condition: Issuing the switchcc command.

Workaround: None


Symptom: During AXSM card switchover, when a line on the previous card is in alarm, but on the new active has the alarm cleared, then CWM does not get updated with the new 'clear' alarm state.

Condition: During AXSM card switchover, when a line on the previous card is in alarm, but on the new active has the alarm cleared.

Workaround: NONE


Symptom: Wrong value of summary address gets assigned.

Condition: 1)When ever the length of PNNI summary address (entered with the command) is less than the length provided in the same command, the wrong value gets entered.

2)When length of summary address and mentioned length are same but length is an odd multiple of 4 (e.g., 12).


1) Keep the length of the PNNI summary address (entered with the command) larger than the length mentioned in the same command.

2) Keep the length as multiple of 8 and keep the length of the PNNI summary address (entered with the command) same as the length mentioned in the same command.


Symptom: Syntax information for routeAdd and routeDelete are missing.

Condition: Just execute any of the commands.

Workaround: Not known


Symptom: Alarms are not sync up during CWM cold start

Condition: 1. CWM cold start

2. too many alarms in switch

Workaround: None


Symptom: After pulling out one AXSM-B card, the UNI port stuck in "vc failure" when dsppnport.

Condition: Before cards pulled out, the port was already in "building vc", and the resync was going on. When card pulled out, the port went to "vc failure" which should be "provisioning".

Workaround: None.


Symptom: Connections temporarily went into mismatch condition

Condition: switchcc was executed

Workaround: None


Symptom: Memory is never freed.

Condition: Failure cases of dspconstats command.

Workaround: None


Symptom: Connection Alarm status does not get updated after cold/warm start

Condition: Connections go into fail state after doing a dnport, and if now we do a warm start / cold start and do an upport the connection still show as Fail on CWM though they are OK on the switch.

Workaround: None


Symptom: The call does not go through with exclusive VPCI and any VCI set in a setup from an NNI link. If only cnfpnportrange is used to configure max and min VPI to 0.

Condition: The call goes through if the max and min VPI is configured to 0 on the line card but does not go through if done by cnfpnportrange on PXM45.

Workaround: Configure max and min vpi on the line card rather than on the controller if the peer NNI node is sending setup with exclusive VPCI and any VCI with VPCI equal to 0.


Symptom: Line was up without any alarms

Condition: No back card was inserted. There should have been some alarms.

Workaround: None


Symptom: When the card gets reset, the core may be dumped regardless of the reason the card got reset. This might result in failure of restoreallcnf if the card or system got reset due to restoreallcnf.

Condition: The core mask is never initialized on the card and it may have some uninitialized value which triggers core dump unnecessarily.

Workaround: Use the following CLI command to check the core dump mask:

- core mask

Use the following CLI commands to set the core dump to default:

- core enable - core mask default

This will install the default core dump mask.


Symptom: The AXSM upgrade fails and the card is put in Active-F state after runrev. Alternatively, the Standby AXSM is put in failed state after loadrev.

Condition: The Standby PXM is coming up when the AXSM upgrade has been initiated and the upgrade has failed.

Workaround: If it is observed that the upgrade has failed before commitrev is given, reset the card that failed to restart the upgrade.

If it is observed that the upgrade has failed after commitrev (this is possible in the non-redundant SM case), use setrev to fall back to the version it has been upgraded from and restart the upgrade process.

In either case, make sure the Standby PXM is not in the process of coming up when the upgraded is restarted.


Symptom: ANYUSER can delcon/cnfcon.

Condition: ANYUSER level is just for checking status (dsp commands). But I found a user at ANYUSER level can do both delcon and cnfcon.

Workaround: Unknown.


Symptom: Simple commands like "dsppnports" and "dspconinfo" doesn't work for standby PXM. Then standby PXM got reset b/c tTnInTsk01 hang for 12 minutes.

Condition: Unknown

Workaround: Unknown


Symptom: Doing multiple rrtcon caused pep's fsm timer stop on PXM45.

Condition: Connection stayed in fail status and couldn't be rerouted.

Workaround: None


Symptom: File access might fail.

Condition: Some abnormal behaviors of the system that allows the same Db name to be used to perform different dataXfer connections establishing at different slots.

Workaround: None.


Symptom: SPVC state shows "IF FAIL."

Condition: In a network with both DSLAM6130 and Cisco MGX 8850, the SPVCs are in "IF FAIL" state when the DSLAM6130 is rebooted. However, they stay in that state even after the DSLAM6130 comes back.

Workaround: dnport followed by upport on the interface where the connection failed.


Symptom: dsplog on active PXM45 hangs.

Condition: This may happen when the previous dsplog command is aborted using CTRL-C. This results in a task getting deleted while holding a semaphore.

Workaround: None


Symptom: PXM45 fails to come up. If it were a Standby PXM, the dspcds on the Active PXM indicates that the Standby PXM slot is empty.

Condition: When the PXM45's console port is connected through a terminal server with echo mode turned on, junk characters come in into the console port of the PXM45. When this card is reset, the runtime image stops its initialization when it received these junk characters on the console port.

Workaround: 1. Configure the terminal server to disable the echo mode.

2. Alternatively, pullout the console port cable and reset the card.


Symptom: svcc-rcc fails to establish between the LGN.

Condition: Unknown

Workaround: None


Symptom: VSI master fills PCR(0) instead of PCR(0+1).

Condition: Whenever CBR.3 cross commits are committed.

Workaround: None


Symptom: SSIF is logging bad timer in the newly active pxm card.

Condition: switchcc is performed.

Workaround: None


Symptom: Standby pxm log error with "Error in rebuilding in spvc StandbyUpdate function at standby"

Condition: After standby reboot, and it comes up in init state, 1) when the node has large number of connections, or 2) user keep provisioning/modifying/deleting pep, or 3) when call status is changing.

Workaround: none


Symptom: Certain commands do not show up in the event log under the severe command category.

Condition: The following commands: switchredcd, restoreallcnf, clrcnf, and clrallcnf when executed to not show at severe in the event log.

Workaround: None


Symptom: Both card went to mismatch.

Condition: Add redundancy

Workaround: None


Symptom: Using CWM, the customer can not see the LAN IP address.

Condition: Unknown

Workaround: Unknown


Symptom: Under some conditions (during rebuild of the node or card), some of the provisioned connections do not get programmed on the AXSM (possibly because of a problem with the PNNI controller). This would cause a traffic outage on the AXSMs. However, this condition should have been detected at the AXSM and the dspcons should declare "mismatch" on those connections. This functionality was broken under some circumstances. This bug fix is meant to address this problem

Condition: Happens usually during a node or card rebuild.

Workaround: None.


Symptom: ssiFree logged invalid memory reference error

Condition: When failed to allocate memory for updating nodeDBs

Workaround: none


Symptom: 32k SPVCs in a 16 node network stayed in fail after upping a downed trunk

Condition: There are 15 nodes between source node to destination node, the source node is not showing the address of the destination node in the reachable address table therefore address in not found when call is setup.

Workaround: None


Symptom: When adding about 35k SPVC connections, the following msg popped up from the standby PXM monitoring terminal continuously. "qePurgeVc fails to send purge request for qe 1"

Condition: When adding/deleting a sar connection, a VC-purge command is sent to the "qe1-sar" task. Since there is no traffic on the standby PXM QE1, this "qe1-sar" task is never waken, and the VC-purge command is never de-queued and processed. When this msg queue is full, we can no longer send vc-purge command and this msg is printed continuously.

Workaround: None.


Symptom: AXSM-OC48 card goes to ACTIVE/STANDBY-F status.

Condition: Online diagnostics should be enabled for these card and burnboot or loadrev, runrev on this card causes card to go to soft fail state.

Workaround: Card get resets by itself to recover from this state.


Symptom: Getting Tlb Load Exception when bringing up a line. Unable to addport; complaining VSIS setting port fails Unable to delpart: Getting

ERR: Configure resource partition fail.

Condition: This happens after turning on debugging on AXSM card.

Workaround: Reset AXSM card.


Symptom: oc12 card got reset

Condition: Executing addport command

Workaround: None


Symptom: VPC are not routed as

Condition: Adequate BW and channels are available. Internal counter use to maintain the count for max VP connection is showing 4095.

Workaround: switchcc is performed to switchover to standby PXM card.


Symptom: Write errors on the AXSM card.

Condition: Burn a new boot on the AXSM card.

Workaround: Unknown


Symptom: Resource errors are seen on the Service Module cards.

Condition: Call release can cause all the ABR connections to send unknown or invalid ABR parameters to be sent to the Service Module causing the Service Module to go into Resource errors.

Workaround: No need for a work around. The system should recover


Symptom: One or more tasks get deleted and the services offered by those deleted tasks become unavailable. The impact on the system depends on the tasks that get deleted.

Condition: When a task throws an exception due to software failure on an Active card the its redundancy is not available (Standby card is not READY), this task may get deleted and the Active card is put into FAILED state.

Workaround: There is no workaround.


Symptom: port stuck in building vc

Condition: axsm reset or dnpnport/uppnport

Workaround: dnpnport then uppnport


Symptom: AXSM/B hardware reported Full coverage failure for offline diagnostic tests

Condition: Offline diagnostic coverage was executed

Workaround: None


Symptom: Unable to save the configuration using saveallcnf and get the following error message appears on the terminal:

"Unable to save configuration because save process is already running."

Condition: This happens when the previous saveallcnf command is aborted using CTRL-C instead of the CLI command 'abortallsaves'.

Workaround: None


Symptom: As the standby PXM coming up after loadrev on a node. Ram Sync Err occurred and the standby PXM went to Failed state.

Condition: Upgrading the node.

Workaround: None


Symptom: Running cnfcon on the AXSM does not change the frame-discard option.

Condition: Issuing cnfcon.

Workaround: Run the cnfcon and set the -frame option to be the same at both the slave and master ends.


Symptom: memPartAllocate failure

Condition: During image download to a standby PXM or an SM from the active PXM.

Workaround: None.


Symptom: On an SVC CBR.2 connection with an asymmetric forward and backward traffic, the voice traffic in the backward direction is lossy.

Condition: When a CBR.2 SVC connection is made to terminate on an UNI passing via an NNI, and if the fwd PCR(0+1) is very low and bwd PCR(0+1) is set to required value, the traffic sent across the connection on the backward direction (from called party towards calling party) will experience cell drops if the cells arrive at a rate more than the very low fwd PCR(0+1)

Workaround: Disable policing on the AXSM to prevent cell drops due to policing.


Symptom: Off-Line Diagnostics fails on AXSM-2 Rev A Cards.

Condition: The cnfdiag command will fail in AXSM-2 Rev A Cards

Workaround: Do not execute this command against Rev A Cards.


Symptom: Database corruption is seen on the active AXSM/PXM card after that active AXSM or active PXM card is reset.

Condition: When performing a clrallcnf on a non-native active disk using the shmRecoverClrallcnf command.

Workaround: Do not use the shmRecoverClrallcnf command until this problem is fixed. Instead use the sysClrallcnf command. Unlike the shmRecoverClrallcnf command, the sysClrallcnf command will leave the PXM card in the boot state after the "clear all configuration" is performed.


Symptom: OC12 fails on-line diag test 0x20200 (xbar burst) every other time. As a result, cards are put into Active-F state.

Condition: Issuing resetsys.

Workaround: Unknown


Symptom: dspcons fails on AXSM card.

Condition: user logged in at ANYUSER level.

Workaround: none


Symptom: dspcds shows an extra card

Condition: When offline diagnostics is running on AXSM

Workaround: None


Symptom: Unable to re-add one of the SPVC conns after deletion

Condition: Deleted an existing conn

Workaround: Use another vci


Symptom: Can't have more than 8 telnet sessions

Condition: Unknown

Workaround: Unknown


Symptom: Ports went into Provisioning VC during upgrade (boot burn phase)

Condition: upgrade from 2.0 to 2.1

Workaround: None

S3 Bugs



Symptom: Active PXM45 in ACTIVE-F state and standby PXM45 keeps getting reset.

Condition: Use DIP switch to inject fault to QE chip on active PXM45 and see standby PXM45 getting reset and active PXM45 in active-f state.

Workaround: None

Further Problem Description:

This is a test on special card with a DIP switch and cannot happen on the field.


Symptom: The error message:

"ERR: Absolute max cell rate must be more than 50 cells/sec",

is generated when adding a partition without a corresponding port (interface).

Condition: On AXSM CLI, try to add a partition with no port associated with that. A wrong error message (as mentioned above) is displayed.

The correct response should be "ERR: port does not exist."

Workaround: None.


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.



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.


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


Symptom: dsppnport shows its ILMI state to be undefined.

Condition: This happened on a node that was experiencing spontaneous AXSM resets.

Workaround: UNKNOWN


Symptom: CLI operational error messages are displayed on all terminals.

Condition: Other terminals are logged into the same node and they are in same card level.

Workaround: None. This only happens when multiple users are logged into the same node.


Symptom: Severity should be lowered for Non service impacting events

Condition: Perform resetsys on a node.

Workaround: None


Symptom: core command causes Tlb Exception in the 'tDbgCmdTsk.'

Condition: This happens when a core is created due to an unknown reset reason. The reset reason is shown as '(null)' in the output of the command. This condition was seen by engineering when debugging core feature itself.

Workaround: None.


Symptom: Terminal monitoring from console port can be turned off without verification to user.

Condition: User unknowingly struck control-s key sequence and blocked out CLI monitoring from console port. This was interpreted as a problem with the console port or connecting hardware by mistake.

Workaround: None


Symptom: Values less than 0 are accepted for maxvcbw

Condition: User entered cli command cnfpnportcac on the command line.

Workaround: None


Symptom: Line failure alarms did not get logged at user severity levels in event log.

Condition: Line failure alarm.

Workaround: UNKNOWN


Symptom: CTC app event handler failed messages observed in event log

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: PNNI rebuild failure messages observed in event log.

Condition: Switchover was executed.

Workaround: UNKNOWN


Symptom: Sev 4 error logs appeared in event log while doing switchcc.

Condition: Performing switchcc

Workaround: unknown


Symptom: Wrong default value for minbw in cnfpnportcac.

Condition: Execute cnfpnport and look for the syntax.

Workaround: N/A


Symptom: upln on E3 AXSM displays unnecessary messages.

Condition: upln for the first time on that bay (E3 back card).

Workaround: N/A


Symptom: FTP activity not recorded in the log (enhancement).

Condition: 2.0.13.

Workaround: None


Symptom: Command addaddr does not take "-redistribute" as an option.

Condition: Attempt to add static address

Workaround: Use "-redst" instead of "-redistribute" as the option.


Symptom: dspcons gave wrong information which is inconsistent with that dspcon showed

Condition: None

Workaround: Unknown


Symptom: wrong value of summary addr gets assigned

Condition: 1> when ever the length of pnni summary addr (entered with the command) is less than the length provided in the same command, the wrong value gets entered. 2> when length of summary addr and mentioned length are same but length is an odd multiple of 4 (e.g., 1)

Workaround: 1> keep the length of the pnni summary addr (entered with the command) larger than the length mentioned in the same command 2> keep the length as multiple of 8 and keep the length of the pnni summary addr (entered with the command) same as the length mentioned in the same command


Symptom: PXM45 logged a lot of error messages as: ssiSynchTimerCreate: Watchdog already created, watchdog Id = 82e2c770. ctc_msg_evt_handler: App evt hdlr failed, evt 22, app 1000b, evtLen 20, Switch Driver Error : spiConnAdd() line no 188: connRef=32598

Condition: Multiple controllers of the same type have been added on the same slot.

Workaround: None.


Symptom: Changing IP interfaces to is not allowed.

Condition: Attempt to delete the IP address.

Workaround: Deleting an interface is done using the default IP address of Setting an interface to have this address will cause it's disk configuration to be deleted after the next system reboot.


Symptom: An invalid port id is shown in the output of dsppnni-reachable-addr local:

aquaman.8.PXM.a > dsppnni-reachable-addr local

scope............... 0 port id.............4294967295 <==== Incorrect.

Condition: Reproducible.

Workaround: None.

Further Problem Description:

The value '4294967295' is 0xFFFFFFFF is an invalid Logical Interface Number.


Symptom: GREEN LED remains on after succession of commands: upln, cnfln (plcp), and dnln on AXSM-T3E3.

Condition: Green LED should not remain on after dnln command is issued.

Workaround: Issue upln, dnln.


Symptom: Request new command to provide mapping between LIN (=ifIndex) and physical descriptor.

16979970 <=> 3:1.2:2

Condition: Reproducible.

Workaround: N/A


Symptom: Add slave end on a node. Attempt to add slave connection on remote end with the NSAP address obtained from local node.

Condition: Attempt to add slave connection with -slave option.

Workaround: Only add master connections with slave option.


Symptom: IPC does not have ipcHelp command at the shell.

Condition: None.

Workaround: None.


Symptom: dalCOnnIdShowByVpci doesn't output the proper information.

Condition: For connections that are on the 2nd bay, dalConnIdShowByVpci shows incorrect port/slot information on those connections.

Workaround: None.


Symptom: Booking factor set by CWM does not create a log entry. It creates a two line message on the screen.

Condition: 2.0.13 and CWM 10.4 FCS Patch 1.

Workaround: Unknown.


Symptom: Pop up messages on CLI screen.

Condition: Router end of SVC releases before PXM45 end.

Workaround: N/A


Symptom: "0" is not printed in the dsppnni-ptse -detail true.

Condition: Whenever an address is added with format of 0x as the last two digits the "0" is not printed in the dsppnni-ptse -detail true.

Workaround: None.


Symptom: Via Node does not send a Crankback IE in release to source node after trying 3 the parallel PNNI links and getting crankbacks on them.

Condition: This occurs when the number of crankbacks on parallel PNNI links with SEB hits the max_crankback limit configured on the port.

Workaround: Increase the max_crankback value through CLI.


Symptom: According to one of the customers, the following objects are not being utilized in the ATM virtual interface MIB:

caviStatEgressEntry and caviStatIngressEntry.

Condition: The port level statistics can only come from the QE, and the QE does not collect OAM, RM and EFCI detail. Some of them may be configured to have valid values, however it would be limited to debug statistics that have a limited number of ports and connections that may be enabled at one time. So, the answer is that those objects that are hardcoded to 0, should be unsupported.

Following objects are unsupported instead of value of 0:






Workaround: None.


Symptom: commitrev allowed to execute when upgrades have failed.

Condition: Execute on standalone card before the card gets to the active state.

Workaround: Watch the card state and the state of the upgrades before executing the commands.


Symptom: Need to change module ID for path trace log and impose no limit.

Condition: 2.0.13.

Workaround: Unknown.


Symptom: delallcon command should prompt for confirmation before execution.

Condition: Execute command on the interface with large number of connections.

Workaround: Use caution when executing this command.


Symptom: Cannot run command 'optrt' if scheduled route optimization is configured.

Condition: Message: "ERROR: Route optimization already enabled on this port, disable first (using cnfrteopt) to use force reroute (optrte)" appears when running optrte command if scheduled route optimization is present as displayed with the command dsprteoptcnf.

Workaround: Remove scheduled optimization with command cnfrteopt <portid> disable, run optrte, and re-config scheduled route optimization if required with desired options in cnfrtopt.


Symptom: switchapsln 1 (clear) gives wrong error message by saying switch failed when actually the switching was finished successfully when either the working line or the protection line was in alarm.

Condition: This happens all the time.

Workaround: Unknown


Symptom: When more than 4 parameters are passed into SSI_TRACE api, it cause core dump

Condition: Anytime user turn on trace option.

Workaround: No workaround.


Symptom: Trying to crankback at the destination end for a SPVC slave.

Condition: If there is a problem with connection establishment at the destination node, currently we crankback for SPVC connections at the destination.

Workaround: Unknown


Symptom: cnfclkrsc display does not show the portid option.

Condition: On issuing a cnfclkrsc command, the parameters for portid are shown, but the option <portid> is not shown.

Workaround: None.


Symptom: Node gives many card errors during normal operation.

Condition: Normal operation.

Workaround: N/A


Symptom: diagdebug command doesn't give error message for wrong parameters.

Condition: Execute diagdebug command with out of range parameter or insufficient argument.

Workaround: make sure the arguments are correct.


Symptom: Connections are not committed by the controller.

Condition: Unknown

Workaround: Unknown


Symptom: AXSM underwent a software error reset

Condition: Switchcc was executed on PXM

Workaround: UNKNOWN


Symptom: CLI commands addcon and dspcon show frame discard feature configurability yet functionality is not available.

Condition: User has "-frame" option available on addcon and "Frame Discard" shown on dspcon. This feature is not available.

Workaround: none


Symptom: LED is green on AXSM faceplate even if dsplns shows that the line is in critical state (LED should be red).

Condition: Can happen randomly.

Workaround: Ignore LED. dsplns shows the correct state


Symptom: Node gives many card errors during normal operation

Condition: Normal Operation

Workaround: N/A


Symptom: Unequipped path alarm is not detected on AXSM.

Condition: None

Workaround: None.


Symptom: ACO does not shut off audio alarm.

Condition: Customer notes ACO does not shut off audio alarm properly. Audio alarm returns after about 15 seconds without the presence of any new alarms.

Workaround: None


Symptom: Ambiguous response from conntrace command.

Condition: CLI returns varying response on conntrace command depending on what point conntrace is initiated on spvc.

Workaround: NONE


Symptom: When dspconinfo CLI issued on both active and standby PXM45 cards, the connections on the standby controller card would be in fail state whereas the connections on the active controller card would be in active state.

Condition: When the connections are rerouting on an active controller card, the UNI card that has SPVC endpoints provisioned, is reset using "resetcd <slot>" CLI command.

Workaround: Avoid executing resetcd <uni slot> when there are reroutes happening on the active controller card.

Additional Information:

To find if reroutes are happening, execute dspconinfo CLI command on active PXM45 repeatedly and see if connections are in stable, active state (no reroutes) or NOT (reroutes are happening).


Symptom: The ip port on active pxm is up and running. After switchover, the ip connectivity is lost on newly active due to bind control-vc fail

Condition: switchover cause ip port to fail on newly active pxm

Workaround: dnpnport and up the port again after switchcc

Known Anomalies found In Previous Releases

The following anomalies were identified in previous releases. There bugs were either closed, determined not to be a problem, duplicated to another bug, or marked as un-reproducible. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.


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


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


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


Closed -- not a problem.


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


Duplicate of CSCds27372, which is fixed in 2.0.11


This bug is now assigned by the CWM group


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


Un-reproducible Sysbootchange Init Parameters Corrupted


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


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


Duplicate of CSCds87902 - this is a CWM bug.


Closed -- not a problem.


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


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


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


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


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


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


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


Closed -- some of the hardware was missing.


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


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


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


Un-reproducible Redundant PXM45 remained in i-state after node reboot


Closed - not a problem


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


Closed -- incorrect connections were being used on the modems


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

miss, fixed in an earlier release.


Un-reproducible pnports went down after PXM45 runrev during 2.0.12 upgrade


Un-reproducible SLT: Cause RcvCount XmtCount repetitively displayed.


Un-reproducible DAX connections stayed in conditioning after interface recovered


Closed - not a problem


Duplicate of CSCds90343 Residual Connection OAM Traffic After Con Deletion -fixed in 2.0.12.


Closed - not a problem.


Duplicate of CSCds33855 Corruption of event log file


Un-reproducible PXM45 fails to go standby


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


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


Closed - not a problem.


Closed - problem with the hardware.


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


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


Un-reproducible axsmred:Database mismatch between standby and active PXM


Un-reproducible Card Summary displays incorrect details


Un-reproducible Core dump - watchdog timeout reset


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


Closed - not a problem


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

redundant cards - fixed in 2.0.11


Closed - user error.


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


Closed - not a problem.


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


Closed - not a problem


Duplicate of CSCdt38628 dspbecnt shows wrong info for an APS line - fixed in 2.0.14


Un-reproducible AXSM spontaneously reset


Closed - not a problem.


Un-reproducible emVsiRamHwRsrcPart error on standby AXSM


Un-reproducible CBR SPVC discarding 50 % of its data


Un-reproducible AXSM spontaneously reset during data transfer tests


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


Un-reproducible - PXM swicthover causes critical alarm on the AXSM


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


Closed - not a problem.


Un-reproducible Upg:EM database consistency error during AXSM resync


Closed - not a problem.


Duplicate of CSCdt14045 ERR:Could not get LCN and data txfer stops after AXSM reset problem


Un-reproducible OC12 AXSM does not implement REI-L (M1) byte


Duplicate of CSCds03436 call to remove () file-1-01-Gen-080220001615 failed - fixed in 2.0.12


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


Closed - Spurious environmental alarms for DC supply reported


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


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt43371 OC48 APS switchapsln/switchred get chan mismatch/sig fail low - fixed in 2.0.14


Closed - not a problem


Un-reproducible - Core dump occurred on one of two PXM45s.


Un-reproducible - Several ports go to ILMI query after PXM45 switch over


Duplicate of CSCdt07366 Pnport goes to building vc state after del. Y-red and PXM45 switchover - fixed in 2.0.14


Un-reproducible - After power cycle the node got reset again


Closed - not a problem.


Closed - not a problem.


Closed - not a problem.


Un-reproducible - Switch sends trunk major alarm trap even though the trunk is ok


Closed - not a problem


Closed - not a problem.


Un-reproducible - BPX interop- APS alarms do not clear when alarm is removed


Closed - not a problem


Closed - mini backplane was inserted incorrectly


Closed - not a problem


Closed - not a problem


Duplicate of CSCdt79626 SLT: OC12 1+1APS not W nor P-line displayed repeatedly


Closed - not a problem.


Closed - not a problem.


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt58554 Modify APS Event Log to make it more user-friendly.


Un-reproducible - AXSM Card is in failed state.


Duplicate of CSCdt56312 APS intermittently fails to switching on OC48/OC3 (BI&NREV)


Closed - not a problem.


Moved to MGX1.


Un-reproducible - Active PXM45 card in slot 7 was not responding and showed a major alarm with red LED.


Duplicate of CSCdt91237 1+1APS; dsplns had Critical/Major alarm, but dspalm was Clear - Fixed in 2.0.14


Closed - not a problem.


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt56312 APS intermittently fails to switching on OC48/OC3 (BI&NREV)


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt93669 - CWM bug


Closed - not a problem.


Duplicate of CSCds43034 Flt.Ins/SRAM failure-popup message appeared on cli - Fixed in 2.0.12


Duplicate of CSCdu21625 Enable Humvee HMM on PXM45 card - Fixed in 2.0.15


Closed - not a problem


Closed - working as designed.


Closed - not a problem.


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt41956 SAR failure/ssiFrameXmt failure error msgs in event log on switch


Closed - not a problem.


Closed - not a problem.




Closed - not a problem.


Fixed in CWM 10.4.01


Duplicate of CSCdt67109 Wrong value of summary address gets assigned - fixed in 2.0.15.


Duplicate of CSCdt78030 An invalid port id is shown in the output of dsppnni-reachable-addr local - Fixed in 2.0.15


Duplicate of CSCdt57525 APS OC3 back card remove/insert caused protection chan stuck signal fail


Duplicate of CSCdt43371 switchredcd caused pnports to fail temporarily


Closed - not a problem.


Closed - not a problem


Duplicate of CSCdu26664 connections failed to route after node rebuild. Fixed in 2.0.15


Closed - not a problem.


Closed - not a problem.


Duplicate of CSCdt40561 SPVCs failed after upgrade due to cross-commit fail - fixed in 2.0.14


Closed - not a problem.


Unreproducible- Failed to cc to AXSM cards


Closed - hardware was not inserted properly.


Duplicate of CSCdt79310 AXSM pair reset resulted in min Guar CR = Max CR/conn failures - Fixed in 2.0.15


Duplicate of CSCdu26030 32k SPVCs stayed in fail after down/up trunk - Fixed in 2.0.15


Duplicate of CSCdt91237 1+1APS; dsplns had Critical/Major alarm, but dspalm was Clear - Fixed in 2.0.15


Duplicate of CSCds52595 trapClTask keeps logging Invalid Ptr Messages - Fixed in 2.0.14


Un-reproducible - OC3 1+1APS; R&R BC caused the Tx&Rx K1K2 sent to the wrong line


Closed - not a problem


Closed - problem with the hardware.


Fixed on MGX1.


Un-reproducible - Locally switched connections take in-ordinate amount of time to come up after software upgrade.


Closed - not a problem


Closed - configuration problem.


Closed - not a problem


Duplicate of CSCdt95005 - OC3 1+1APS; Wline auto switch failed after Wline BC removed - Fixed in 2.0.14


Duplicate of CSCdu20428 - VSI master fills PCR(0) instead of PCR(0+1) - Fixed in 2.0.15


Un-reproducible - dspcons and dspcon on AXSM gave wrong information about the connection after multiple switchredcd on AXSM T3/E3 cards.


Closed - replace the hardware.


Closed - not a problem


Closed - not a problem


Closed - not a problem


Duplicate of CSCdt95005 - OC3 1+1APS; Wline auto switch failed after Wline BC removed - Fixed in 2.0.14


Duplicate of CSCdu26664 - Connections failed to route after node rebuild - Fixed in 2.0.15


Un-reproducible - Addr not flushed in reachable_addr


Duplicate of CSCdu27378 - loadrev,runrev on AXSMOC48 causes card to go to ACTIVE-F status - Fixed in 2.0.15


Closed - working as designed


Duplicate of CSCdu26664 - Connections failed to route after node rebuild - Fixed in 2.0.15

Problems Fixed in Release 2.0.14

Bug ID
S1 Bugs


Symptom: Card getting reset or losing the ingress bandwidth.

Condition: Connection deletes or deroutes.

Workaround: None


Symptom: SCM retry messages on screen and all AXSMs and standby PXM45s in failed state.

Condition: qe overflow problem.

Workaround: None


Symptom: Standby controller card goes to failed state.

Condition: Upon performing loadrev after a clrcnf.

Workaround: Do a setrev on slot 14 (for SES) or slot 32 (for MGX 8850) with version number 0.0.


Symptom: SPVCs derouted on newly active PXM45 card.

Condition: This problem is found after runrev.

Workaround: Waiting for all the connections to be rerouted.


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: None.

Additional Information:

To recover from the problem, execute dnpnport followed by uppnport.


Symptom: Standby PXM45 resets.

Condition: Execute the runrev command on a single AXSM.

Workaround: None


Symptom: dsppnports CLI on PXM45 card does not show the output.

Condition: On executing dsppnports on PXM45 card, pnCcb task got suspended.

Workaround: None


Symptom: Traffic doesn't flow out of E3 back card.

Condition: E3 backcard defaults to loopback upon upln.

Workaround: None.


Symptom: On a AXSM bring up, the corresponding PNNI ports may show "provisioning."

Condition: When AXSM comes up, the VSIS may not be able to have the ports added properly if the fault management task comes up before CEMA. This would cause the VSIS not reporting those ports to the PNNI controller.

Workaround: None


Symptom: The port on which SPVCs were provisioned ran out of bandwidth during a card rebuild scenario. It is unclear at this point as to why this happened. It has something to do with the non-default booking factor provisioned on the controller. After resetting the card, the problem did not reappear.

Condition: This problem was observed when upgrading the AXSM from 2.0(11.3) to 2.0(12.0).

Workaround: Reboot both the active and standby AXSM to force a rebuild. In case of a non-redundant configuration, reboot the non-redundant AXSM.


Symptom: Data transfer interrupted when switchredcd executed.

Condition: switchcc and switchredcd executed with an LOS condition on one APS line.

Workaround: UNKNOWN


Symptom: AXSM underwent a software error reset.

Condition: switchcc was executed on PXM45.

Workaround: UNKNOWN


Symptom: NNI port stuck in admin state up and interface state down. IFC_DOWN.

Condition: After configure pnportcac bookfactor to 20% for T3 trunk.

Workaround: Disable VSI partition on BXM and then re-enable it.


Symptom: APS protection channel stuck in signal fail.

Condition: Remove and insert of back card caused protection channel to stick in "signal fail."

Workaround: resetcd on active AXSM.


Symptom: SPVC connections did not route after node upgrade.

Condition: Upgrading the node.

Workaround: None


Symptom: Standby AXSM stuck in INIT state. Repeated resets of the standby card does not help getting the problem resolved.

Condition: Specific events causing this condition unknown. Sometimes, when the standby reboots it gets stuck in Init.

Workaround: Need to reboot both the active and standby cards.


Symptom: Pnports stayed in building VC/VC failure after upgrading the AXSM bootcode.

Condition: After upgrading the AXSM bootcode from 2.0(27) to 2.0(42) the pnports remained at building VC status.

Workaround: None


Symptom: Node started rejected CLI commands.

Condition: Execute commands dsppnports and dsppnni-link

Workaround: None


Symptom: Standby card goes Init state after upgrading the bootcode and active AXSM card stays at Active-F state.

Condition: Upgraded the AXSM boot code from 2.0(27) to 2.0(42).

Workaround: Remove the front and back cards and re-insert them.


Symptom: Standby card goes Init state and Active AXSM card stays at Active-F state.

Condition: Upgraded the AXSM boot code from 2.0(27) to 2.0(42).

Workaround: Remove the front and back cards and re-insert them.


Symptom: pnCcb causes system reload on processing crankbacks with max_crankbacks value changed by configuration on ports.

Condition: If the max_crankback configured on the egress port is less than what is configured on the ingress port on which the SVC trying to crankback was setup.

Workaround: Keep the max_crankback same in the node, or keep the egress max_crankback value more than ingress side.


Symptom: Nativity check is skipped on power up.

Condition: Node reboot, bring up of any controller card as active.

Workaround: None.


Symptom: PNNI link went to 'building vc' failure right after changing cables.

Condition: unknown

Workaround: Unknown


Symptom: Card configuration is not restored after a clrallcnf with restoreallcnf.

Condition: Did a clrallcnf on the node and did a restoreallcnf, and the configuration is not restored as the card on which the saveallcnf and restoreallcnf was done came up as standby instead of active mode.

Workaround: None


Symptom: Standby AXSM of a redundant AXSM-OC3 pair alternates between BOOT & INIT mode after a burnboot process and never comes active. Also the standby PXM45 reset and remained in INIT mode for a long time before coming to standby again.

Condition: Using the burnboot command.

Workaround: Unknown


Symptom: When cong_display command is executed "outStanding status enquiry congestion" is persistently on.

Condition: An edge node that had SPVC connections routed via this node was rebooted.

Workaround: None.


Symptom: Load exception error occurred which changed the PXM45 to Fail state which resulted on PXM45 to oscillate between two PXMs.

Condition: Performed switchcc on one node. This happens when there are SPVC provisioned on the IISP port and there are active SPVC calls going through the IISP link.

Workaround: Remove SPVC endpoints on the IISP port.


Symptom: Upgrade to image causes system reload while the new image is trying to go active.

Condition: This happens when the interfaces keep on going up and down rapidly during congestion and a lot of connection status enquires are taking place.

Workaround: Unknown


Symptom: Port stuck in building VC state.

Condition: Egress connection ID programming failure.

Workaround: None


Symptom: Some of the lines display a signal failure.

Condition: Any switches thereafter will not work.

Workaround: Do a lockout of protection line and then clear it.


Configure at least one side as 1+1 uni directional.


Symptom: The node was completely hosed and no one could log in.

Condition: When there are very few resources during a crankback, the alternate routing also cranks back, resulting in a recursive crankback. During this operation, there is a memory leak and over period of time the system runs out of memory.

Workaround: switchcc to the standby if available. If its a standalone node, no workaround except to go around the reason for crankback.


Symptom: switchredcd causes both cards to reset and stay in "Init" state for about 30 minutes before they come back.

Condition: Doing switchredcd a number of times on AXSM redundant pair with APS and ILMI enabled will reproduce the problem.

Workaround: None.


Symptom: Port went to "building vc" state.

Condition: Large number of connections routed through the trunk. dnpnport and uppnport.

Workaround: N/A


Symptom: PNNI tries to route a new call using a VPI/VCI pair that has already been assigned to an active call over the PNNI trunk.

Condition: UNKNOWN

Workaround: resetsys would have to be issued to clear this condition.

S2 Bugs



Symptom: When a user polls the switch using CWM, 'cwspOperUniType' returns 'zero', this value is not part of the enum defined for this MIB variable.

Condition: When 'clock only' ports are added to the controller, these ports are displayed as part of dsppnports command. The sub-agent also returns these ports to a user polling the switch. Since these ports are not 'pnports', the values of the variables associated with these ports are not correct.

Workaround: There is no work around for this right now.


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.

Condition: 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, sometimes 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 up the system.


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.


None But dncon and upcon will recover the connection.


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

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

Workaround: None


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

Condition: 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.


Symptom: When resetcd command was given, unexpected system reload was observed.

Condition: unknown.

Workaround: Unknown.


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

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


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


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

Condition: None

Workaround: None.


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

Condition: None

Workaround: None.


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: switchredcd command is executed

Workaround: N/A

Additional Information: All popup messages have been removed by default. If you want to trace them, you can turn trace on for VSIS and EM popup messages or enhance the trace level for APS popup messages


Symptom: Node alarms reported on and nodes with switching alarms being the source

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

Workaround: UNKNOWN


Symptom: SPVCs stayed in conditioning state

Condition: The node terminating the master end of one of the two failed SPVCs was rebuilt

Workaround: UNKNOWN


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.


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


Symptom: Severe clocking events are shown as info type of events

Condition: Configuring clock sources and failing the clock sources

Workaround: None


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


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


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 comes up


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.


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


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


Symptom: After setrev to downgrade from 2.1.x to 2.0.x we see checksum mismatches between the PXM45 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


Symptom: Port stuck in building vc

Condition: Power off/on or reset node

Workaround: Issue dnpnport portID then uppnport portID command


Symptom: PXM45 failed its nativity check.

Condition: Can't give up mastership Fault Insertion test was being conducted.

Workaround: UNKNOWN


Symptom: PXM45 failed its nativity check.

Condition: Can't give up mastership Fault Insertion test was being conducted.

Workaround: UNKNOWN


Symptom: Crossbar fabric and card crossbar alarms reported

Condition: 'Can't give up mastership' fault insertion tests were being conducted

Workaround: UNKNOWN


Symptom: CAC is set for ABR for 2%. Have 2 connections big PCR CBR connection and ABR connection. If CBR is routed first, then ABR con is not able to route.

Condition: ABR connection is not routed due to no bandwidth although PNNI has enough bandwidth

Workaround: dncon on the CBR connection rrtcon on abr upcon on the CBR connection


Symptom: Dax connections go into failed state.

Condition: When upgraded from 2.1(0.15) to 2.1(0.30).

Workaround: Down one of the PNNI port and up again.


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.


Symptom: Last user request field implementation needs to be understood

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Able to add 2 master to the same slave endpoint for dax connections. Also, this will lead to dspcons mess-up

Condition: add slave endpoint

add master endpoint to slave endpoint nsap address

add another master endpoint (with different vpi vci) to the same slave endpoint nsap address and vpi vci

Workaround: None


Symptom: Bulk configuration file keeps growing.

Condition: When SNMP manager tries to save SNMP config file, it loops on MIB walk

Workaround: Delete all connections with vci=65535


Symptom: VBR3 and UBR2 routed SPVC connection remain in FAIL state. Dspcon on that connection shows "Unsupported combination of traffic parameters" as the Last Fail Cause.

Condition: If frame discard is requested on the VBR3 or UBR2 SPVC connections (via addcon/cnfcon), then these connections fail to route.

Workaround: Do not program frame discard on pep (addcon/cnfcon with frame discard disable).


Symptom: cli command dnpnport/uppnport of nni port timeout. pnRedman was busy sending to standby while the standby is in failed status showing in dspcds. syncRam shouldn't allow application (pnRedman) to send to standby when standby is in failed status.

Condition: The MGX(p2spvc4) node has a 100k SPVC routed connections.

Workaround: unknown


Symptom: pnport went into vc failure state

Condition: setrev was executed on AXSM

Workaround: None


Symptom: dspapslns shows wrong info

Condition: when crossover happens

Workaround: none.


Symptom: dspbecnt shows wrong info.

Condition: Always.

Workaround: None.


Symptom: Syntax for the command routeNetAdd failed

Condition: At the cli prompt type the command

Workaround: None


Symptom: The port stays in AutoConfig.

Condition: Somehow the Qe48 hardware get stuck and ILMI (or any other app using Qe48_sar) cannot send PDUs. reasons could as follows: There were some known issue (before metal fix) in Qe48sar that if a Cell is there for extraction, the software has to extract the cell first and then do any other thing as hardware statem/c will be stuck till the present images cell_extraction is done on ISR. this can mean that HW failed to raise a ISR when cell came in or software got the ISR but failed to clear the cell injection.

Workaround: first we need to confirm that its same problem. we can find out by using "dspilmicnt " on cli and qe48sarStatsShow on shell. 1)run qe48sar_cell_extract_from_hw on the shell. 2)reset the card


Symptom: Connections as displayed by CWM are incomplete. Modifications on the connections don't show up on the CWM GUI. Connections exist on the switch and don't show up in CWM.

Condition: This can happen when there is a high volume of traps, for example when a script is being run to delete a large volume of connections.

Workaround: A configuration upload could be done to correctly synch the CWM with the switch after the script has finished.

Another work around is, if a user need to add/delete more than 1000 connections at one time, he/she should pace the SPVC connections add/delete rate to avoid trap overflow. The recommended rate is 1 connection/sec.

Further Problem Description:

When there is a high volume of traps, especially on an SES node, traps can be silently discarded by the switch after a burst of about 1000 traps has been generated on a given card.


Symptom: SAR frame transmit failed and ssiFrameXmt failed error messages are recorded in event log

Condition: Switchcc executed every 8 min

Workaround: UNKNOWN


Symptom: switchredcd caused pnport to fail temporarily

Condition: One of the APS lines was in LOS

Workaround: UNKNOWN


Symptom: from dsppnports, there are failed three SPVC connections at both orion node (svcpop2) and mgx node(p2spvc4).

Condition: Both Orion node svcpop2 and MGX node p2spvc4 have redundancy cards and multiple PNNI interfaces. About 99K SPVC connections are configured and routed on the node. Upgraded the FW to 1.1(50.44)A and system went to reset. After reset system, the SPVC connections start to reroute. Once finished rerouting, there are still three connections failed.

Workaround: UNKNOWN


Symptom: Sev 4 'Nodal data in disk mismatch with RAM data' message appears in event log

Condition: Clock sources were deleted or re-added and switchcc executed

Workaround: None


Symptom: cnfapsln on protection line doesn't change all the parameters.

Condition: Configure intra card 1+1 APS and attempt to configure the parameters on Protection line.

Workaround: N/A


Symptom: Event log files are not ordered in chronological order

Condition: on a redundant node, as a card comes up in standby mode. The file number sequence is off.

Workaround: none.


Symptom: issued a switchcc, display log shows error,scmproccardinsertremovemsg unknown slot 23.

Condition: Customer did a switchcc, dsplog shows this error. 08-00137 02/06/2001-18:09:43 SCM-5-UNKNOWN_VALUE tSCM 0x8022442c <scmProcCardInsertRemoveMsg> unknown slot 23 - 24 dropped

Workaround: None


Symptom: Route Op Start/Stop messages are dropped incorrectly.

Condition: None

Workaround: None


Symptom: dbgcon command is available at cli level and should be removed

Condition: Not applicable

Workaround: UNKNOWN


Symptom: Policing does not work with ABR CDVT.

Condition: Policing works with all traffic classes except ABR. Changing CDVT does not change anything.

Workaround: None


Symptom: Execute testdelay on a connection for multiple times.

Condition: On SPVC connection execute tstdelay multiple times.

Workaround: For successful tstdelay we need to try few times.


Symptom: APS switching fails intermittently. Sometimes APS won't switch back from P-W, sometimes APS switched okay but false alarm message was display "Warning: Switch Unsuccessful on Line: Due To Some Unknown Reason."

Condition: switchapsln manual (W-P) then Force (P-W)

Workaround: None


Symptom: IP Connectivity to the node fails. Any new ports will not have their Control VCs coming up.

Condition: The VCM VC Table incorrectly shows no more free entries. This causes all new Control VC Allocation to fail.

Workaround: None


Symptom: CLI does not warn users that port policy configuration changes made via the cnfpnportcac command will apply to existing connections

Condition: cnfpnportcac command is used when connections have already been provisioned

Workaround: UNKNOWN


Symptom: Trap 60078 (cwCoreCardSwitch) was sent with cwTrapSlotNumber and cwTrapIndex in reversed order so old active slot number would be wrong.

Condition: The trap is sent after a PXM45 switchover.

Workaround: None.


Symptom: dspalmcnt does not count number of RcvRai alarms on ds3 card.

Condition: If physically there is remote alarm indication (Rai) shown in dspalm -ds3 dspalmcnt will not show the count increase.

Workaround: None.


Symptom: Resource allocation after the AXSM gets reset.

Condition: Resource usage on the endpoint of the NNI link is different.

Workaround: None



addcon, dspcons, dspcon, delcon, cnfcon are only available at the

CISCO_GP access level.

Condition: Commands are available on AXSMS.

Workaround: You must log in as cisco to access these commands.


Symptom: PXM45A resets from init state.

Condition: When resetsys was given on the node.

Workaround: None.


Symptom: Virtual trunks on AXSM T3 card were not coming up even the relative spvp connections were added and out of alarm.

Condition: did not find similar problem on AXSM OC3 card

Workaround: None


Symptom: Added two DAX SPVCs thru CLI, slot 1 interface 1 & 3. Line 1 has local loop and Addtech testset is Connected on line 3. Line 1 & 3 do not have any alarms but SPVCs are showing E-AisRdi alms. One shows alarm on interface 1 & the other on interface 3. Addtech is not Transmitting any data on line 3.

Condition: The dax connection is: to The reason that is in E-AIS/RDI alarm is because is incorrectly generating seg AIS towards the ingress direction. Currently, we suspect that the AXSM made the decision to generate AIS because the use of un-initialized information in the database.

Workaround: None


Symptom: During switchcc, the ATM interface loses connectivity to router.

Condition: First router entry in IPCONN database is null.

Workaround: Before switchover, make sure first router entry in not null. To do this:

1. delete any router entry 2. re-add any router entries


Symptom: Control VC stays in attempt states. QE SAR shows discards/errors on the GLCN.

Condition: We suspect that QE VC queue is not purged when the connection is deleted. It causes the cell memory leak in QE. Pretty soon the cell memory will reaches the threshold so the incoming cell will get discarded.

Workaround: switchover to standby


Symptom: Crankback IE not sent to the originating node when max_crankback is changed by configuration on the via node.

Condition: This happens when the egress max_crankback value and ingress max_crankback value differ on the via node.

Workaround: keep ingress and egress max_crankback values same on the ports on the via node.


Symptom: Runrev on a AXSM blocked after loadrev with reason that there have been disk updates.

Condition: Upgraded an OC12 card with approximately 50VTs and feeder connected.

Workaround: Reset the Standby card or abort the revision and attempt upgrades again.


Symptom: Rerouting of connections causes messages to be logged under SPVCM_INFO

Condition: rerouting of connections

Workaround: None


Symptom: One will see following line repeatedly 5.1.2 not W nor P-Line for 0x81918a88

Condition: switchredcd was executed

Workaround: logout from the session and login again.


Symptom: Rerouting of connections using rrtcon causes some connections to take a long time to reroute.

Condition: rerouting of connections using rrtcon

Workaround: None


Symptom: Connection still exists on the port that was admin down on AXSM (i.e., dnport).

Condition: When dnport command is issued, AXSM should delete all connections on that interface. However, while deleting the connection, if any error occur to a particular connection, the function exits prematurely leaving the rest of the connection undeleted.

Workaround: None.


Symptom: During resync, RM connection delete may fail.

Condition: When processing the resync end command, if a "to be deleted" connection is in CmtPendCd state, the RM delete may fail because TCB was not updated properly.

Workaround: None.


Symptom: The connections go into fail state.

Condition: After performing numerous dnport/upport/switchredcd on a AXSM, the connections may go into fail state.

Workaround: None.


Symptom: As per design, the dspln shows "major" just to alert the user that one of line is bad. But it is not service affecting. Traffic is flowing.

Condition: None.

Workaround: None.


Symptom: Intraslave connection commit failed. Condition: When committing a connection from (A,0) to (A,B) where A and B are endpoints on the same card, if commit B failed, the hardware programming are not always backout properly (i.e., a dangling egress conn id of B may be left in the hardware).

Workaround: Perform a switchover if standby AXSM is available.


Symptom: On an OC-48 card with Y-red cable configured with links, without APS, a switchred from the primary to secondary card, whereby causing the secondary card to go active, would cause the link to go down. This only occurs when the mini-backplane is installed.

Condition: The condition or result of this is that the link would go down.

Workaround: Remove the mini-backplane if there is no APS configured.


Symptom: Connection delete failed on standby

Condition: When massive connection deroute/reroute take places at the same time when standby is coming up, connection delete on standby may fail due to Ingress conn id delete failure.

Workaround: None.


Symptom: When dspapsbkplane command is used

Condition: Sometimes the command does not display the correct value when the line is in alarm

Workaround: None


Symptom: Connection delete failure was reported on AXSM.

Condition: When connection deroute fails for a given endpoint, subsequent connection delete on the endpoint may also fail, leading to VSI/RM connection info mismatch.

Workaround: None.


Symptom: Connection commit failure is reported by AXSM.

Condition: When derouting a connection, if the controller deroute by setting the PRI endpoint to NULL (i.e., from (A, B) to (0, B)), the connection deroute may fail.

Workaround: None.


Symptom: All interrupt are disabled while adding intra-card APS lines.

Condition: Under this situation, if config the apsln to be bi-directional, it still operates at uni-directional mode, and if the other end added as inter-card APS line, sometimes, both forced and manually switchapsln do not work.

Workaround: Developers are working on this problem.


Symptom: Connection deroute fails on the AXSM.

Condition: When controller deroute a connection in the commit pending on committed state (i.e., when controller deroute a connection BEFORE it receives a response from the slave for the previous connection commit on the same endpoint), the connection deroute request may fail.

Workaround: None.

S3 Bugs



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.


Symptom: Standby PXM45 gets reset by Active PXM.

Condition: Rerouting is going on massive scale, we have SPVC journaling also at the same time and user executes provisioning commands which requires disk writes and standby journaling updates. At that time sometimes standby is reset by active pnRedman.

Workaround: When massive rerouting is going on avoid too many provisioning commands on the system.


Symptom: Port goes into Building VC.

Condition: When configuring the signaling parameters for a given port. If sigvci and rccvci have been changed and then brought back to their default values of 5 and 18 respectively, the port may go to Building VC occasionally.

Workaround: Down the port and up the port should bring the port to UP again.


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.


Symptom: SPVC are allowed to be added on failed PNNI interface

Condition: addcon on failed PNNI interface

Workaround: Don't add SPVC on failed PNNI interface


Symptom: Debug messages are displayed as Error messages in log file

Condition: With ABR calls and vsvd 0

Workaround: none


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.


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.


Symptom: The display of the address filter does not contain the address in some cases.

Condition: This problem will arise when combinations involving prefixes, * or addresses beginning with ... are entered. The filtering action will take place correctly. However, the display is not correct.

Workaround: None.


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


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


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.


Symptom: dsperrs on PXM45 displays pnCallaudit error entry when burning new boot on the card.

Condition: The error is logged while burning the new boot on the PXM45 card.

Workaround: Unknown


Symptom: 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.

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


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

Condition: Normal Operation

Workaround: None


Symptom: Diagnostics tests configured with cnfdiag and shown with dspdiagstat do not show passed diagnostics tests. Output only shows number of test iterations and failed results.

Condition: Customer configured diagnostics tests using cnfdiag. Test results were then viewed with dspdiagstat. Results did not adequately show the passed cases.

Only number of iterations and failures are shown in the output.



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

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


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.


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


Symptom: APS mini-backplane warning message displayed after APS was deleted and the mini-backplane was removed.

Condition: Installed the mini-BP, added APS line. Deleted the APS line, removed the mini-BP.

Workaround: None.


Symptom: The event log entry is misleading when SSCOP is disabled.

Condition: disablesscop command executed on a port.

Workaround: None.


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 PXM45 switchover may resolve the ethernet connectivity issue.


Symptom: 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 ""

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

Workaround: If both PXM45 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.


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.


Symptom: dspxbaralm and dspxbaralms commands have same functionality.

Condition: Use of cli

Workaround: UNKNOWN


Symptom: dspcon command presented an error message on cli

Condition: It was executed on a standby AXSM card

Workaround: UNKNOWN


Symptom: Tstsdelay on popeye2 should be blocked for the connection which terminates on a feeder node.

Condition: tstdelay command on a popeye2 node.

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


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

Condition: 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.


Symptom: After switchred on AXSM, dsplog shows that call to ctcAppActiveReadyconfirm() fails

Condition: The first call to the function goes through but the second call fails but the second call is not required anyway.

Workaround: This is not a service affecting bug.


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.


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


Symptom: When PXM45 boot up, it displays the PXM45 card banner instead of the product MGX 8850 or MGX 8950 banner.

Condition: PXM45 card banner does not correctly represent the product name.

Workaround: none


Symptom: Intuitive error message when connection is added on an existing endpoint

Condition: When connection is added on an existing end point

Workaround: Don't try to add a connection on an existing end point


Symptom: Interface go down after deleting AXSM redundancy

Condition: Delete AXSM T3/E3 redundancy

Workaround: Remove standby AXSM Y-cable before delete AXSM redundancy


Symptom: CLI commands provide no functionality: cnfnddebug and dspnddebug.

Condition: UNKNOWN.

Workaround: UNKNOWN.


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.


Symptom: CLI cnfspvcprfx is confusing

cnfspvcprfx [-prfx] where -prfx is mandatory not optional

the bracket should be removed

Condition: do either

cnfspvcprfx -prfx 20bytes address


cnfspvcprfx -prfx default

Workaround: cnfspvcprfx -prfx default


Symptom: 3 segment ABR foresight connections across MGX 8850 2.0 network always has middle segment part with ICR = PCR on feeder side.

Condition: When creating 3 segment abr-foresight across MGX 8850 2.0 network.

Workaround: Go through CLI to fix ICR value.


Symptom: Erroneous values shown for tstdelay result when con segment endpoint in place on via node.

Condition: SPVC configured across three nodes and connection segment endpoint is configured on intermediate via node. Result of tstdelay is over 100% higher value with intermediate connection segment endpoint in place as opposed to when it is not in place.

Workaround: None


Symptom: Multiple .zip files are being retained in C:/CNF dir. However, according to design, only the 2 most recent files should be retained in C:/CNF.

Condition: On issuing a saveallcnf through SNMP or CLI

Workaround: manually delete any old .zip files that are not required.


Symptom: cnfpart is allowed when port is up.

Condition: user initiated cli command

Workaround: Do not do cnfpart when port is up.


Symptom: Error message indicating incorrect syntax or illegal option values are used is presented when upln is issued.

Condition: Line is already up

Workaround: UNKNOWN


Symptom: dspsscops command output appears on all telnet sessions open to switch

Condition: dspsscops command was executed only on one of the telnet sessions

Workaround: UNKNOWN


Symptom: Non service impacting Event Logs should lower the severity.

Condition: Perform resetsys on the node

Workaround :



Symptom: SM card goes to contious reboot when downloading image

Condition: This happens if the checksum of the image is incorrect or the image size is larger or the image is just corrupted. The card will come up and then reset again due to invalid image without a warning or error log.

Workaround: Download a valid image to the disk and the card.


Symptom: Commands parameters that require an unsigned intrange do not have a valid type.

Condition: Whenever the need for such a parameter is identified

Workaround :

This problem has been fixed. A new type has been introduced.


Symptom: Commands dspcds and dspcdalms do not seem to be showing corresponding output.

Condition: User executing dspcds sees major and minor alarms on AXSM service modules. Subsequent execution of dspcdalms does not quantify alarms.

Workaround: None


Symptom: System level error messages displayed on terminal

Condition: Standby card get rebooted

Workaround : N/A


Symptom: The message displayed is : " ATMC-4-INTERNAL_ERROR Start Bitmap Null"

Condition: During call journaling, before updating the call on stdby side,it will check if there is a VpiVci bitmap created on stdby side. If bitmap is not found, the above information will be displayed and won't affect the call updating to the standby card.

Workaround: None


Symptom: After formatting the PXM45 hard disk, the "sysVersionSet" command returns an error about not being able to open C:/SHMDB/forced_version

Condition: 2.0.12 code was used

Workaround: Before issuing the "sysVersionSet" command, create a /SHMDB directory and FTP the four files from a working node's /SHMDB directory on to the node.


Symptom: Configuration of APS for non existent AXSM card did not block

Condition: Attempt to configure APS line of non existent AXSM from an AXSM.

Workaround: N/A


Symptom: When the PXM45/AXSM cards reboot, boot code clears the caches instead of flushing them to DRAM. This operation destroys the data got modified in the caches that has not been written to memory.

Condition: Checking the coredump shows that the core image does not represent the actual image in memory.

Workaround: None


Symptom: CUT: (cuts) failed to schedule time in cutsProcessAckRecv event log message was recorded

Condition: None

Workaround: None


Symptom: Commands dspcds and dspcdalms do not seem to be showing corresponding output.

Condition: User executing dspcds sees major and minor alarms on AXSM service modules. Subsequent execution of dspcdalms does not quantify alarms.

Workaround: None


Symptom: cnfln syntax does not include e3 options

Condition: Issue the cnfln command

Workaround: Check documentation.


Symptom: ILMI disabled messages are printed in the event log for all ports where ILMI is not configured

Condition: Switchcc is executed

Workaround: UNKNOWN


Symptom: Mutliple Upgrades can take place at the same time

Condition: Issue loadrev on a set of cards and then do it on the other set

Workaround: Do not upgrade multiple cards at the same time. Multiple upgrades is not a recommended upgrade procedure.


Symptom: 'Call failure due to crankback max attempts reached' message appears in event log

Condition: This message appears even for SPVC crankbacks

Workaround: UNKNOWN


Symptom: APS has a failure, but is not shown in the APS Trouble mask in dspapsln

Condition: unknown

Workaround: look at event log to see correct APS state.


Symptom: dsprevs command shows garbage for non-existent cards

Condition: UNKNOWN

Workaround: UNKNOWN


Symptom: Core dump flag should be set to the default value of 0x262ee if it is having a value of "0".

Condition: Unknown. But value can be set from software.

Workaround: None.


Symptom: APS Event log is not clear enough to debug

Condition: APS events

Workaround: look at existing APS event log.


Symptom: agent capability mib shows incorrect access to mib objects

Condition: usage of this mib

Workaround: know correct access levels and avoid invalid access to mib objects


Symptom: Need warning message to user to continue before executing switchredcd command.

Condition: None

Workaround: Unknown.



PXM45 shows a major clock alarm when running on internal clock.

Condition: Delete the primary BITS clock with a major alarm, the alarm does not go away though the node is now running on internal clock.

Workaround: Go to shellcon and enter command: clkmgrAlarmClear (0x29004)


Symptom: Access levels to be changed as appropriate for the listed commands.

Condition: Access levels can be realized by logging in with different login levels. Depending on the Access Levels, the applicable commands will be visible.

Workaround: None.


Symptom: Release-complete cause code gives wrong cause value when the number of crankbacks hits the max_crankback limit.

Condition: total releases processed is max_crankbacks +1 but we only check for max_crankback number of crankbacks.

Workaround: Unknown


Description: VSI Master AVL Tree of interfaces does not match that maintained by Interface Manager.

Symptom: Congestion Manager (CCM) logs error during congestion detection and abatement.

Workaround: None.


Symptom: T310 timer range is not correct for PNNI1.0 signalling using cnfsig.

Condition: User cannot configure T310 timer per Q.2931 specified range.

Workaround: None


Symptom: Dsplog displays unreadable working line index.

Condition: PSB Irrelevant event occurred

Workaround: None


Symptom: Results from vsiCksmBlkCmp command is seen on Stdby instead of active.

Condition: When vsiCksmBlkCmp command is issued on the active, the result is shown only on the standby, which is annoying.

Workaround: Open a window for both active and standby. Issue the command on active and observe the result on standby.


Symptom: dspapslns and dspapsln shows ALM or OK. It would be useful for the user if it is displays more granular level, i.e., SF-L, SF-H etc.

Condition: None.

Workaround: None.


Symptom: Irrelevant error message pops up when a APS line is added.

Condition: On AXSM CLI, add a APS line. A error message pops up.

Workaround: None.


Symptom: delapsln is executed and the command fails due to some reason. APS tries to log the trace but the logging causes the 'Tlb Exception'

Condition: unknown

Workaround: None.


Symptom: When dspapsbkplane is executed on the standby card it shows an error: "Standby card is Not Ready."

Condition: Always

Workaround: Try executing the command in Active card only. If the ACtive card shows the backplane state as "ENGAGED", then there is a high probability that the backplane is ENGAGED.

Problems Fixed in Release 2.0.13

Bug ID
S2 Bugs


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


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.


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.


Symptom: SPVCs were stuck in mismatch condition.

Condition: Associated pnport was stuck in provisioning state

Workaround: UNKNOWN

S3 Bugs



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.


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

Condition: Normal

Workaround: N/A


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.

Problems Fixed in Release 2.0.12

The following is the list of known problems that are fixed in Release 2.0.12. 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
S1 Bugs


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.


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


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


The controller was out of memory and restarted.


Task suspends during its sync process.


After loadrev standby PXM45 keeps resetting


Standby card continuously reset.


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


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


AXSM card is restarted due to software exception.


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"


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

S2 Bugs


XBAR plane available Multicast event buffer got corrupted.


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.


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.


Standby card does not come up after a restoreallcnf.


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


After running script to create 50K SPVC connections, 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.


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.


Some connections are not passing traffic.


VP Connections are slow to route


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


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


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.


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.


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


TLB exception on one of the ftp tasks.


It takes a long time for some connections to route.


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


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


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.


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


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


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


SVC Based RCC cannot be established on ABR service category.


Memory leakage in ILMI.


SPVC connections are in AIS


Unable to create APS lines from CiscoView


clrchancnts command does not clear all the counts.


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


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.


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


No access to node via ATM interface


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


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


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


Port stuck in building-vc.


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.


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


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


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


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


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.


summary display of tasks is awkward to get from CLI


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


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


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


SPVC connection failed to come up after power cycle


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


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


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


OAM traffic exists for deleted connections on ports.


Port go to building vc.


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


Node shows PXM45/B card as mismatch when inserted as Standby card.


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.


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

S3 Bugs


Confusing trap sent when voltage is above threshold.


-dsplns command accepts junk as input parameter.


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.


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


Memory allocation failure detected in statistics region on the PXM45 card.

This is the SNMP region - region2.


Debugging 'printf' messages are displayed.


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


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


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


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.


addport, addpart, delport or delpart commands can be rejected


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.


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


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.


AXSM card reboots and is stuck in failed state.


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


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


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


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


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


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


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


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


addaddr takes address matching host address.


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


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


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


The PXM45 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 PXM45 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 PXM45 and AXSM card.


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.


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


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


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.


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.


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


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


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


Card alarm is generated when core redundancy is lost.


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


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.


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


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


CC alarm is not always reported.


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


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


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.


System runs out of memory due to a memory leak.


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


No defect will be exposed to user.


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


When you issue sysBackupBoot from VxWorks shell of PXM45 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.


When you issue a bootChange command on the PXM45 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 PXM45 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.


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


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


dspchancnt gives wrong error message.


When you issue bootChange command and enter the boot information for PXM45 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 PXM45 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.


Debug messages are displayed as Error messages in log file


aesa_ping setup timing out even after receiving connect.


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


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


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


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


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.


On the PXM45 console, user see SHM BRAM Checksum Error


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


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


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


file descriptor is leaked


No tracing of card-to-card multicast messages


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


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


dsprevs shows current revision for empty slot


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


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


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


Fan tray alarms not reported correctly.


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


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


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


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.

Problems Fixed in Release 2.0.11

The following is the list of known problems that are fixed in Release 2.0.11. 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
S1 Bugs


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


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


SPVCs do not get routed.


The problem will cause UBR calls to fail


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


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


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


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


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


PNNI can't detect bad clock source.


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


Shelf Manager task got suspended.


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


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.


pnCcb task gets suspended


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.


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


ILMI task crashs and card may reset.


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.


The Standby PXM/AXSM card fails to come up.


Floating point exception and system gets reloaded automatically.


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


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


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.


Axsm card resets while attempting to read sct file.


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.


The controller was out of memory and restarted.


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


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.


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

S2 Bugs



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


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


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


Standby PXM45 card gets reset 3 times and stays in Failed state.


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


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


AIS is not generated when dnport issued on AXSM card


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.


SNMP GETs on the following variables:


Calls not routed after setrev


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.


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


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.


The conn pending congestion counter shows negative values.


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


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


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


The dsppnports on PXM45 will show ILMI state as autoconfig but AXSM is in UpandNormal state or on PXM45 ILMI will be showed as disable when it was really enabled on AXSM.


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.


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


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


Pnni-link port is in attempt state.


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.


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.


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


Connections are not able to route due to running out of trk vpi/vci even vpi/vci should not be running out


The AXSM card fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.


A nni port with ILMI on is stuck in auto cfg.


When a dncon / upcon is performed on an endpoint, the connections' upload counter is not updated. Use dspcons to see the upload counter.


OC48 Card CLI hangs, and one cannot execute any commands.


The PSB condition caused by any condition other than the invalid code is cleared even though the PSB condition has not disappeared.


An AXSM card may be reset immediately after a PXM45 switchover.


Standby OC-48 card stuck in reset init state.


LCN resource not available and connection commit keep failing


Root task could not delete a suspended task.


User adds feeder on an interface on which connections exist


No immediate symptom. Over time when many addapsln/delapsln/dspapsln commands have been executed, we may get IPC message allocation errors.


Line shows that there are some statistical alarms, although, the line has no defects. There are no adverse effects of this.


After a addred or switchredcd, there may be alarms on some channels in the Active AXSM card.


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.


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.


swichred on PXM, standby becomes active, reset the newly standby PXM,


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.


Getting incremental RAM Sync send error after line/port/partition commands are executed. See description for display details.


During AXSM switchred, previously standby card gets PHYTask exception while transitioning to active. Ports go into provisioning state.


After AXSM card sends a passup command to the controller, the message counter doesn't increment for the passup cmd message.


ports in standby card stay in "vc failure"


The Active PXM45 gets a software exception and resets unexpectedly when a file is transferred onto the Active PXM45 using FTP.


dspenvalms shows DC Level outside of threshold range, but no node alarm generated


Some SPVC connections will not be routed and stays in fail state


Two GLCN programs the same ELT Entry in HUMVEE. HUMVEE will indicates ELT Mismatch, no traffic will be passing through.


A nni port has a vpi range of (0-255) available instead of the complete range (0-4095).


Alarms show up in dspcdalms <slot> for the standby card after a switchred.


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.


Before switchcc, take the physical connection out (ex. 3:1.1:1).


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


Receive RAI count is not cleared by clralmcnt command.


Power supply failure does not generate a node alarm.


Connection routing failure due to AvCR being zero on PNNI link that previously was out of LCNs.


Trap 60004 cwShelfRestart was not received after a node reset from CLI "resetsys" command.


When SPVCs are tunneled through an DAX-SVP connecting two VTs configured with different VPIs, the connection will not be accepted.


Port gets stuck in down in progress.


Standby AXSM card gets reset multiple times before it becomes standby ready


When a large number of IISP trunks are configured on the node and a switchover is attempted, system goes into busy state.


No event logging is done for APS.


Any command on the PXM45 that accesses the disk will pause for a couple of minutes and displays nothing. Also, any file transfer to the PXM45 disk will fail. Also, an AXSM card fails to load an SCT file and uses default traffic parameters.


Some connections are derouted and rerouted continuously.


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.


Configuration on active AXSM card is destroyed.


The ILMI address will not be sent to PNNI for advertisement.


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.


VTs are still up even when the uni endpoints on spvp tunnel are brought down.


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.


Previously standby AXSM card cannot transition to active ready state after switchred is performed.


The problem was handling crankback when VP resources are not available.


SPVC connections FAILED to route. the Last Fail Cause to be Call Rejected.


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.


Failure to configure the clock source.


The problem was an unexpected routing failure where some calls never get routed.


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 PXM45 shows "Active-F" for the slot.


Some of the ports are in Building VC state after one of the service module cards are reset.


When SHM could not update its database to standby PXM, SHM just logs an error. It should reset standby PXM45 to recover.


When the active PXM45 powers up, it stays at the pxm45> prompt with an error message printed saying SHM_BRAM_VER_MISMATCH.

S3 Bugs


Selecting the front card for testing based in the command syntax given by diagnostics produced an "Invalid syntax" message.


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


AXSM card does not detect loss of cell delineation (LOCD), therefore not generating RDI as a result.


No mechanism to clear a portion of a node's configuration.


When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name.


Revereved back card alarm missing alarm persists.


Under certain situations, the restoreallcnf may fail and the node's configuration is not restored.


pnCcb takes too much (75-85%) CPU time


The dspcds, dspcd and dspcdalms do not show the same alarm information.


The connection summary information displayed by command dsppnport wraps after 80 columns (the output exceeds 80 columns).


output from CLI command dsptasks scrolls off screen


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.


dsppncon command displays SCR and MBS values for CBR and UBR calls.


Configuration commands

cnfspvcprfx cnfilmienable cnfnodalcongth cnfabrtparmdft cnfrrtparm execution is allowed on standby card.


dsplog -task dbClnt will show error sometimes during switchcc of two MGX 8850 PXM45 cards.


User is allowed to add feeder on a VNNI trunk.


AXSM card remains in Init state.


cannot configure the clock sources.


When "dspapsln" command is executed using protection line ID as input, the working line ID is same as protection line.


Risky commands such as shutdisk are available and are not needed.


No mechanism to display current community string value.


Programming the backplane NOVRAM on an MGX 8950 backplane fails with a write error.


On a resetsys, the event was not logged indicating the command and username.


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.


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.


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.


PNNI link is in attempt state.


After executing addlnloop command on AXSM card - the event is not recorded in event log.


SNMP responses and SNMP traps being sent out the incorrect network interface.


When a switchcc is executed, the following messages appear on the console port of the PXM45 that transitions from standby to active:

go_active, sync_flag=1 SPVC transiting from Standby to Active


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


No particular symptom. AXSM Diagnostic may cease to run.


This was noticed in a customer beta trial. The dspcons on AXSM does not show any alarm. However the dspcdalm <slot> on the PXM45 would display chan alarms for that particular slot. This would translate to a node level alarm in the system;


Multiple switchred can trigger XBAR remap twice error. The error is also reported to alarm manager. "Card Crossbar" major alarm will be registered.


Taking the standby PXM45 from one node and placing into the standby of another node can cause the LAN interface of the old node to become disabled.


The different values of K1 when doing switchred and when removing cards is cleared when the redundant card comes up.


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.


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.

Problems Fixed in Release 2.0.10

The following is the list of known problems that are fixed in Release 2.0.10. 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
S1 Bugs


The SRCV task in AXSM gets an address exception.


Receive 60905 or 60904 trap as soon as CWM requests for a config upload file.


Vsi master fails to recover on trying to commit a connection on an existing vpi/vci.


PXM45 fails to send config message to slave.


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.


SNMP MIB Walk fails even though the cards are in active state.


CWM did not receive trap 60901 to let CWM know that File creation has been started.


Cpro shows status indicating AIS state when no AIS state exists.


When addpart or and "set partition" type command is executed for VT (VNNI) ports, AXSM card gets SW exception and resets.


The problem is an unexpected system reload.


When connection reroute is triggered from CWM, the operation would fail


When pulling out an active AXSM, PXM45 goes into reset


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


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.


dspsct command does not display proper information.


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 PXM45 card may be affected by this, and may get stuck in the INIT state also.


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.


Trap managers don't see any trap for PXMs switch over.


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.


Some SPVCs will appear as failed even though the connections are active


uni or nni port state goes up and down intermittently.


To reproduce this problem,

1. add a partition, and PXM45 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.


dspcdalms command does not break after 24 lines to give user an option to either continue display or quit.


SVC connection is constantly torn down and rebuilt. This causes intermittent outages between node and CWM.


Applications complaining about IPC message allocation failures due to IPC message leak.


Standby card will be waiting in Init state


Event log entries indicating IPCONN could not send message to vcid 0.


When dspswalms/dspslotalms commands are used to display alarms, displays are inconsistent when there are alarms present compared to when they aren't present.


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.


A redundancy-deleted trap is sent with secondary slot number set to zero.


The Cross bar status displayed by the command dspxbarstatus does not reflect the correct status.


getone on an instance of caviStatEgressTable object does not return the value.


The message "Function ssiTaskDelay called by ISR." may appear in the dsplog output.


Message Of IPC Allocation failure seen on the console


Event log messages are not generated.


After about 75 (out of the 100) ports issued the above error message, PXM45 would temporarily lock up (for about 40 sec) and then continue.


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.


Failure condition for addred/delred from CWM will always indicate a general error.


Frame discard field comes as 0 when it is disabled. It should be 2.


Link goes down and up when ILMI is enabled in IISP


After a setrev or a soft reset, a NOVRAM will be corrupted. The specific symptom is a failure of the checksum verification.


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.


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.


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.


When user enters the command "dspvsicons -cksm 0" the CLI task would take an exception.


The trap oid for cwIfIndex is wrong.


MIB Requests(Get,Set, Get-next) comeback with NO SUCH INSTANCE error.


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.


OC12 card result in wrong cell delineation because of the wrong C2 byte configuration.


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


When pulling out an active AXSM, PXM45 goes into reset


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.


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.


Operational status of Protection line is not displayed correctly


SSI event logged as EVENT_ERROR with stack trace of event.


dspcd and dspcds show a card is in failed state but no alarm is raised.


Update port sig parameters when the port status is up, it will cause the inconsistence in information display between the dsppnport and dsppnportsig.


Standby PXM45 fails to come up after a PXM45 switchover or new Standby PXM45 insertion.


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


Calls with AAL parameter IE octet 12.1 (i.e. partially filled cells method) set to 0 are rejected.


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.


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

The following is the list of known problems that are fixed in Release 2.0.02. 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
S1 Bugs


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.


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.


Performing PXM45 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.


A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost.


Bucket statistics file name has incorrect file name.


VC Failure due to insufficient LCNs used up by the user connections. The port stays in VC failure forever.


Some of the provisioning command operation does not get reflected on standby and disk.


Unable to ping/telnet to the node intermittently.


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.


Reset of AXSM cards and switchover will cause SPVC to reroute.


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.


NO SPVCS. After PXM45 rebuild some interfaces might disappear.

WITH SPVCS Every time PXM45 card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception.


'ssiIpcMessageAllocate fails' appears on screen periodically.


The call does not routing with VPI/VCI assignment error.


Could not run "dspln", dspports, etc. Could not walk mib tables.


Exception in pnCcb task causing the active processor to reset.


Standby PXM45 reloads


Connection add / delete problems when number or connections is around

30,000+. Possible error message includes, delete failure, non-existing ConnID entry.


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.


Standby card will be reset and come back in the higher revision (2.0(1)). The card will then transition to the failed state.


provision the SPVC, the conn is ok but the cell dropped.


Standby PXM45 waits indefinitely in INIT state.


The applications on Active PXM45 fail to communicate with other applications on the same card and other cards due to lack of IPC message buffers.


dspcds will show that the card is in the BOOT state.


Intermittently, AXSM cards will get reset due to MCAST_MSG_LOSS.


Node and card redundancy configuration is lost.


dspcds and many other CLI commands will not work.


SPVCs will fail to route.


After clrallcnf, access to the node via TCP/IP makes connection to the standby card rather than the active.


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.


System restarts.


When a large number of endpoints are provisioned and if all of them had statistics collection enabled, then it is impossible to login or cc to the AXSM card.


IP connectivity cannot be established and remains in SETUP state.


IP connectivity setup fails with cause ATM_CAUSE_VPCI_UNAVAIL (35).


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


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.


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.


The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.


When performing dnpnport on a certain ports with SPVC connections which has statistics enabled, some dal/statistics error are observed on the UNI AXSM side.


The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.


Much lower via node reroute rate when attempting to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value.


Any operation involved in file creation or file opening on the Active controller card will start failing continuously.


Cell drops are noticed on OC3 with default line rate.


Calls will not go through.


After addpart with incorrect parameters, the partition gets added on AXSM, but dsppnports on PXM45 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 PXM45, although dspparts on the AXSM doesn't show the partition anymore. There is no error message displayed.


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.


Few connections will be in fail state at one end point (either master end or slave end)


Cannot display link selection configured on PNNI port.


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.


User see sometimes SPVC fail to route SPVC connection on AXSM card resets


User did not have the granularity to find out why the clock when bad.


User did not have the granularity to find out why the clock when bad.


Some SPVC connections are in AIS-FAIL in standby


Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections.


After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM.


After the switchover, the new active PXM45 still shows that the above inserted back cardback card is still missing. This will eventually cause an extra switchover when a healthier standby PXM45 is ready.


port(s) in "vc failure"


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.


Svc call on uni port getting released.


The connection does not pass the data traffic.


Dax connections are in FAIL state


An unsupported card will stay in the Boot state, and the standby PXM45 will stay in the Init state.


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.


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


Some SPVC connections are in AIS-FAIL in active PXM45 after switchover


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.


The clock is marked as unclockable.


The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link.


After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before.


Connection may not be routed on best path.


System allows calls to use VPI/VCI below the provisioned minimum value.


CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB.


Connection resync will be stuck in one place and so connections will be mismatched between controller and slave


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.


The addcontroller command fails.


dspsct command does not display proper information.


1.switch gives status.14.0000000000000 as the response to

getnext request on netprefix

2.get negative number in ILMI PDUs from HP test


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.


cnfchan on slave dax con for cc enable, PNNI controller doesn't send vsi msg to SM


SPVCs will fail to route.


Calls will not get routed through the nodes in the network.


When 2 mandatory events were sent to the children at the same time, the RAT only kept the last one.


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


See the following misleading messages: "+bad length+" and

"Send Status Enquiry"


AXSM STM1 card will not handle over 32K connections.


SPVP connection(s) are not allowed.


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.


Bad IPC messages detected caused by unreported SAR CRC errors.

Unexplained behavior or errors in the shelf.


SHM FAILURE ALERT message is displayed on the console


See a continuous Trap messages indicating IPC memory leaks.


The dspclksrc command shows inaccurate clock information


Switchcc results in clk switch to priority 0 msg.


No event logs when there is a PXM45 switchover.


If a resetsys or a switchcc is preformed on the PXM, a

core dump would be preformed during the boot of the formerly active PXM45 card. When the core dump logs are observe the reason would be a device driver error.


clralmcnt doesn't clear LOS/LOF alarm counters.


dspcdstatus shows "No Alarms" for PXM45/any inapplicable slots. When slot number is not specified, it defaults to PXM45 slot.


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


When the optional parameter, shelf #, was provided in the CLI commands, the commands fail.


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.


DAX connections are not in AIS when connection is down


dspcdalms shows alarms whereas dspcdstatus does not.


switchcc generates a syntax error message inappropriately


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.


CLI dsppnni-path displays node name incorrectly


Some connections exhibit unexpected behavior such as "cannot resolve passthru".


Some connections exhibit unexpected behavior (see related bug CSCdr72621) such as "ERR: Could not resolve passthro id" when "dspcon" is executed on some connections.


SNMP MIB Walk or Sending Traps results in failure(Event Log contains this information)


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.


dsplns will show "other" for Medium LineType instead of "ShortSMF" etc.


Board (e.g. PXM45) fails to boot and issues a NOVRAM checksum error.


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


Log does not report successful switching of clock source.


dsppnport does not show active connections after dnpnport on a UNI port.


? 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. Note that the "=" is part of the part number.

Table 1 MGX 8850 Switch Release 2 Related Documentation

Documentation Title and Part Number

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.

Cisco MGX 8850 AXSM SNMP Reference, Release 2


Provides information on all supported management information base (MIB) objects, support restrictions, traps, and alarms for the AXSM card.

Cisco MGX 8850 PXM SNMP Reference, Release 2


Provides information on all supported MIB objects, support restrictions, traps, and alarms for the PXM45 card.

Cisco MGX 8850 PNNI SNMP Reference, Release 2


Provides information on all supported MIB objects, support restrictions, traps, and alarms for PNNI.

Cisco MGX and SES PNNI Network Planning Guide


Provides guidelines for planning a PNNI network that uses the MGX 8850 and the MGX 8950 switches and the BPX 8600 switches. When connected to a PNNI network, each BPX 8600 series switch requires a Service Expansion Shelf (SES) for PNNI route processing.

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.

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: (for example, as of this printing, MGX 8850 Release 2 documentation is located at

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:

Registered users can order the Documentation CD-ROM through the online Subscription Store:

Nonregistered 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

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 as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For registered users, additional troubleshooting tools are available from the TAC website. 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. provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through, 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 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, go to the following website:

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:

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, go to the following website:

If you cannot resolve your technical issue by using the TAC online resources, registered users can open a case online by using the TAC Case Open tool at the following website:

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:

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.