[an error occurred while processing this directive]

Cisco MGX 8800 Series Switches

2.0.11 Release Notes for MGX 8850

 Feedback

Table Of Contents

2.0.11 Version Software Release Notes
Cisco WAN MGX 8850 Software

About These Release Notes

About the 2.0.11 Release

Phased Release Strategy:

Software Release 2.0.11 and related hardware:

AXSM Cards

PXM 45 Cards

PNNI

Special Installation/Upgrade Requirements

Upgrade Procedure

Loading the runtime images from 2.0.10 to 2.0.11

Loading the runtime images from 2.0.02 to 2.0.11

New CLI Commands

Changed CLI Commands

Features Not Supported

Committed (but not delivered in this release)

Obsoleted:

Notes & Cautions

Limitations

Recommendations:

Compatibility Notes

Compatibility Matrix

Release 2.0.11 System Content

Switch Software and Boot Codes

Hardware Products

Known Anomalies

Problems Fixed in Release 2.0.11

Known Anomalies from Previous Releases

Problems Fixed in Release 2.0.10

Problems Fixed in Release 2.0.02

Additional Deliverables

SNMP MIB

Obtaining Service and Support

Cisco Connection On-line


2.0.11 Version Software Release Notes
Cisco WAN MGX 8850 Software


About These Release Notes

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

About the 2.0.11 Release

Phased Release Strategy:

This is the fifth release of PXM45 and AXSM. Follow on releases are planned to add new feature contents and can be found in Marketing Road Map

Software Release 2.0.11 and related hardware:

AXSM Cards

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

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

Line Interfaces for the AXSM Cards

T3/E3

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

G.703/Accunet Conformance

OC3c/STM1

G.703/GR-253 Conformance

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

MMF, SMF intermediate and long reach

4 port Electrical back card

OC12c/STM4

G.703/GR-253 Conformance

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

SMF intermediate and long reach

OC48c/STM16

G.703/GR-253 Conformance

Single port back card, one back card per slot

SMF Short, long and extra-long reach

ATM Layer Information

Usage policing supported on all interfaces except OC48c/STM16

T3 interfaces support both PLCP and direct cell mapping

64 Logical interfaces -- ports, trunks, or virtual trunks (future)

16 Class of Service queues for each class of service

Supports independent queues for each ATM class of service

Network Management Features

OAM functionality per ITU-T I.610

Fault management - AIS/RDI at F4 and F5 flow

User selectable continuity checking at connection endpoints

Loopback diagnostics

Automatic alarm generation and propagation for interface failures

The AXSM offers a complete ATM feature set and allows the MGX8850 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 MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.

PXM 45 Cards

The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 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 (RAS) Features

The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the 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 to ensure that if one or both hard disk fails, 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 PXMs in a system. This was calculated at greater than 100,000 hours.

PNNI

The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:

PXM-UI-S3

The PXM-UI-S3 supports the following interfaces:

One RJ45 10Mbps 802.3 Ethernet port

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

Pin
Signal
Direction
Description

1

RTS

OUTPUT

Request to Send

2

DTR

OUTPUT

Data Terminal Ready

3

TX

OUTPUT

Transmit Data

4

SG

Signal Ground

5

SG

 

Signal Ground

6

RX

Input

Receive Data

7

DSR

Input

Data Set Ready

8

CTS

Input

Clear to Send


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

RJ48. Pin Out conforms to Accunet1.5 Specification

Wire Wrap

BNC

DB15

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

PXM-HD

This contains the hard disk for the processor.

PNNI

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

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

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

PNNI provides dynamic ATM routing with 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 has the ability to 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 the following:

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

The following 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.

Special Installation/Upgrade Requirements

Upgrade Procedure

There are new SCT files that are being released with this version.

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

pxm45 backup boot

pxm45 runtime image

axsm runtime image

Loading the runtime images from 2.0.10 to 2.0.11

For Redundant Systems

Upgrade the standby PXM45 boot code by using the following steps:


Step 1 - type "sh" to go to the shellconn

Step 2 - issue "sysBackupBoot" command

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

Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
- enter "y" to confirm

Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.

Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.

Step 7 Use the "LOADREV" command to load the 2.0.11 release on the standby card:

loadrev <slot number> <version>

For example: loadrev 7 2.0(11.3)

Step 8 After the standby card comes back up with the new image in the ready state, use the "RUNREV command to load the 2.0.11 release on the active card. This command will bring your original standby card to active state.

runrev <slot number> <version>

For example: runrev 8 2.0(11.3)

Step 9 After the redundant card comes up in standby ready, issue the command "COMMITREV" to commit your node to the current release.

commitrev <slot number> <version>

For example: commitrev 8 2.0(11.3)

Step 10 Replace SCT.2 and SCT.3 with new SCT on Disk.

Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the "LOADREV, RUNREV and COMMITREV" command for each AXSM card.

For example:

loadrev <axsm slot> 2.0(11.3)

runrev <axsm slot> 2.0(11.3)

commitrev <axsm slot> 2.0(11.3)

Repeat these steps for all non-redundant AXSM cards.

Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.

loadrev <slot number> <version>

For example: loadrev <axsm slot> 2.0(11.3)

Step 13 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.

runrev <slot number> <version>

For example: runrev <axsm slot> 2.0(11.3)

Step 14 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.

commitrev <slot number> <version>

For example: commitrev <axsm slot> 2.0(11.3)

Repeat this step 12-14 for all redundant AXSM cards.


For non-redundant (PXM45) systems, please follow these steps


Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn

a. - issue "sysBackupBoot" command

b. - hit return when prompted to do so to stop auto-boot

c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"

d. - enter "y" to confirm

Step 2 Use the "LOADREV, RUNREV, COMMITREV" commands to load the 2.0.11 release:

-- loadrev 7 2.0(11.3) 
-- runrev 7.2.0(11.3)
-- commitrev 7 2.0(11.3)

Step 3 Replace SCT.2 and SCT.3 with new SCT on Disk.

Step 4 To upgrade non-redundant AXSM cards with the new runtime image, issue the "LOADREV" command for each AXSM card.

For example:

loadrev <axsm slot> 2.0(11.3)

runrev <axsm slot> 2.0(11.3)

commitrev <axsm slot> 2.0(11.3)

Repeat these steps for all non-redundant AXSM cards.

Step 5 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.

loadrev <slot number> <primary version>

For example: loadrev <axsm slot> 2.0(11.3)

Step 6 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.

runrev <slot number> <primary version>

For example: runrev <axsm slot> 2.0(11.3)

Step 7 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.

commitrev <slot number> <version>

For example: commitrev <axsm slot> 2.0(11.3)

Repeat steps 6-7 for all redundant AXSM cards.

Loading the runtime images from 2.0.02 to 2.0.11

For Redundant Systems

Upgrade the standby PXM45 boot code by using the following steps:


Step 1 - type "sh" to go to the shellconn

Step 2 - issue "sysBackupBoot" command

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

Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
- enter "y" to confirm

Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.

Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.

Step 7 Use the "SETREV" command to load the 2.0.11 release:

setrev <slot number> <primary version>

For example: setrev 7 2.0(11.3)

Step 8 Replace SCT.2 and SCT.3 with new SCT on Disk.

Step 9 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.

For example: setrev <axsm slot> 2.0(11.3)


For non-redundant systems, please follow these steps


Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn

a. - issue "sysBackupBoot" command

b. - hit return when prompted to do so to stop auto-boot

c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.

sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"

d. - enter "y" to confirm

Step 2 Use the "SETREV" command to load the 2.0.11 release:

-- setrev 7 2.0(11.3) 

Step 3 Replace SCT.2 and SCT.3 with new SCT on Disk.

Step 4 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.

setrev <axsm slot> 2.0(11.3)

Repeat this step for all AXSMs on the card.

New CLI Commands

1. Two new CLI commands have been added on the AXSM card.

a. clrportcnts: There are no parameters to be entered. This command will clear the counts on all the ports.

b. clrchancnts: There are no parameters to be entered. This command will clear the counts on all the connections.

2. The CLI command "clrcnf" has been added to clear a portion of a node's configuration. The following information is retained:

a. IP Connectivity configuration for LAN and ATM

b. nodename

c. Correct primary and secondary software version for all slots

d. SNMP community string, contact and location.

e. timezone

f. GMT offset

g. date and time

3. When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name. This has been changed to reflect the command that was issued. Note, this fix will work for those CLI commands that currently call the areYouSure () function to throw the prompt "Do you want to proceed?". However those CLI commands that don't use the areYouSure () function will continue to throw their own confirmation prompt.

4. Two additional commands have been added for the AXSM card.

a. dspbecnt

b. clrbecnt

Changed CLI Commands

1. The switchcc command has been changed to reject the pxm switchover if the node is not in a stable state. The node is considered not stable if some of the cards in the node are in the process of transitioning to ready state.

2. The dsptasks command now has screen prompting to continue or exit from viewing the information.

3. Before, the card alarms and slot alarms (for the same slot that the card resides in) were being reported by different CLIs i.e., dspcdalms and dspslotalms. Now, both these CLIs have been merged to show both card and slot alarms via dspcdalms. As a result of this change, dspslotalms will no longer be available. Further,

- dspcdalm <slot> provides alarm type-level information for the slot specified

- dspndalms contains both slot and card alarms under alarm type "Card Alarms"

For Example:

Unknown.7.PXM.a > dspcdalms

Card Alarm Summary:

Slot Critical Major Minor

---- -------- ------- -------

1 0 0 1

2 0 0 0

3 0 0 0

4 0 0 0

5 0 0 0

6 0 0 0

7 3 4 5

8 0 2 0

9 0 0 0

10 0 0 0

11 0 0 0

12 0 0 0

13 0 0 0

14 0 0 0

Use dspcdalms <slot> to see more detail.

Unknown.7.PXM.a > dspcdalm 7

Card Alarm Summary

Alarm Type Critical Major Minor

---------- -------- ------- -------

Hardware Alarm 0 0 0

Card State Alarm 0 0 0

Disk Alarm 3 4 5

Line Alarm 0 0 0

Port Alarm 0 0 0

Feeder Alarm 0 0 0

Channel Alarm 0 0 0

Unknown.7.PXM.a > dspndalms

Node Alarm Summary

Alarm Type Critical Major Minor

---------- -------- ------- -------

Clock Alarms 0 0 0

Switching Alarms 4 5 6

Environment Alarms 3 4 5

Card Alarms 3 6 6

Features Not Supported

Committed (but not delivered in this release)

1. AXSM cards with STM1 electrical interface.

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

3. Connection density: 50K connection per node. 40K connections is supported in this release.

Obsoleted:

none

Notes & Cautions

1. Note upgrading from the 2.0.02 release to 2.0.11 is non-graceful. Upgrading from 2.0.10 to 2.0.11 is graceful.

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

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

4. The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert!! Alert!!." In this situation follow the steps below:

a. enter "shmFailDisplay." Display table will show that BRAM is not native.

b. enter "shmFailRecoveryHelp". This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is "shmRecoverIgRblDisk".

c. enter "shmRecoverIgRbldDisk".

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

6. Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.

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

8. To replace one type of AXSM front card with other type, it is required to delete all connections, partitions, ports and down lines. In case of AXSM card failure, same type of AXSM card must be installed in that slot.

9. If a user has upgraded already to 2.0.11 and then decides to fall back to 2.0.10 he/she should run the following command on the active PXM after falling back to 2.0.10 - gShmRebuildFlagSet(2).

Limitations

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

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

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

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

5. For users who would like to add MPLS controller in release 2.1, it is highly recommended to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be automatically established on 0/32.

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

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

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

7. If 50 users (the maximum is 50) is added and the pxm card is reset, the card does not come back up.

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

Recommendations:

It is recommended to 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, you must use the SCT files released with 2.0.11 (number 2 and 3) for the Control VC feature.

Compatibility Notes

Compatibility Matrix

Board Pair
Latest Boot Code Version
Minimum
Boot Code
Version
Firmware
Latest
Firmware
Version
Minimum
Firmware
Version

PXM45

pxm45_002.000.011.001_bt.fw

2.0.11.1

pxm45_002.000.011.003_mgx.fw

2.0.11.3

2.0.11.3

AXSM-1-2488

axsm_002.000.0010.000_bt.fw

2.0.10

axsm_002.000.011.003.fw

2.0.11.3

2.0.11.3

AXSM-16-155

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.011.003.fw

2.0.11.3

2.0.11.3

AXSM-4-622

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.011.003.fw

2.0.11.3

2.0.11.3

AXSM-16-T3/E3

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.011.003.fw

2.0.11.3

2.0.11.3


MGX 2.0.11 interoperates with CWM 10.3.

MGX 2.0.11 operates with MGX 1.1.31 as a feeder. Please see 1.1.31 release notes for bugs related to the feeder features.

MGX 2.0.11 operates with Cisco View 5.1x (package 3.3x).

Release 2.0.11 System Content

Switch Software and Boot Codes

The following four images are applicable to the 2.0.11 release:

Boot Images

axsm_002.000.010.000_bt.fw

pxm45_002.000.011.001_bt.fw

Runtime Images

axsm_002.000.011.003.fw

pxm45_002.000.011.003_mgx.fw

Hardware Products

Support hardware for Release 2.0.11:

Model
800 Part Number
Revision

PXM45

800-06147-07

B0

PXM-UI-S3

800-05787-02

A0

PXM-HD

800-05052-03

A0

AXSM-1-2488

800-05795-05

A0

SMFSR-1-2488-FC

800-05490-05

A0

SMFXLR-1-2488-FC

800-05793-05

A0

SMFLR-1-2488-FC

800-06635-04

A0

AXSM-16-155

800-05776-06

A0

AXSM-4-622

800-05774-09

B0

AXSM-16-T3/E3

800-05778-08

A0

SMFIR-2-622

800-05383-01

A1

SMFLR-2-622

800-05385-01

A1

SMB-8-T3-BC

800-05029-02

A0

SMB-8-E3-BC

800-04093-02

A0

MMF-8-155

800-04819-01

A1

SMFIR-8-155

800-05342-01

B0

SMFLR-8-155

800-05343-01

A1

APS RDNT CON

800-05307-01

A0


Known Anomalies

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

Bug ID
Description
S1 Bugs
 

CSCdr15911

Symptom:

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

Conditions:

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

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

Workaround:

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

CSCds20527

Symptom:

The CWM Software(ConnProxy module) will notice timeouts while creating connections continuously.

Condition:

SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).

Workaround:

Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.

Additional Information from CWM:

If client tries to add more than 100 connections through Connection Proxy (Service Agent) Script, they will start getting Time Out's even though the time out frequency is less. Client then needs to find out from the Log file which all connections could not be added. If provisioning is a one time action, Client may bear this, but if they do provisioning very often, it will be a serious concern.

CSCds46636

Symptom:

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

Solution:

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

Workaround:

None

Frequency:

One time occurrence.

CSCds54248

Symptoms:

All the links may go to 0ne-way-inside or even in reset state. PXM may loose connectivity with SM cards.

Conditions:

Happens during high DMA traffic like having 95 interfaces on the nodes (physical + virtual) with 50K connections and switchcc happens on a via during resetsys happening on a neighboring node. Problem is observed on a via node.

Workaround:

Non.

Additional Information:

Switchcc PXM or resetsys the node.

CSCds54390

Symptoms:

Connections fails to route over OC48 trunk

Conditions:

Routing connection over OC48 trunk

Workaround:

None

Frequency:

One time occurrence.

CSCds55470

Symptom:

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

Conditions:

LAN boot IP address has not been configured.

Workaround:

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

Execute following commands:

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

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

CSCds63724

Symptoms:

PNNI interface status is in "building vc" state after loading new image on AXSM.

Conditions:

After loading new image on AXSM, one of the pnni port shows status in "building vc" in dsppnports command. This problem occurs in a fully loaded node (50K connections) and 100 interfaces. The problem occurrence is also rare.

Work around:

Perform dnport and upport on that interface.

Frequency:

Intermittent

CSCds64523

Symptoms:

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

Conditions:

(1) On AXSM, perform addport and addpart.

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

Workaround:

None.

CSCds65556

Symptoms:

The controller was out of memory and restarted.

Conditions:

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

Workaround:

None.

CSCds68209

Symptom:

Single PXM card resets itself after upgrading boot

Conditions:

After upgrading boot on non-redundant PXM.

Workaround:

none

Frequency:

One time occurrence.

S2 BUGS

 

CSCdr89521

Symptom:

dspcon shows routing cost = 0

Condition:

This will happen after swithcc on connections that are not rerouted

Workaround:

Do a dncon or rrtcon

CSCdr90786

Symptom:

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

Conditions:

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

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

Workaround:

None.

CSCds06186

Symptoms:

CC alarm is not always reported.

Conditions:

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

Workaround:

None.

CSCds17859

Symptom:

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

Conditions:

When CWM FTPs files from the node.

Workaround:

None.

CSCds20527

Symptom:

The CWM Software(ConnProxy module) will notice timeouts while creating Connections continuously.

Condition:

SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).

Workaround:

None.

Additional Information:

Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.

CSCds24362

Symptoms:

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

Conditions:

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

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

(3) dnport on the UNI on NODE_EP1.

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

Workaround:

None.

CSCds31775

Symptom:

AXSM card continuously resets.

Condition:

Unknown

Workaround:

None.

Additional Information:

Reseat the front and back cards.

Frequency:

One time occurrence.

CSCds36438

Symptom:

Standby card does not come up after a restoreallcnf.

Conditions:

The database for the Standby card is corrupted.

Workaround:

Perform sysClrallcnf on the standby card.

Frequency:

One time occurrence.

CSCds46455

Symptoms:

After a PXM switchover, all AXSMs went to the failed state.

Conditions:

There is a communication failure between the new active PXM and all the AXSM cards in the node. This was seen once and could not be reproduced since.

Workaround:

If there is a standby PXM in the standby Ready state, switch to that card. Otherwise, perform a node reset using the resetsys command.

CSCds46524

Symptom:

The dsppnports show links to be down after APS switchover or after card/node boot up.

Condition:

Some application (APS suspected) generate lots of snmp traps. and this will clog all 1k IPC buffers, leading pxm and axsm comm been broken. since vsi master-slave will have Alloc fails for IPC buff.

Workaround:

Reduce the number of ports.

Frequency:

One time occurrence.

CSCds47626

Symptoms:

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

Conditions:

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

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

(3) Some connections might failed to route.

Workaround:

none.

CSCds52922

Symptom:

vsiErr 0xe007 is logged on the axsm console

Condition: Not clear.

Workaround:

None

Frequency:

Intermittent.

CSCds54794

Symptoms:

When APS line is added and the controller is reset, the establishment of SSCOP links is delayed.

Conditions:

When APS line is added on a port and after this if the system is reset, then SSCOP link takes a while to re-establish.

Workaround:

None.

Frequency:

Intermittent.

CSCds54946

Symptom:

VP Connections are slow to route

Condition:

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

WorkAround:

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

CSCds56802

Symptom:

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

Condition:

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

WorkAround:

None.

Additional Information:

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

CSCds57511

Symptoms:

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

Conditions:

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

Workaround:

Switchcc on the active PXM.

Frequency:

One time occurrence.

CSCds60742

Symptom:

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

Conditions:

Normal operation

Workaround:

None.

CSCds61188

Symptom:

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

Condition:

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

Workaround:

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

CSCds63497

Symptom:

TLB exception on one of the FTP tasks.

Conditions:

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

Workaround:

If redundancy is enabled, conduct a switchover.

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

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

Frequency:

One time occurrence.

CSCds63635

Symptom:

It takes a long time for some connections to route.

Condition:

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

After 30 minutes the PTSE update clears this problem.

WorkAround:

None

CSCds63689

Symptoms:

PXM card was reset and a core dump was generated.

Conditions:

This problem occurred while the user was trying to change the external BITS clock cable.

Workaround:

Do not adjust the cable if the cable is attached to the active PXM. This will prevent a node reset (if the standby PXM is not ready) and the above problem is triggered.

Frequency:

One time occurrence.

CSCds63745

Symptom:

The tstconseg fails on BPX when it is connected to AXSM.

On AXSM it results in large delay.

Condition:

Interworking issue between BPX and MGX. It only happens in the interworking scenario and not when they are connected to same equipment.

Workaround:

None

CSCds64258

Symptom:

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

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

Workaround:

None.

CSCds64282

Symptoms:

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

Conditions:

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

Work Around:

None.

CSCds64302

Symptom:

tVsiSync task crashes, when the standby attempts to load a new firmware revision But the axsm card eventually comes up.

Conditions:

The AXSM card seem to crash while performing a VSIrmGetConnRef or qe_mf_fill operation.

Workaround:

None

Frequency:

Intermittent.

CSCds65195

Symptom:

The shellconn command lkup pnni_base_group causes the pxm to reset.

Condition:

This seems to occur for the specific string pnni_base_group every time.

Workaround:

Avoid using lkup. If this is not possible, avoid "lkup pnni_base_group".

CSCds66741

Symptom:

dspcds shows critical alarm on some AXSM cards but dspndalms does not show any alarm. This is only a display problem.

Condition:

Sometimes this is seen after PXM switchover.

Workaround:

None.

CSCds67334

Symptom:

In an AXSM redundant pair, the standby AXSM become active and active AXSM become Standby.

Condition:

None.

Workaround:

None.

CSCds67426

Symptoms:

Two PXM45 nodes with one end has primary and secondary clock configured (first node) another end has clocking sources (second node) have been reset. 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 in 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

Conditions:

One node is up before second node.

Workaround:

Reconfigure the clocks with cnfclksrc commands.

CSCds68426

Symptom:

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

Condition:

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

WorkAround:

None.

Additional Information:

dncon and upcon will recover the connection.

CSCds69511

Symptoms:

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

Conditions:

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

Workaround:

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

CSCds69515

Symptoms:

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

Conditions:

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

Workaround:

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

CSCds69518

Symptoms:

SVC Based RCC cannot be established on ABR service category.

Conditions:

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

Workaround:

There is no workaround to this situation.

CSCds71721

Symptom:

AXSM cards continuously switch between Active and Standby when connected to feeder.

Condition:

Active and Standby back cards were unequal, one had 2, one had 1.

Workaround:

Use the same number and same type of back cards in Active and Standby. This has so far been reported only in one card. If the above doesn't work (replace Front and Daughter cards).

CSCds74175

Symptom:

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

Condition:

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

Workaround:

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

CSCds74195

Symptom:

clrchancnts command does not clear all the counts.

Condition:

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

Workaround:

Use clrchancnts after dspchancnt. The values will be cleared.

CSCds74565

Symptoms:

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

Conditions:

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

Workaround:

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

S3 BUGS

 

CSCdr50289

Symptom:

XBAR plane available Multicast event buffer got corrupted.

Condition:

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

Workaround:

None.

CSCdr50889

Symptom:/

-dsplns command accepts junk as input parameter.

Condition:

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

Workaround:

None

CSCdr77019

Symptom:

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

This is the SNMP region - region2.

Conditions:

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

Workaround:

None.

Additional Information:

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

CSCdr78943

Symptom:

cnfpnportcac command from PNNI cli will fail.

Condition:

When a combination of MaxBw and Bookfactor values are modified at the same time, AXSM can reject the configuration erroneous.

Workaround:

Perform the configuration of bookfactor and max-bw one after another.

CSCds01758

Symptom:

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

Condition:

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

Workaround:

None

CSCds03436

Symptom:

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

Condition:

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

Workaround:

None.

CSCds03683

Symptom:

dsppnni-node command does not display the Node Name.

Condition:

Sometimes, the dsppnni-node does not reflect the node name even though the prompt on the node displays it. This is not service impacting.

WorkAround:

None

CSCds05239

Symptom:

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

Condition:

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

Workaround:

Do not type quit during display of dspsarcnt.

CSCds06083

Symptoms:

addport, addpart, delport or delpart commands can be rejected

Condition:

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

Workaround:

None

CSCds11605

Symptoms:

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

Conditions:

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

(2) Connections are established from NODE_EP1 to NODE_EP2.

(3) perform a switchcc on NODE_EP1.

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

Workaround:

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

CSCds16572

Symptom:

AXSM reboots and is stuck in failed state.

Conditions:

Trying to burn non-existent boot code.

Workaround:

None.

CSCds17159

Symptom:

The data transfer fails in popeye2 node for data option with aesa_ping command

Condition:

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

Workaround:

None.

CSCds17564

Symptom:

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

Conditions:

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

Workaround:

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

CSCds17719

Symptom:

No access to node via LAN

Conditions:

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

Workaround:

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

CSCds20339

Symptom:

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

Condition:

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

Workaround:

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

CSCds25447

Symptom:

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

Condition:

Not applicable.

Workaround:

Not applicable.

CSCds25483

Symptom:

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

Condition:

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

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

Workaround:

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

CSCds27446

Symptoms:

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

Conditions:

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

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

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

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

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

Workaround:

Do not perform switchover while rerouting/derouting connections.

CSCds27960

Symptom:

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

Condition:

Working line fails.

Workaround:

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

CSCds29751

Symptom:

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

Condition:

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

Workaround:

None.

CSCds30648

Symptom:

Standby stays in i state and do not become standby ready

Condition: This has happened only once when tester did reboot of active card when standby was not ready. This is something

not recommended. This problem didn't happen after that.

WorkAround:

None

CSCds31074

Symptom:

Resources could leak.

Condition:

CNTRL-C is pressed to abort a CLI command which is in process.

Workaround:

Avoid aborting an in progress CLI command by CTRL-C.

CSCds31341

Symptoms:

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

Condition:

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

Work Around:

None

CSCds32464

Symptom:

Sometimes, operator cannot connect to the PXM console port from a PC. This problem is not seen from UNIX based terminals.

Condition:

None.

Workaround:

Execute PXM switchover.

CSCds32847

Symptoms:

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

Conditions:

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

Workaround:

Provision with CDV/CTD values.

CSCds33218

Symptom:

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

Condition:

An FTP request is interrupted during logout.

Workaround:

None.

CSCds33855

Symptoms:

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

Conditions:

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

Workaround:

Event logs can be read on redundant PXM card.

CSCds35707

Symptom:

The message header "Cause Rcv Count Xmt Count" displayed repetitively.

Condition:

This is an intermittent problem and happens on some nodes, sometimes.

Workaround:

None.

CSCds38742

Symptoms:

If min VPI and max VPI values are misconfigured on PNNI controller and AXSM then "dsppnport" command will show min VPI to be more than max VPI.

Conditions:

Following is an example where min VPI can be calculated as more than max VPI.

1. On AXSM (a) minVpi = 4095 (b) maxVpi = 4095

2. On Controller (a) minVpi = 0 (b) maxVpi = 255

The usable VPI range can be calculated as (a) minVpi = max of (minVpi on AXSM, minVpi on PXM) (b) maxVpi = min of (maxVpi on AXSM, maxVpi on PXM)

This yields (a) Usable minVpi = 4095 (b) Usable maxVpi = 255

This configuration would mean no VPI on this interface can be used.

Workaround:

Configure the min and max VPI values correctly so that there is always a usable range.

CSCds40655

Symptom:

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

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

Condition:

None

Work Around:

None

CSCds42201

Symptom:

Standby PXM45 card is in continuous reset loop, all AXSMs 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

CSCds42505

Symptom:

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

Condition:

Injecting a hardware failure on SRAM component of Active PXM45 card manually.

Workaround:

None

CSCds43034

Symptom:

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

Condition:

Injecting a hardware failure on SRAM component of Active PXM45 card manually.

Workaround:

None

CSCds43093

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.

CSCds43124

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

CSCds43165

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

CSCds43545

Symptoms:

popup message appear on screen.

Condition:

When trying to do a delcon.

WorkAround:

None.

CSCds43553

Symptom:

No trap is seen on HP Open View after PXM45 card switchover

Condition:

Injecting a hardware failure on BRAM component of Active PXM45 card manually.

Workaround:

None

CSCds43554

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

CSCds43557

Symptom:

Event log file got corrupted

Condition:

Injecting a hardware failure on BRAM component of Active PXM45 card manually.

Workaround:

None

CSCds43560

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

CSCds43563

Symptom:

Sometimes, Standby PXM45 card goes to Failed state.

Condition:

Injecting a hardware failure on SRAM component of Standby PXM45 card manually.

Workaround:

None

CSCds45296

Symptom:

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

Condition:

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

Work Around:

None

CSCds45411

Symptoms:

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

Conditions:

The error messages are seen in the following cases

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

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

Workaround:

None

CSCds45450

Symptom:

The standby PXM45 card fails to become standby.

Condition:

After switchover of PXM45 cards.

Workaround:

Reset the standby PXM45 card.

CSCds53634

Symptom:

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

Condition:

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

Workaround:

None.

CSCds54873

Symptom:

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

Condition:

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

Workaround:

None

CSCds55631

Symptom:

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

Condition:

All port state changes.

Workaround:

None.

CSCds55940

Symptom:

Card alarm is generated when core redundancy is lost.

Condition:

Even when core redundancy is disabled using cnfndparms.

Workaround:

None

CSCds58507

Symptom:

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

Conditions:

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

Work Around:

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

CSCds58518

Symptom:

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

Conditions:

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

Work Around:

None

CSCds58799

Symptom:

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

Condition:

It is the syntax for this command.

Workaround:

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

CSCds58912

Symptom:

CC alarm is not always reported.

Condition:

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

Workaround:

None.

CSCds62345

Symptom:

System runs out of memory due to a memory leak.

Condition:

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

Workaround:

None.

CSCds63066

Symptom:

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

Conditions:

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

Workaround:

Reset the failed AXSMs once the Standby PXM is READY.

CSCds63506

Symptom:

No defect will be exposed to user.

Condition:

Not applicable.

Work around:

Not applicable.

CSCds65600

Symptom:

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

Condition:

Whenever the force resync kicks in.

Workaround:

None.

CSCds72007

Symptom:

The AXSMs always download the firmware image from the Active PXM disk.

Conditions:

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

Workaround:

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

CSCds73161

Symptom:

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

Condition:

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

WorkAround:

None


Problems Fixed in Release 2.0.11

Bug ID
Description
S1 Bugs
 

CSCdr70497

Symptoms:

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

Conditions:

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

Workaround:

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

CSCds07776

Symptom:

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

Condition:

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

Workaround:

Reset the corresponding ACTIVE card.

Problem Occurrence:

Intermittent or occurs once.

CSCds16063

Symptoms:

SPVCs do not get routed.

Conditions:

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

Workaround:

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

CSCds22416

Symptoms:

The problem will cause UBR calls to fail

Conditions:

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

Workaround:

None

CSCds24309

Symptom

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

configuration

 J1.3.AXSM.a > dspapsln 3.1.5
   Working Index          : 3.1.5           Protection Index       : 4.1.5          
   Provisioned Arch       : 1+1             Provisioned Direction  : bi             
   Operational Arch       : 1+1             Operational Direction  : bi             
   Active Line            : working         WTR(min)               : 5              
   SFBer 10^-n            : 3               SDBer 10^-n            : 5              
   Revertive              : Yes             Last User Switch Req   : 
ForcedW->P     
   Bridge State           : WChan Bridged   Selector State         : 
Selector Released
   Protection Line Pending Request   : SignalFailLowPriority
   Working Line Pending Request      : None
   APS Trouble Mask                  : ProtectionSwitchingByte,ModeMismatch
                   Bit Map    Req Field            Chan Field     
   Transmit K1     0xc0       Sig Fail Low         Null Channel   
   Receive K1      0x20       Reverse Request      Null Channel   
   Current Request 0xc0       Sig Fail Low         Null Channel   
                   Bit Map    Chan Field           Arch Field      Dir Mode 
Field 
   Transmit K2     0x5        Null Channel         1+1             BI             
   Receive K2      0xd        Null Channel         1:1             BI             
   Alarm State     Clear  

Condition

Repeated switchredcd causes this condition when APS is provisioned.

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

Work Around.

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

CSCds24374

Symptoms:

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

Conditions:

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

Workaround:

None

Additional Information:

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

CSCds26049

Symptom:

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

Conditions:

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

Workaround:

Use setrev to go to release 2.0(30)A1

CSCds28030

Symptoms:

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

Condition:

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

Workaround:

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

CSCds33324

Symptom:

PNNI can't detect bad clock source.

Condition:

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

Workaround:

Not available

CSCds34606

Symptom:

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

Conditions:

switchredcd with invalid slot values.

Workaround:

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

CSCds34659

Symptom:

Shelf Manager task got suspended.

Condition:

Exception in the Shelf Manager task.

Workaround:

Pullout the PXM45 card and re-insert it.

CSCds34714

Symptom:

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

Conditions:

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

2) execution of "resetsys" command from cli.

Workaround:

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

CSCds37401

Symptom:

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

Condition:

Repeated valid and/or invalid addred/delred commands.

Workaround:

None

Additional Information:

Reboot the Active AXSM card.

CSCds40915

Symptom:

pnCcb task gets suspended

Condition:

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

WorkAround:

None

CSCds44402

Symptom:

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

Conditions:

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

Workaround:

None.

CSCds45313

Symptom:

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

Condition:

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

Workaround:

None.

CSCds46519

Symptom:

ilmi task crashes and card may reset.

Condition:

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

Workaround:

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

CSCds47673

Symptom:

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

Conditions:

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

Workaround:

None

Other Information:

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

CSCds50617

Symptom:

The Standby PXM/AXSM fails to come up.

Conditions:

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

Workaround:

The Active peer of the failed card should be rebooted.

CSCds51901

Symptom:

Floating point exception and system gets reloaded automatically.

Condition:

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

WorkAround:

none

CSCds52919

Symptom:

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.

Solution:

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

Workaround:

None

CSCds56700

Symptom:

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

Conditions:

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

Work Around:

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

CSCds57024

Symptoms:

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

Conditions:

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

Workaround:

Reset the card on the switch (AXSM).

CSCds63376

Symptom:

Axsm card resets while attempting to read sct file.

Condition:

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

Workaround:

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

CSCds68882

Symptom:

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

Condition:

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

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

Workaround:

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

Note:

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

CSCds71908

Symptom:

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

Condition:

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

Unknown.7.PXM.a > bootChange
'.' = clear field;  '-' = go to previous field;  ^D = quit
boot device          : lnPci
processor number     : 0 
host name            :  
file name            : 
inet on ethernet (e) : 0.0.0.0 
inet on backplane (b): 
host inet (h)        : 0.0.0.0 
gateway inet (g)     : 0.0.0.0 
user (u)             :  
ftp password (pw) (blank = use rsh): 
flags (f)            : 0x0 
target name (tn)     : 
startup script (s)   : 
other (o)            :

Workaround:

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

CSCds76260

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

Conditions:

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

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

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

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

Workaround:

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

Further Problem Description:

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

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

S2 Bugs

 

CSCdr50503

Symptom:

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

Condition:

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

Workaround:

None

CSCdr78869

Symptom:

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

Condition:

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

Workaround:

None

CSCdr89686

Symptom:

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

Conditions:

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

Workaround.

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

CSCdr94471

Symptoms:

Standby PXM45 card gets reset 3 times and stays in Failed state.

Conditions:

Upgrading PXM45 image from previous version to a new version.

Workaround:

Reset the standby PXM45 card

Problem Occurrence:

Intermittent or occurs once.

CSCds01593

Symptom:

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

Condition:

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

Workaround:

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

CSCds08941

Symptoms:

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

Conditions:

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

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

(3) dnpnport on the NNI on NODE_VIA.

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

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds09512

Symptoms:

AIS is not generated when dnport issued on AXSM

Conditions:

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

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

Workaround:

None.

CSCds09604

Symptom:

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

Conditions:

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

Workaround:

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

CSCds09708

Symptom:

SNMP GETs on the following variables:

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

Condition:

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

Workaround:

None

CSCds12955

Symptom:

Calls not routed after setrev

Condition:

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

WorkAround:

None:

Addition Information:

Down and up the nni port which is in attempt state

CSCds13444

Symptom:

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

Condition:

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

Workaround:

None.

CSCds13984

Symptom:

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

Condition:

Problem occurs when addln is entered instead of addlnloop.

Workaround:

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

CSCds14832

Symptom:

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

Condition:

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

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds16776

Symptom:

The conn pending congestion counter shows negative values.

Condition:

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

Workaround:

None.

CSCds17876

Symptoms:

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

Conditions:

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

Workaround:

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

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

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

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

CSCds18258

Symptoms:

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

Condition:

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

Work Around:

No work around

CSCds18328

Symptom:

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

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

Workaround:

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

CSCds19314

Symptom:

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

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

Workaround:

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

CSCds20504

Symptom

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

Condition:

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

Work around

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

CSCds23341

Symptom:

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

Condition:

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

Workaround:

Disable ingress cac. Need to verify this

Problem Occurrence:

Intermittent or occurs once.

CSCds23518

Symptom:

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

Condition:

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

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds23525

Symptom:

Pnni-link port is in attempt state.

Condition:

Multiple switch overs and reset of slave cards.

Workaround:

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

Problem Occurrence:

Intermittent or occurs once.

CSCds23579

Symptoms:

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

Conditions:

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

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

(3) dnpnport on the UNI on NODE_EP1.

(4) uppnport on the same UNI on NODE_EP1.

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

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds24399

Symptom:

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

Conditions:

switchcc shortly after a switchredcd

Workaround:

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

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

CSCds25413

Symptom:

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

Condition:

Once the node is in a state of congestion caused by too many calls in the state of being setup or being torn down, we need to process RELEASE messages immediately so as to alleviate the congestion. There was a problem noticed in this path where RELEASE message processing was being deferred.

Workaround:

None

CSCds25534

Symptom:

Connections are not able to route due to running out of trk vpi/vci even vpi/vci should not be running out

Condition:

Reset either master node or via node

Workaround:

reset the trunk card

CSCds26981

Symptom:

The AXSM fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.

Condition: There are more than 4 AXSMs in the shelf and the file descriptor list gets corrupted on the ACTIVE or STANDBY PXM.

Workaround:

None

Additional Information:

1. Reset the PXM card which has the file descriptor list corrupted if redundancy is available. 2. Call the support to rectify the file descriptor list to avoid resetting the card.

CSCds28316

Symptom:

A nni port with ilmi on is stuck in auto cfg.

Condition:

A "none" port or "ip" port was reconfigured as "pnni10" port and ilmi is enabled on the port.

Workaround:

Configure the port as "uni31" and then back to "pnni10". The port will come up as nni.

CSCds28453

Symptom:

When a dncon / upcon is performed on an endpoint, the connections' upload counter is not updated. Use dspcons to see the upload counter.

Description:

Whenever there is a change in the conn. cnfg the upload counter is updated. This was caused by a error in coding (which excluded the admin status change as a config change).

Workaround:

None.

CSCds28520

Symptom:

OC48 Card CLI hangs, and one cannot execute any commands.

Condition:

Some event on the OC48 back card such as APS switchover, card switchover and back card pull.

Workaround:

Reset the hung card.

CSCds30075

Symptoms:

The PSB condition caused by any condition other than the invalid code is cleared even though the PSB condition has not disappeared.

Condition:

This problem can be created by causing a PSB condition through any cause other than the invalid code.

Workaround:

None

CSCds30425

Symptoms:

An AXSM card may be reset immediately after a PXM switchover.

Conditions:

If an user executes a switchcc command (graceful PXM switchover) while an AXSM card is in the process transitioning to the Active Ready state, that AXSM card will be reset by the new active PXM after the PXM switches over.

Workaround:

Run dspcds to verify that all cards are in a steady state (steady card states are: READY, FAIL, EMPTY, MISMATCH) before executing a grace pxm switchover.

CSCds30710

Symptom:

Standby OC-48 card stuck in reset init state.

Condition:

Standby card was reset.

Workaround:

None

CSCds30721

Symptom:

LCN resource not available and connection commit keep failing

Condition:

de-routing of connections and switchredcd of the trunk card at the same time.

Workaround:

None

CSCds31496

Symptom:

Root task could not delete a suspended task.

Condition:

When a software download task gets suspended.

Workaround:

Reset the card using resetcd command.

CSCds32205

Symptom:

User adds feeder on an interface on which connections exist

Conditions:

User will not be able to delete feeder unless connections are deleted. This could be a problem since feeder might have being added by mistake. A CLI prompt should be added to warn users about this.

WorkAround:

Before adding feeder on a particular interface, make sure it is the right interface especially if there are previous connections on it.

CSCds32276

Symptom:

No immediate symptom. Over time when many addapsln/delapsln/dspapsln commands have been executed, we may get IPC message allocation errors.

Conditions:

Execute addapsln, delapsln or dspapsln commands.

Workaround:

None

CSCds32318

Symptoms:

Line shows that there are some statistical alarms, although, the line has no defects. There are no adverse effects of this.

Conditions:

On a t3 line, when line is enabled.

Workaround:

None.

CSCds32413

Symptom:

After a addred or switchredcd, there may be alarms on some channels in the Active AXSM card.

Condition:

Happens after a addred or a switchredcd

Workaround:

None.

CSCds34183

Symptom:

The symptom is that the VSICore and RM database are not in sync. The vsicore indicates the connection is in committed state, and RM is in reserved state.

Condition:

This situation will happen when the Commit timeout, VSICore will Nak the controller, instead of putting the connection is NULL state, the connection is put in commit state.

Workaround:

None

CSCds34687

Symptom:

The VPI range will be 0-255 for NONE port even the AXSM port is a NNI. This blocks the user to use the VPI bigger than 256.

Condition:

None.

Workaround:

None.

CSCds35591

Symptom:

swichred on PXM, standby becomes active, reset the newly standby PXM,

Condition:

Couple of connections stay in failed state

Work Around:

reroute the failed cons (via rrtcon)

CSCds35710

Symptom:

In a node with thousands of calls, we see that the unacknowledged status enquiry counter is beyond the threshold value. This is seen using the command dspintfcongcntr for a particular interface.

Condition:

We might get into this condition due to PXM switchover. The effect of this is that status enquiry can no more be initiated for audit purposes resulting in erroneous dangling connections being present forever.

Workaround:

none

CSCds36145

Symptom:

Getting incremental RAM Sync send error after line/port/partition commands are executed. See description for display details.

Condition:

Card redundancy are setup. Both active and standby are in ready state. Then standby card is removed.

Workaround:

Do not execute line/port/partition command in redundancy setup when standby card is absent.

CSCds36182

Symptom:

During AXSM switchred, previously standby card gets PHYTask exception while transitioning to active. Ports go into provisioning state.

Condition:

This happens on non-OC3 AXSM cards. Should not be problem for all AXSM card if there is no redundancy.

Workaround:

Do not switchred.

Problem Occurrence:

Intermittent.

CSCds36677

Symptoms:

After AXSM sends a passup command to the controller, the message counter doesn't increment for the passup cmd message.

Conditions:

(1) On AXSM, perform addcon, causing a passup command to be sent from the AXSM to the PXM.

(2) After the command is transmitted, perform the shell command vsiPduCountShow. The counter for passup command is not incremented.

Workaround:

-none.

CSCds37301

Symptom:

ports in standby card stay in "vc failure"

Condition: with multiple switch over of two controller cards

Workaround:

none

CSCds37761

Symptom:

The Active PXM gets a software exception and resets unexpectedly when a file is transferred onto the Active PXM using FTP.

Conditions:

When a file is transferred using FTP onto the Active PXM hard disk to a directory that is replicated to the Standby PXM, at times, the Active PXM completes the replication of the file to the Standby PXM at the same time as an internal software timeout. This results in Active PXM generating a software exception which causes the Active PXM to reset.

Workaround:

None

CSCds38135

Symptom:

dspenvalms shows DC Level outside of threshold range, but no node alarm generated

Conditions:

Power entry module being used to generate power supply voltage. When voltage drops below 3 volts, monitoring software declares that the inputted voltage for threshold check purposes is zero.

Workaround:

None. Under this condition there is no alarm. Should this voltage had been generated in a system with a resident power supply module, an alarm would be generated.

CSCds38320

Symptom:

Some SPVC connections will not be routed and stays in fail state

Condition: Unknown

WorkAround:

Delete SPVC end point and re-add it again.

CSCds38562

Symptom:

Two GLCN programs the same ELT Entry in HUMVEE. HUMVEE will indicates ELT Mismatch, no traffic will be passing through.

Condition:

PNNI try to commit the same SSCOP/RCC/IP connection on two different GLCN.

Workaround:

dnpnport and uppnport to check whether problems goes away, if not, please reset the PXM45.

CSCds39375

Symptom:

A nni port has a vpi range of (0-255) available instead of the complete range (0-4095).

Condition:

When ports are provisioned to controller, the default interface type is UNI which at release 2.0.30(D) takes on an enforced range of 0-255. Add nni ports with vpi range 0-4095 on AXSM card. Ilmi is turned on these interfaces. The interfaces on used as nni links.

WorkAround:

Use "cnfpnportrange" command to increase the range to (0-4095).

CSCds41314

Symptom:

Alarms show up in dspcdalms <slot> for the standby card after a switchred.

Condition: Occurs intermittently after switchred.

Workaround:

Another switchred can clear the condition.

CSCds41496

Symptom:

Resources are not updated for a trunk even after connections have routed along them. This is visible in the dsppnportrsrc command. Connections may not route along expected paths.

Condition:

Upon AXSM reset, addcontroller-delcontroller, AXSM switchover.

WorkAround:

None

CSCds41592

Symptoms:

Before switchcc, take the physical connection out (ex. 3:1.1:1).

dspclksrc

Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: no clock signal Secondary clock type: generic Secondary clock source: 14:1.1:1 Secondary clock status: ok Secondary clock reason: locked Active clock: secondary source switchover mode: non-revertive

After switchcc

Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: not configured Secondary clock type: okay Secondary clock source: 14:1.1:1 Secondary clock status: not configured Secondary clock reason: okay Active clock: internal clock source switchover mode: non-revertive

Conditions:

During switchover (the clock resynchronization), If we get NAK from AXSM, the existing code did not assign the right slave id. This cause the set clk message did not send to the clk manager. The display never been updated according to clock manager current status.

Workaround:

Make sure the clock port is up (or make sure the port physically connect the clock source), before doing switchcc.

CSCds41617

Symptom:

Receive RAI count is not cleared by clralmcnt command.

Condition:

For each instance that RDI is received, RAI count is incremented. This can happen in T3/E3 and SONET AXSM cards.

Workaround:

Keep a log of the current "Num of RAI" in order to recognize new RDI received.

CSCds41628

Symptom:

Power supply failure does not generate a node alarm.

Conditions:

External DC power source is used to generate power for node. Circuit breaker is tripped on the power source.

Workaround:

None. Software declares a missing power source normal if it has a power reading of zero volts.

CSCds41931

Symptom:

Connection routing failure due to AvCR being zero on PNNI link that previously was out of LCNs.

Conditions:

In addition to the above symptom the condition for this problem to occur is that the LCN availability remains under 8 on the link of interest.

Workaround:

None.

CSCds42022

Symptom:

Trap 60004 cwShelfRestart was not received after a node reset from CLI "resetsys" command.

Condition:

Upon CLI "resetsys", "reboot", or "resetcd"; On certain hardware, the SNMP master agent takes longer to read the disk DB to extract the trap manager IP addresses and configure the trap communities. Thus, by the time the trapserver needs to send traps out, the community strings are not configured and the traps are dropped.

Workaround:

No known workaround.

CSCds44016

Symptoms:

When SPVCs are tunneled through an DAX-SVP connecting two VTs configured with different VPIs, the connection will not be accepted.

Conditions:

When there is a configuration error in provisioning different VPIs across VTs connected via DAX-SVP

Workaround:

The workaround for this problem will be to remove this configuration error and use the same VPI across the VTs

CSCds45150

Symptom:

Port gets stuck in down in progress.

Condition:

The network should have 50k routed spvc connections. Multiple nni links on a node.Down a a nni port on axsm on one of the node.

Workaround:

No work around.

CSCds45453

Symptoms:

Standby AXSM gets reset multiple times before it becomes standby ready

Condition:

When the syncRamElementAdd fails while connection bulksync, the code erroneous released the iovPtr, which was still used by the higher layer for adding connections into the list. This corrupts memory and when syncRamIovSend is attempted on this bogus iovPtr, the send fails and the active card calls for ramSyncFatalError which resets standby card.

Workaround:

None.

CSCds46551

Symptoms:

When a large number of IISP trunks are configured on the node and a switchover is attempted, system goes into busy state.

This might cause some mismatched connections across the IISP trunks.

Conditions:

When there is a a large number of IISP links are configured on the node and a switchover is attempted.

Workaround:

None

CSCds47500

Symptom:

No event logging is done for APS.

Condition:

None.

Workaround:

None

CSCds47575

Symptom:

Any command on the PXM that accesses the disk will pause for a couple of minutes and displays nothing. Also, any file transfer to the PXM disk will fail. Also, an AXSM fails to load an SCT file and uses default traffic parameters.

Conditions:

When the dsplog attempts to access the log files that have been corrupted, it fails to close the associated file descriptor. This results in exhausting all the file descriptors available on the system over a period of time.

Workaround:

The PXM card should be rebooted.

CSCds50779

Symptoms:

Some connections are derouted and rerouted continuously.

Conditions:

When the SPVCs are provisioned across IISP and the slave endpoints are in the same node of the IISP link, and the IISP is the user side.

Workaround:

Do not provision the SPVC slave endpoint in the same node with the IISP User side.

CSCds51173

Symptom:

-In a popeye2 node, we might have a case where traffic on an SPVC DAX connection cannot be passed though the connection is in OK state on the PXM.

Condition:

This case may occur when the line card containing a DAX connection is removed and re-inserted. After the card-reinsert, the cross connects are not committed to the AXSM in a specific case.

Workaround:

None.

CSCds52449

Symptom:

Configuration on active AXSM is destroyed.

Conditions:

Redundancy is added with active AXSM declared as secondary card.

Workaround:

Make sure that no configuration is enabled on AXSM before adding to redundancy.

CSCds52468

Symptoms:

The ILMI address will not be sent to PNNI for advertisement.

Conditions:

During switchover, the new active will not send the ILMI addresses to PNNI and the addresses will not be visible in the system address tables. The calls for these addresses will not get routed.

Workaround:

There is no workaround to this situation except to reregister the ILMI addresses or switch over the system again.

CSCds52601

Symptom:

With T3 backcard, "addport" or "cnfport" commands fail with min/max port rate at max T3 cell rate (96000 for PLCP mode, 104268 for ADM mode). "dsplns" does show the lines as T3 lines and not E3.

Condition:

The AXSM was reset with E3 backcard in the past, but no "upln" is done using the E3 backcard, i.e., backcard is not reserved for E3. Then the E3 backcard is replaced with T3 backcard and "upln" is done so that ports can be added.

Workaround:

If AXSM T3/E3 backcard is not reserved for a particular type (T3 or E3), reset card when new backcard is inserted before upping lines.

CSCds52916

Symptom:

VTs are still up even when the UNI endpoints on SPVP tunnel are brought down.

Condition:

Two Virtual trunks are connected through a SPVP tunnel. The uni ports the VTs connected are brought down on the controller.

Workaround:

Bring down the ports on the axsm and VTs will stop communicating.

CSCds53212

Symptom:

Active and Standby system were out of sync with each other from PNNI controller point of view. Active side of controller doesn't know that standby is exist.

Condition:

WIN_TIME_OUT means active tries to send but it times out before it can send.

Workaround:

None

CSCds54891

Symptom:

Previously standby AXSM card cannot transition to active ready state after switchred is performed.

Condition:

The AXSM switchred is executed on PXM while AXSM is still in the middle of provisioning ports (using scripts, so once it starts, it does not stop until all ports are done).

Workaround:

Do not switchred until AXSM provisioning is completed. Safer still, wait a few seconds after provisioning before switchred.

CSCds55452

Symptoms:

The problem was handling crankback when VP resources are not available.

Conditions:

Under rare conditions, when VPC resources (like VPI values) was not available for outgoing calls, the release was not generated with a crankback and so an alternate route was not selected.

Workaround:

The workaround for this would be to increase the number of crankbacks or increase the VP resources on the failed link.

CSCds55584

Symptoms

SPVC connections FAILED to route. the Last Fail Cause to be Call Rejected.

Condition:

When adding the partition on AXSM, it is required to configure the maxConns for the partition. The maxConns is constrained to the number of channels supported by a port group. CLI detects, for a given partition ID, if the maxConns entered by the operator exceed the total supported channels with the port group. However, if the operator is adding partitions for different ports that fall within the same port group, as long as each individual partition does not exceed the total supported channels, CLI does not complain the aggregation number exceeding the total supported channels. The problem can be solved by reporting the available channels to PNNI based on the port-group availability which is more accurate.

Workaround:

None

CSCds57279

Symptom:

No traffic passes, PNNI link does not come up, when NNI trunk is configured with a minimum Vpi greater than 255 over an OC48 line.

Condition:

Problem caused by Vpi greater than 255 on OC48 line.

Workaround:

Use a Vpi less than 255 on OC48 lines to avoid this problem.

CSCds57791

Symptoms:

Failure to configure the clock source.

Conditions:

The static memory information has been overwritten by unknown function.

Workaround:


Step 1 goto shellConn by sh command.

Step 2 d &ncdpClockingDb

Step 3 modify the address at &ncdpClockingDb+0xa4 m &ncdpClockingDb+0xa4 (clear to zero).


This procedure will cause the internal code to reallocate new memory to store privateData pointer.

In this way, we can continue to configure the clock.

CSCds58806

Symptoms:

The problem was an unexpected routing failure where some calls never get routed.

Conditions:

Under rare conditions, when the node has many parallel links and many calls using up a small bandwidth, the routing may choose some of the links which cannot support the bandwidth which a new call has requested. This is because the bandwidth change due to previous calls was not significant and so routing doesn't know that the link cannot support the requested bandwidth. In such scenarios, the path table update relies on crankback. With many parallel links, the crankback might not update the path table.

Workaround:

The workaround for this problem is to disable the path table and bring it back up.

CSCds61572

Symptom:

When "dsplns" or "dspln" is executed, there is a "?" in the Frame Scramble field. The line does not come out of alarm by adding physical loopback on backcard or terminal loopback with "addlnloop" command. Resetting card does not get rid of problem. "dspcds" on PXM shows "Active-F" for the slot.

Condition:

This is seen with 2.0(92)A1 sanity label build. It does not happen with earlier build. At some point, "addlnloop" or "dellnloop" has been executed with this label software, after which the Frame Scramble field becomes a "?".

Workaround:

Do not use "addlnloop" or "dellnloop" commands with this build.

CSCds62686

Symptoms:

Some of the ports are in Building VC state after one of the service module cards are reset.

Conditions:

After one of the AXSM cards are reset or reloaded, then the ports may go into Building VC state and never recover.

Workaround:

Reset the card on the switch (AXSM) again.

CSCds63119

Symptom:

When SHM could not update its database to standby PXM, SHM just logs an error. It should reset standby PXM to recover.

Conditions:

N/A

Workaround:

NONE

Further Problem Description:

NONE

CSCds72181

Symptoms:

1) when the active PXM powers up, it stays at the pxm45> prompt with an error message printed saying SHM_BRAM_VER_MISMATCH.

Conditions:

1) The above problem will occur under the following scenario:

a) move a PXM45 card that is running Release 2.1 or greater to a node running release 2.0.11.0 or less

b) insert this card as a standby card in the release 2.0 node

c) when the card becomes standby, make this new standby card the active PXM card in the node.

d) sometimes in the future, reset the node with new active PXM in it.

e) This new active PXM will fail to come up as the active card afterward. It can only be brought up as a standby card only.

or

2) Performing an abortrev or setrev from release 2.1 to 2.0 on the PXM slot on a node can cause the above problem.

or

3) Performing a loadrev/runrev from release 2.0+ to 2.1+ using the standby PXM that was previously already running release 2.1. The database will not be upgraded from release 2.0 to 2.1 when a 2.1 PXM card is inserted as a standby card into this 2.0 node.

Workaround:

1) avoid moving PXM45 cards that are running different software releases (2.0 versus 2.1).

S3 Bugs

 

CSCdr45241

Symptom:

Selecting the front card for testing based in the command syntax given by diagnostics produced an "Invalid syntax" message.

Condition:

Selecting the front card for testing.

Workaround:

None

CSCdr45875

Symptom:

Even with "pagemode off" in effect some CLI command output still pause in the middle with the prompt "Press <CR> to continue, Q<CR> to quit:"

Condition: An off-by-one error in scanning of output caused an inadvertent miss of the Continuation string. This caused the output to be incorrectly halted waiting for user input.

Workaround:

There is no known work around. It is necessary to enter a <CR> in order to continue output. This will allow the output to complete or until the off-by-one error case is once again encountered.

CSCdr86751

Symptom:

AXSM does not detect loss of cell delineation (LOCD), therefore not generating RDI as a result.

Condition:

Line signal with LOCD is injected into AXSM.

Workaround:

No workaround.

CSCdr91962

Symptom:

No mechanism to clear a portion of a node's configuration.

Conditions:

PXM will full configuration including ports, lines and connections. No mechanism to clear provisioning config without also clearing shelf config

Workaround:

None. New mechanism needs to be supported. New command will be clrcnf.

CSCdr95809

Symptom:

When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name.

Condition:

Service affecting command such as switchcc, resetsys, resetcd display the confirmation prompt.

Workaround:

Avoid using command abbreviations.

CSCds05064

Symptom:

Reserved BC (Back Card) alarm missing alarm persists.

Condition:

Even when the cards have been unreserved.

Workaround:

Do shmAlarmUpdate on the for the slot.

CSCds05178

Symptom:

Under certain situations, the restoreallcnf may fail and the node's configuration is not restored.

Conditions:

In a node with both PXMs inserted, if the user performs a restoreallcnf of a database that was saved using a different S/W version, the restoreallcnf may not be successful.

Example:

DB Configuration saved with saveallcnf while the active PXM is running S/W version 2.0.1.0.The PXM F/W is then upgraded and is now running 2.0.2.0. The user then perform a restoreallcnf of the database that was saved from 2.0.1.0.

Workaround:

Remove the standby PXM from the node, then perform the above restoration.

CSCds12357

Symptom:

pnCcb takes too much (75-85%) CPU time

Condition:

When nni ports are brought down in a network with 50K routed connections.

Workaround:

None

CSCds13955

Symptoms:

The dspcds, dspcd and dspcdalms do not show the same alarm information.

Conditions:

Alarms reported on an AXSM card is not integrated into the dspcd and dspcds command.

Workaround:

Use dspndalms to find out the different alarms reported under the different categories.

Use the dspcdalms command to show alarms reported under "Alarms From Cards" category.

Use the dspcd/dspcds commands to show alarms reported under "Shelf Slot Alarms" category by the dspndalms command.

In this version of the Software, the above dspcdalms/dspcd/dspcds commands do not show the combined alarm state from "Alarms From Cards" and "Shelf Slot Alarms".

CSCds15147

Symptom:

The connection summary information displayed by command dsppnport wraps after 80 columns (the output exceeds 80 columns).

Condition:

None.

Workaround:

None.

CSCds16241

Symptom:

output from CLI command dsptasks scrolls off screen

Condition:

Always

Workaround:

None

CSCds16452

Symptom:

dspnodalcongth/cnfnodalcongth: some keyword does not match. The threshold names in these commands were different. For consistency and documentation purpose, the threshold names were made same.

Condition:

None

Work Around:

None

CSCds17195

Symptom:

dsppncon command displays SCR and MBS values for CBR and UBR calls.

Condition:

When CBR and UBR SPVC or SPVP are added, dspcon is not displaying SCR and MBS value where as dsppncon is displaying the same.

Workaround:

None

CSCds17592

Symptom:

Configuration commands cnfspvcprfx cnfilmienable cnfnodalcongth cnfabrtparmdft cnfrrtparm execution is allowed on standby card.

Condition:

Command Descriptor table of ccb showing ANYSTATE for the above commands.

Workaround:

None

CSCds21295

Symptom:

dsplog -task dbClnt will show error sometimes during switchcc of two POPEYE21 pxm cards.

Condition: happen during switchcc

Workaround:

none

CSCds21451

Symptom:

User is allowed to add feeder on a VNNI trunk.

Conditions:

The above should not be allowed since this is not a valid configuration. CLI should be blocked. A feeder should be added only on a physical interface.

Workaround:

Do not add feeder on a VNNI trunk.

CSCds26368

Symptom:

AXSM remains in Init state.

Conditions:

When AXSM is reset, AXSM card remained in INIT state with the following error message:

EmTask - emInitFeeder fails for feeder x because ILMI is enabled.

This occurs if ILMI is enabled on an interface and feeder is added on another interface on the same AXSM card.

Work Around:

Do not enable ILMI on the same AXSM if feeder is added on that card.

CSCds26640

Symptoms:

Can not configure the clock sources.

Conditions:

During ncdp resync.

Workaround:


Step 1 Go to ShellConn.

Step 2 Run the ncdpResetNcdpState command


CSCds27986

Symptom:

When "dspapsln" command is executed using protection line ID as input, the working line ID is same as protection line.

Condition:

No special condition.

Workaround:

Use "dspapsln" with working line ID to find out protection line ID.

CSCds31066

Symptom:

Risky commands such as shutdisk are available and are not needed.

Condition: Users with cisco access level can access these commands.

Workaround:

Avoid using commands, shutdisk and format.

CSCds31146

Symptom:

No mechanism to display current community string value.

Conditions:

Issue cnfsnmp command. Display shows garbage instead of valid community string.

Workaround:

None.

CSCds32730

Symptom:

Programming the backplane NOVRAM on a Jupiter backplane fails with a write error.

Condition:

ATMEL AT93C66 parts are installed on the Jupiter backplane.

Workaround:

None

CSCds33798

Symptom:

On a resetsys, the event was not logged indicating the command and username.

Condition:

Enough activity on the system so the lower priority CLI did not run before the system was reset.

Workaround:

None

CSCds33824

Symptom:

Currently when we try to delete clock, it is an implicit set. This will take longer for the clock manager to re-lock the clock source.

Condition:

When user try to use the command "delclksrc" on PXM45, the implicit set clock will happen.

Workaround:

Don't use the "delclksrc" to del clock source. The new fix will only delete the clock source. It will not try to re-lock the clock.

CSCds34234

Symptom:

When PNNI controller sends a msg which is not recognized by the slave, we send a general Response error msg to the controller. Within the response msg, there is slaveCode which VSI Slave copy the msg header sent. Since the Msg header contains LLC-SNAP header, so VSI Slave copy that as well. But PNNI controller don't interpret SNAP Header.

Condition:

PNNI controller could send a msg which is not supported on VSI SLave.

Workaround:

Make sure that the msg is supported by Slave, if not, the VSI master might not be able to handle the response probably.

CSCds34340

Symptoms:

When you give incorrect value for the line option, it complains about incorrect value for the following option instead. There is no destructive effect of this error.

Condition:

Happens when you do "cnfapsln" command with incorrect value for working line.

Workaround:

There is no workaround.

CSCds35712

Symptom:

PNNI link is in attempt state.

Conditions:

After Y red switchover.

WorkAround:

None

CSCds37762

Symptom:

After executing addlnloop command on axsm card - the event is not recorded in event log.

Condition: Executing addlnloop command.

Workaround:

None.

CSCds40637

Symptom:

SNMP responses and SNMP traps being sent out the incorrect network interface.

Conditions:

Node is being managed by only one CWM or has only one trap manager. During operation, the network interface being used for connectivity is changed.

Workaround:

For traps, create a second trap manager.

CSCds43543

Symptom:

When a switchcc is executed, the following messages appear on the console port of the PXM that transitions from standby to active:

go_active, sync_flag=1 SPVC transiting from Standby to Active

Condition:

None

Workaround:

None

CSCds43550

Symptom:

Pop up messages were seen during configuration of SPVC with cnfcon command

Install has both Legs A(1011801,13,102) and (10c1801,0,42)Configuration successful

Condition:

When trace mod PNNET 1 1 is enabled on the node for debugging purpose, above pop up messages use to appear on the screen

Workaround:

Moved the corresponding debug statement to be seen only when CM debug is enabled.

CSCds44287

Symptom:

No particular symptom. AXSM Diagnostic may cease to run.

Condition:

When some error triggers AXSM diagnostic to print out error traces.

Workaround:

Disable AXSM Diagnostic task traces.

CSCds48531

Symptom:

This was noticed in a customer beta trial. The dspcons on AXSM does not show any alarm. However the dspcdalm <slot> on the PXM45 would display chan alarms for that particular slot. This would translate to a node level alarm in the system;

Solution:

Clearing of card level alarms were not being synchronous with the clearing of channel alarms. This was the cause of mismatch.

Workaround:

Rebooting of the AXSM card will clear the alarms.

CSCds48589

Symptom:

Multiple switchred can trigger XBAR remap twice error. The error is also reported to alarm manager. "Card Crossbar" major alarm will be registered.

Condition:

The problem is intermittent. It is rarely observed. The experiment indicates that the spurious errors can be generated when programming XBAR ASIC even though XBAR remap configuration is correct.

WorkAround:

None

CSCds51524

Symptom:

The different values of K1 when doing switchred and when removing cards is cleared when the redundant card comes up.

Condition:

This condition is created by the inconsistent values transmitted on K1.

WorkAround:

A higher priority command such as lockout of protection of forced switch might clear this condition.

CSCds51688

Symptom:

dspcdalms shows alarms for a card in a particular slot (reported by the card) and dspslotalms shows alarms for the slot reported by the shelfmanager.

Condition:

dspcdalms and dspslotalms show different alarms for the same card.

Workaround:

In order to view alarms for a particular slot, dspcdalms and dspslotalms CLIs need to be used.


Known Anomalies from Previous Releases

CSCdr15133

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

CSCdr15197

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

CSCdr19636

Verified in 2.0.02 dspalm and dspln cmds show diff alarm status

CSCdr20887

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

CSCdr22569

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

CSCdr35241

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

CSCdr43257

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

CSCdr19861

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

CSCdr26669

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

CSCdr28772

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

CSCdr31492

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

CSCdr47777

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

CSCdr86343

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

CSCdr87314

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

CSCdr89382

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

CSCdr89804

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

CSCdr93317

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

CSCdr94471

Closed -- not a problem.

CSCds14824

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

CSCds15089

Closed -- not a problem.

CSCds15159

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

CSCds16742

Duplicate of CSCds27372, which is fixed in 2.0.11

CSCds18690

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

CSCds19282

Un-reproducible Sysbootchange Init Parameters Corrupted

CSCds20287

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

CSCds20318

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

CSCds21342

Closed -- not a problem.

CSCds22604

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

CSCds22824

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

CSCds22862

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

telnet ss.

CSCds22946

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

CSCds23335

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

CSCds23586

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

CSCds23866

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

miss, fixed in an earlier release.

CSCds24168

Closed -- some of the hardware was missing.

CSCds24320

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

CSCds24905

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

CSCds28506

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

CSCds33133

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

CSCds35713

Un-reproducible DLS:DAX conns stayed in conditioning after interface recovered


Release 2.0.01, 2.0.02 and 2.0.10

Problems Fixed in Release 2.0.10

Bug ID
Description
S1 Bugs
 

CSCdr70591

Symptom:

The SRCV task in AXSM gets an address exception.

Condition:

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

Workaround:

None.

CSCdr74831

Symptom:

Receive 60905 or 60904 trap as soon as CWM requests for a config upload file.

Condition:

This condition can be reach, when the system is really busy and the scheduler task does not receive a work request acknowledgement from the worker task. Once the scheduler time out exceeds the threshold, the scheduler task will mark it worker control block for that particular worker task as fail. This will disable that particular worker task from servicing any future work request. Currently, we have three worker task in service. If all three tasks are marked in the worker control block as CUT_FAIL, CWM will no longer be able to request any config upload file. Any request set by CWM will be result in receiving trap 60905 or 60904

Work around:

None

CSCdr87841

Symptom:

Vsi master fails to recover on trying to commit a connection on an existing vpi/vci.

Condition:

Add a connection between 2 AXSM cards. Delete one leg of the connection. Try and commit the connection made earlier again.

Workaround:

None

CSCdr88211

Symptoms:

PXM45 fails to send config message to slave.

Conditions:

If we did not get response or trap message from the vsimw, the ncdpClockingDb. privateMsgPtr never been reset.

Workaround:

The solution is using shell command to reset state(ncdpResetNcdpState).

CSCdr89807

Symptom:

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.

Condition:

If the address present in the SETUP message does not have a match in the filter configured against the port, the system may reset.

Workaround:

Do not associate an address filter with a port.

CSCdr99509

Symptom:

SNMP MIB Walk fails even though the cards are in active state.

Condition:

When CiscoView is used for configuring Redundancy and other things, switch might fail to service mib requests. During registration of the MIBs by Subagent, Master agent gets the maximum bytes to be registered and looks for that many bytes using ssiIpcMessageReceive call with WAIT FOR EVER timeout value. In case the subagent could not send all the bytes due to failure of the cards(Reset, fail ec), master agent waits for ever and other Subagent requests and responses can not be serviced. This will cause the EPID queue to be full and causing IPC messages to be dropped from the subagent.

Workaround:

None

CSCds01070

Symptom:

CWM did not receive trap 60901 to let CWM know that File creation has been started.

Condition:

This occur to any file creation that takes less than one minute. These files are, PXM genrict file, PNNI file, AXSM generic file.

Workaround:

None.

CSCds03375

Symptom:

Cpro shows status indicating AIS state when no AIS state exists.

Condition:

This problem may occur when a connection is modified while in the AIS detection state.

Workaround:

Do not modify connections while they are in the AIS detection state.

CSCds05585

Symptom:

When addpart or and "set partition" type command is executed for VT (VNNI) ports, AXSM card gets SW exception and resets.

Condition:

When addpart, delpart or cnfpart commands on VT (VNNI) ports are executed. This does not happen with UNI and NNI ports.

The ifName format has been modified to conform to dependency doc (see CSCds01124). When ifName is made, it is stored in a static variable of fixed length. The old ifName array length is not enough to contain VNNI ifName, thus overwriting adjacent variables and causes memory corruption. This memory corruption cause SW exception.

Workaround:

Increase the ifName static variable array length to cover VNNI ifName

CSCds07804

Symptoms:

The problem is an unexpected system reload.

Conditions:

When a partition is deleted on the service module and when the load info from the service module is received and processed, the system may reload.

Workaround:

None.

CSCds09032

Symptoms:

When connection reroute is triggered from CWM, the operation would fail

Condition:

Happens when rerouting is attempted from CWM on any routed connection.

Workaround:

Attempt reroutes only from CLI, till this bug fix makes it to the release.

CSCds09374

Symptom:

When pulling out an active AXSM, PXM goes into reset

Condition:

Error threshold time is zero. This can be caused by a corrupted database. User can also use cnfxbarerrthresh to intentionally set the error threshold time to zero.

Workaround:

Do not set error threshold time to zero.

CSCds24374

Symptoms:

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.

Conditions:

If a card is getting reset continuously because of some SW/HW error in the card.

Workaround:

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

S2 Bugs

 

CSCdp73120

Symptom:

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.

Condition:

This is because in AXSM card, resource manager doesn't support asymmetric connections, all connections are assume symmetric, and only egress side traffic parameters are being used.

Workaround:

None

CSCdr50497

Symptoms:

dspsct command does not display proper information.

Conditions:

dspsct to display content of an SCT file in PXM Disk.

Workaround:

If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.

CSCdr71440

Symptoms:

Currently, if a SHM/CTC message protocol timeout occur, only an error is logged. The card will eventually be reset. The timeout for this may be up to 1.5 hours. If the protocol error occurred during a node power up against an AXSM card, the AXSM will be stuck in the INIT state; in addition, the STANDBY PXM card may be affected by this, and may get stuck in the INIT state also.

Condition:

The SHM/CTC message protocol timeout error can be triggered every time there is a communication between the PXM card and any other cards (this is a rare problem.) Typical activity that triggers communication between the SHM(active PXM) and the CTC (any card) are: a) node powering up/reset b) card powering up/reset c) card switches

Workaround:

If a SHM/CTC message protocol timeout error is seen in the log, and the card seems to be stuck in some state (e.g. INIT), reset the stuck card manually using the resetcd command.

CScdr74604

Symptom:

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.

Condition:

The exact condition under which this happened is unknown. Workaround:

None.

CSCdr74850

Symptom:

Trap managers don't see any trap for PXMs switch over.

Condition:

PXMs switch over trap is sent too early when newly active card is not fully up so the trap is lost.

Workaround:

None

CSCdr75239

Symptoms:

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.

Condition:

Powering up a standby card.

Workaround:

When there is a slot alarm, run dspcds/dspcd to show the specific alarm which could be a disk alarm.

CSCdr75434

Symptoms:

Some SPVCs will appear as failed even though the connections are active

Conditions:

This condition will happen when AXSM Switchover is preceded by a trunk LOS causing reroutes.

Workaround:

None.

CSCdr77408

Symptoms:

uni or nni port state goes up and down intermittently.

Conditions:

Problem occurs on any uni or nni port in the axsm card. Problem occurs more often if the card is running at full card bandwidth.

Workaround:

None.

CSCdr77525

Symptom:

To reproduce this problem,

1. add a partition, and pxm cli> cnfpnportcac port-id cbr -minbw 50 axsm sh> rmPartDtlInfoShow.

2. axsm cli> cnfpart.... -emin 100000

3. axsm sh>rmPartDtlInfoShow will shows the interface policy info in each cos has been reset to wrong values.

Condition:

Currently, cnfpart only apply recorded interface policy percentage to each cos, without recalculating the maxbw, and maxvc

, based on how much minbw, minvc has been taken for certain cases.

Workaround:

Don't config interface policy minbw.

CSCdr82076

Symptom:

dspcdalms command does not break after 24 lines to give user an option to either continue display or quit.

Condition:

This happens only when there are more than 6 AXSM cards on the shelf that could cause the display to be more than 24 lines

Workaround:

None

CSCdr85279

Symptoms:

SVC connection is constantly torn down and rebuilt. This causes intermittent outages between node and CWM.

Condition:

SVC connection to router used for IP Connectivity.

Workaround:

None

CSCdr86184

Symptom:

Applications complaining about IPC message allocation failures due to IPC message leak.

Condition:

Applications calling IPC send function with lcn = 0 erroneously.

Workaround:

None

CSCdr86324

Symptoms:

Standby card will be waiting in Init state

Condition:

If any AXSM card in the shelf is waiting indefinitely in Init state, the standby PXM cannot come up.

Workaround:

Reset AXSM card. This will bring up the standby PXM.

CSCdr86680

Symptoms:

Event log entries indicating IPCONN could not send message to vcid 0.

Condition:

SVC connection to router used for IP Connectivity.

Workaround:

Issue reset of SVC using svcifconfig command svcifconfig atm0 router xxxx reset

CSCdr89700

Symptom:

When dspswalms/dspslotalms commands are used to display alarms, displays are inconsistent when there are alarms present compared to when they aren't present.

Conditions:

The inconsistency exists only happens only when an alarm of each

alarm type (displayed when there are no alarms in the system) isn't present.

Workaround:

None

CSCdr90786

Symptom:

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.

Conditions:

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

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

Workaround:

None.

CSCdr91277

Symptom:

A redundancy-deleted trap is sent with secondary slot number set to zero.

Condition:

This problem occurs after deleting redundancy

Workaround:

None

CSCdr93427

Symptoms:

The Cross bar status displayed by the command dspxbarstatus does not reflect the correct status.

Conditions:

This symptom occurs when errors are detected on a XM60 Card.

Workaround:

None.

CSCdr93676

Symptom:

getone on an instance of caviStatEgressTable object does not return the value.

Condition:

Happens when you try to get the value of a single instance of statistics table of any virtual interface.

Workaround:

Use getmany to get the value.

CSCdr94049

Symptom:

The message "Function ssiTaskDelay called by ISR." may appear in the dsplog output.

Condition:

Using CTL-C is used to exit from a CLI lkup command.

Workaround:

Do not use CTL-C to exit the "lkup" command. Use "Q" instead.

CSCdr94469

Symptom:

Message Of IPC Allocation failure seen on the console

Condition:

When we have upgrades going on with many AXSMs and at the same time we have many connections.

WorkAround:

Wait until all the AXSMs come up.

CSCdr94654

Symptom:

Event log messages are not generated.

Condition:

Executing dncon/dnport commands causes the problem.

Workaround:

None.

CSCdr96243

Conditions:

(1) Created 100 ports using addcon.

(2) Did a dnpnport on each of the ports.

(3) Changed the signalling vpi and vci for each port using the following: cnfpnportsig <port-id> -vpi 10 -sigVci 32

The cnfpnportsig command causes a warning to be printed for each port as follows: "** Warning: Signalling VPI IS OUTSIDE OF THE VPI RANGE IT OWNS"

Symptoms:

After about 75 (out of the 100) ports issued the above error message, PXM would temporarily lock up (for about 40 sec) and then continue.

Workaround:

Do not change the signalling vpi to the value which is outside the vpi range it owns

CSCdr97659

Symptom:

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.

Condition:

When a Service Module is physically removed, failed, "addred", "switchredcd", or "resetcd" command is run from CLI, or "reboot" command is run from shell.

Workaround:

None.

CSCdr97665

Symptom:

Failure condition for addred/delred from CWM will always indicate a general error.

Conditions:

CWM used to delred/addred on the node A failure condition occurs for the command from CWM

Workaround:

None.

CSCdr99149

Symptom:

Frame discard field comes as 0 when it is disabled. It should be 2.

Condition:

Problem occurs when FrameDiscard is disabled.

Workaround:

None.

CSCds01843

Symptom:

Link goes down and up when ilmi is enabled in IISP

Conditions:

Two mgx connected via trunk with configuration as IISP and ILMI is enabled in both side.

Workaround:

Disable ILMI.

CSCds02379

Symptom:

After a setrev or a soft reset, a NOVRAM will be corrupted. The specific symptom is a failure of the checksum verification.

Condition:

This problem will occur on rare occasions after a setrev was issued to a node full of AXSM Service Modules. Perhaps one in 60 will fail.

Workaround:

None:

CSCds03654

Symptom:

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.

Condition:

Caused by a failure in the translation routine which converts the internal error codes to a string that the CWM understands.

Workaround:

None.

CSCds03787

Symptom:

User can't modify cdvt of slave endpoint of dax con. Also, in the case of popeye2 node, when user modifies cdvt of master endpoint of dax con, the slave endpoint then is assigned cdvt = -1.

Condition:

Dax con endpoints only.

Workaround:

None.

CSCds03927

Symptom:

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.

Conditions:

"burnboot" command is in progress at a service module slot

"setrev" command is issued before the card is ready

Workaround:

Make sure the flash is updated with the correct boot and the card is ready before doing a setrev on the card.

CSCds03954

Symptom:

When user enters the command "dspvsicons -cksm 0" the CLI task would take an exception.

Condition:

Caused by entering the above CLI command.

Workaround:

Do not use the -cksm option of the CLI command dspvsicons.

CSCds04883

Conditions:

Whenever an APS trap number 60124, 60125

Symptoms:

The trap oid for cwIfIndex is wrong.

Workaround:

None

CSCds05071

Symptom:

MIB Requests(Get,Set, Get-next) comeback with NO SUCH INSTANCE error.

Condition:

At least 13 subagents to be supported in the MGX8850 R2 shelf. However found that we support only 12(a bug) subagents at any point of time. If there are 12 standalone AXSMs in the shelf, then the registration of the last subagent (not necessarily the last slot) will result in error and the MIB Objects for the last subagent will result in errors.

Workaround:

None

CSCds06500

Symptom:

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.

Condition:

1. Adding a new service type for signalling channel caused the problem, on ingress side, one case statement was missing for calculating ecr.

2. It was decided not to apply booking factor to ingress side, after some discussion, we decided to apply booking factor to both sides.

Workaround:

1. None.

2. in shell command line, does sh> VrmEnbIgrCosCac(), will turn on ingress booking factor applying.

CSCds07835

Symptom:

OC12 card result in wrong cell delineation because of the wrong C2 byte configuration.

Condition:

C2 byte was configured with default 01h which does not say the signal contain ATM payload.Now default is changed to 13h(ATM payload).

Workaround:

None

CSCds09194

Symptoms:

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

Conditions:

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

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

(3) Perform a tstdelay on the connection.

(4) If the tstdelay is not successful, then the result will discontinue in "test in progress" mode. Consequently, any subsequent attempts will fail for that reason.

Workaround:

None

CSCds09375

Condition:

Error threshold time is zero. This can be caused by a corrupted database. User can also use cnfxbarerrthresh to intentionally set the error threshold time to zero.

Symptom:

When pulling out an active AXSM, PXM goes into reset

Workaround:

Do not set error threshold time to zero.

CSCds10319

Symptom:

There was buffer overflow in one of trace messages. 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.

Workaround:

None.

CSCds10564

Symptom:

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.

Condition:

"mismatch" Condition can be created by turning off the segment endpoint using command "cnfoamsegep" on the PXM45. After this, if the AXSM were to be rebooted all the persistent endpoints on the card would enter into mismatch state. Now, if the alarm file is uploaded and parsed, it would indicate no alarms on the card.

Workaround:

None.

CSCds11187

Symptom:

Operational status of Protection line is not displayed correctly

Condition:

The problem has been fixed.

Workaround:

None

CSCds13606

Symptom:

SSI event logged as EVENT_ERROR with stack trace of event.

Condition:

When VC manager retries for control VC fails for any reason.

Workaround:

None

CSCds13978

Symptom:

dspcd and dspcds show a card is in failed state but no alarm is raised.

Conditions:

Whenever a card is moved to failed state.

Workaround:

None.

CSCds14777

Symptoms:

Update port sig parameters when the port status is up, it will cause the inconsistence in information display between the dsppnport and dsppnportsig.

Conditions:

The port status is up.

Workaround:

Do not do the cnfportsig command, when the port status is up.

CSCds16773

Symptom:

Standby PXM45 fails to come up after a PXM switchover or new Standby PXM45 insertion.

Condition:

The disk synchronization on Standby PXM45 may fail when, an one or more AXSMs are also coming up at the same time and they are taking longer time due to burning the image onto the flash.

Workaround:

Reset the Standby PXM45 from Active PXM45 using 'resetcd' one more time.

CSCds18258

Symptoms:

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

Condition:

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

Work Around:

None

CSCds19129

Symptom:

Calls with AAL parameter IE octet 12.1 (i.e. partially filled cells method) set to 0 are rejected.

Condition:

As per UNI 3.1 page 201 - AAL parameter IE octet 12.1 partially filled cells method range is 0x01-0x2F. However, in the case of non-compliance equipment, octet 12.1 is set to 0.

Work Around:

None.

CSCds22540

Symptoms:

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

Conditions:

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

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

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

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

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

Workaround:

Do not perform switchover while rerouting/derouting connections.

CSCds22868

Symptom:

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.

Condition:

The problem was been identified as a user state machine error. It will surface in a rare scenario where the sscop link is down while trying to release the active call in the state u10.

Workaround:

The problem will not surface so long as the sscop link is up.


Problems Fixed in Release 2.0.02

Bug ID
Description
S1 Bugs
 

CSCdr22185

Symptom:

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.

Conditions:

These messages can show up when the system is under stress, such

as on system rebuild, and VsiErr due to real errors are meant

to be displayed, but instead warning VsiErrs are displayed

Workaround:

None

CSCdr23168

Symptom:

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.

Conditions:

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

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.

(5) Reset NODE_EP1.

(6) While SPVCs are being established (about 15K), reset the AXSM UNI card.

(7) After the AXSM has come up, a lot of VsiErrs are observed, and then the tVsiSlave task crashed.

Workaround:

(1) Do not reset the UNI AXSM while the PNNI is rebuilding the connections.

CSCdr27919

Symptoms:

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.

Conditions:

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

_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.

(5) down one of the two NNI trunk on NODE_EP1.

(6) While SPVCs are being established (about 15K), reset the active PXM card on NODE_EP1 to cause a PXM switchover.

(7) On the UNI AXSM, a lot of VsiErrs are observed, and then the tVsiSlave task stopped working causing a system reload.

Workaround:

(1) Do not perform PXM switchover while the PNNI is rebuilding the connections.

CSCdr34387

Symptom:

A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost.

Condition:

Happens when a node is fully loaded to 50K connection capacity.

WorkAround:

Avoid connection addition during heavy connection re-routing, link status changes.

After the problem has occurred - SPVCs can be re-added.

CSCdr36772

Symptom:

Bucket statistics file name has incorrect file name.

Conditions:

Suppose the file is created at 5:30 it will have a time of 5:15. The interval is 15 to 30 min. This means that the beginning time is used instead of the ending time.

WorkAround:

None.

CSCdr36954

Symptom:

VC Failure due to insufficient LCNs used up by the user conns. The port stays in VC failure forever.

Conditions:

When more SPVCs are provisioned than the available LCNs, the port could go into VC failure upon few resets on the controller or the Slaves. This happens because of failure conditions to establish connections and if user connections could be established before the control VC connections.

Workaround:

Never provision more than the available LCNs.

CSCdr37025

Symptom:

Some of the provisioning command operation does not get reflected on standby and disk.

Condition:

When there are many spvcs are getting added/deleted/modified within a very short period of time and also at the same time many ports status is oscillating between up and down in that case this may happen.

Work Around:

When port status is oscillating, do not add/mpdify/delete spvcs on it.

CSCdr37302

Symptom:

Unable to ping/telnet to the node intermittently.

Conditions:

This problem occurs in a redundant PXM node. When ping the node from a workstation, the ifShow command shows that the receiving packet counts is incrementing while the send packet counts remains the same.

Workaround:

Reconfigure the interface with the same IP address again using command

CSCdr38809

Symptom:

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.

Condition:

When restoreallcnf is performed, the configuration on the disk is overwritten by the restored configuration on the Active controller card and the configuration needs to be cleared on the Standby controller card before it could synchronize the configuration with that on the Active controller card. This clearing of configuration on the Standby controller card is not done as a part of restoreallcnf. This causes the problem.

Workaround:

You need to clear the configuration using clrallcnf before restoring the configuration. You should make sure that the Standby controller card is in operational state when configuration is cleared. If the Standby controller card is not in operational state when clrallcnf was performed on the node, you should clear the configuration on the Standby controller card when the card is in the boot state using sysClrallcnf command.

CSCdr39120

Symptom:

Reset of AXSM cards and switchover will cause SPVC to reroute.

Condition:

When ILMI is turned on the AXSM, when reset the Peer ILMI module will trigger a Loss of Connectivity and all the calls on the interface will be derouted.

Workaround:

If Using Orion 1.0.x or P-II 2.0.x, disabling the Securelink procedures will not allow the calls to be derouted (cnfilmiproto command can be used to turn off Secure link on a port basis). If not using the above, there is no workaround as secure link is enabled on NNI/UNI links.

pxm1Cli> cnfilmiproto <portid> -securelink no

- turns off the securelink on the NNI trunks. By default its turned on for all the interfaces.

CSCdr40126

Symptom:

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.

Conditions:

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

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 31K+ SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.

(5) Down either of the trunk connecting either NODE_EP1 or NODE_EP2 to the NODE_VIA to cause connections deroute. After the deroute completes, it was observed that the connections in the NODE_VIA are not deleted, and no error were observed.

Workaround:

(1) Restrict the number of connections on the NODE_VIA to less than 31K. This can be done by configuring the partitions for NNI trunks on the NODE_VIA to support less than 31k connections (combined).

CSCdr40620

Symptom:

NO SPVCS. After PXM rebuild some interfaces might disappear.

WITH SPVCS Every time PXM card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception.

Condition:

If any image built between Apr 21, 2000 & Apr 29, 2000 had been used in a node, then there is a possibility for data base corruption, which will lead to this problem.

Workaround:

No workaround.

CSCdr43586

Symptoms:

'ssiIpcMessageAllocate fails' appears on screen periodically.

Conditions:

a. copychans/delchans b. pull out the high speed trunk. For example, we have lot of connection routed over OC3. If we pull out OC3, all the routed conns on OC3 need to be rerouted on, say, T3/E3

Workaround:

1. Avoid using copychans/delchans 2. program the SSCOP signalling channels with higher values of PCR/SCR/MBS. Use cnfpnctlvc to change the default values.

CSCdr43665

Symptom:

The call does not routing with VPI/VCI assignment error.

Condition:

When you have big number of calls (around 16K) in one interfaces and switch-over.

Workaround:

Do not do switch-over when call is in progress and # of calls is around 16K.

CSCdr45695

Symptom:

Could not run "dspln", dspports, etc. Could not walk mib tables.

Conditions:

The "dsplog" CLI output might contain following message:

01-00127 05/12/2000-11:14:26 MIBS-4-SEMTAKE_FAILED E:06412 snmpSA 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.

tSmCmdTskcl: doMibTbls(): Can't get resrc semaphore.: Err from snmpMibSemTake 01-00104 05/12/2000-09:21:54 MIBS-4-SEMTAKE_FAILED E:06409 tSmCmdTskc 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.

Work around:

The Card which has this problem (dsplog -sl <x> has the above message) will have to be reset.

CSCdr46104

Symptom:

Exception in pnCcb task causing the active processor to

reset.

Condition:

Observed on derouting and rerouting SPVCs over an IISP link.

Workaround:

None.

CSCdr47782

Symptom:

Standby PXM reloads

Condition:

When there is too much traffic going on to standby from Active, sometimes connection path gets congested and it may take more than 5 sec.

WorkAround:

None

CSCdr47834

Symptom:

Connection add / delete problems when number or connections is around

30,000+. Possible error message includes, delete failure, non-existing ConnID entry.

Condition:

This problem exists only when the number of connections gets to be around 30,000 or greater.

Workaround:

None

CSCdr47947

Symptom:

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.

Conditions:

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

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.

(5) Reset the UNI card in NODE_EP1.

(6) While the port is in "down in progress" state, perform pxm45 switchover.

(7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state.

Workaround:

One of the following: (1) Do not perform pxm45 switchover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.

CSCdr50312

Symptom:

Standby card will be reset and come back in the higher revision (2.0(1))

The card will then transition to the failed state.

Conditions:

Upgrading gracefully (through the loadrev command) on the PXM with

redundancy available (2 PXMs in the node) between release 2.0(0) and 2.0(1)

Workaround:

Do a non-graceful upgrade by using the setrev command

This will cause the PXMs to be reset and come back in the higher revision

setrev 7 2.0(1)

CSCdr55652

Symptom:

provision the SPVC, the conn is ok but the cell dropped.

Condition:

The SPVC percent util was applied to FWD EP bandwidth and that made the pcr to be 0. This caused the dropping cells.

Workaround:

None

CSCdr56267

Symptom:

Standby PXM45 waits indefinitely in INIT state.

Condition:

Intermittent. Occurs when inserting the standby PXM45 card.

Workaround:

None

CSCdr61082

Symptom:

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.

Condition:

This problem occurs on error conditions like failure of a node,

causes PNNI to report errors (with no throttling) to SHM results in

exhausting the error buffers which in turn results in exhausting

the IPC buffers due to buffer leak.

Workaround:

Reboot the PXM45 card.

CSCdr61204

Symptom:

dspcds will show that the card is in the BOOT state.

Condition:

Card Bringup will sometime get stuck in the BOOT state because a bringup message being sent to the card is lost.

Workaround:

If the card is stuck in the BOOT state, reset the card manually.

CSCdr67620

Symptom:

Intermittently, AXSM cards will get reset due to MCAST_MSG_LOSS.

Condition:

On a fully populated POPEYE2 node when restoreallcnf is performed or when there is a lot of activity during the system bringup.

Workaround:

None

CSCdr71695

Symptom:

Node and card redundancy configuration is lost.

Condition:

Insert a standby PXM45 into a node with a failed active PXM45 can result in the lost of the database on the standby PXM45 card.

Workaround:

Do not insert a standby PXM into a node whose active PXM is already in the failed state (use dspcds on the active PXM to show the card state before inserting the standby PXM.) Remove the failed active PXM before inserting the new standby PXM.

CSCdr73806

Symptom:

dspcds and many other CLI commands will not work.

Condition:

After a long period of time, the PXM45/AXSM cards run out of IPC buffer memory.

Workaround:

Switchcc

CSCdr75500

Symptoms:

SPVCs will fail to route.

Conditions:

This condition will happen when some connections are deleted and a switchover is followed by that.

Workaround:

None

CScdr78831

Symptom:

After clrallcnf, access to the node via TCP/IP makes connection to the standby card rather than the active.

Condition:

Redundant PXM45 configuration using ethernet access for IP connectivity. Boot IP addresses of the PXM45 as well as disk IP address are the same.

Workaround:

Reconfigure boot IP addresses of the PXM45 cards to be unique.

CSCdr80279

Symptom:

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.

Condition:

All connection related traps (add/del/modify/down/up/fail) carried the wrong encoding of the cwaChanVpcFlag for VPC connections.

Workaround:

None.

CSCdr80807

Symptom:

System restarts.

Condition:

Provision 50K SPVC routed connections. In the source node perform the following: - dnpnport <trunk or port> - wait for the connections to be released. When connection are being re-routed, perform uppnport.

Condition:

Workaround:

Disable internal audit by using the CLI command "actaudit disable".

CSCdr82611

Symptom:

When a large number of endpoints are provisioned and if all of them had stats collection enabled, then it is impossible to login or cc to the AXSM card.

Condition:

This was caused by the conn. stats task hogging the CPU time while collecting stats on all those connections. The basic problem was narrowed down to an inefficient search algorithm in the code.

Workaround:

Do not enable stats on connections, without a fix for this bug. The fix involved correcting the inefficient algorithm and reducing the priority of the stats collection task, so that the control point applications can run.

CSCdr82868

Symptom:

IP connectivity cannot be established and remains in SETUP state.

Condition:

If the IP AESA address does not match with the pnni node prefix (the default summary address), the svc connection cannot be established.

Workaround:

Configure the IP AESA address to match the pnni node prefix.

CSCdr85316

Symptom:

IP connectivity setup fails with cause ATM_CAUSE_VPCI_UNAVAIL (35).

Condition:

This happens only within a very small window during PXM switchover. If a RELEASE is received from the link before an application re-listens (registers the address with sigap) on the newly active PXM, the RELEASE would fail and the connection resources would not be freed properly. Therefore, subsequent SETUPs would fail because the vpci is still in use.

Workaround:

None.

CSCdr87319

Symptoms:

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.

Conditions:

Large number of ports configured on the system or high bandwidth data traffic on OC48 cards have shown symptoms like this.

Workaround:

None

S2 BUGS

 

CSCdr25037

Symptom:

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.

Conditions:

In a three-node network with two nodes (NODE_EP1 & NODE_EP2) connected directly as well as via a third node (NODE_VIA), approximately 5000 SPVCs are added between NODE_EP1 and NODE_EP2.

All of these AXSM cards operate in stand-alone (e.g., non-redundant) mode.

The UNI card in NODE_EP1 is rebooted (by resetcd from PXM45 or ESC-CTRL-X).

Immediately after the PXM45 console reports the insertion of the UNI-AXSM, a [switchcc] command is issued.

Workaround:

One of the following: (1) Do not [switchcc] at all. (2) Do not [switchcc] until the rebooted UNI-card is burning the flash (by observing a few cycles of [burning xxxxx verify... ok] messages) (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.

CSCdr27033

Symptom:

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.

Condition:

The clock source manager is the traffic cop for maintaining the correct/best clock source and managing the state of all clock sources. To make sure that the current clock source is valid, frequency and phase error tests are continuously run on the clock source. Should there ever be a sample that shows invalid frequency or phase error, the clock source is placed into "out of lock" state and a more intensive test is done on the clock source. If this intensive test shows enough failure, the clock source is declared unlockable.

To determine if a clock source has been labelled as unusable, there are two methods:

1. From shellconn issue command nclkm_status. Look for the MUXA/MUXB "programmed as" lines of the display. If the source is programmed as "TOP SRM", it has been labelled as unusable.

2. From shellconn issue command dspclockinfo. If clock source is configured but programmed to NULL, then it is labelled as unusable. (NOTE: This display is in the process of change to be more clear about this special clock source state.)

Workaround:

Reconfigure the clock source, even if it is to the same exact configuration to clear the unlockable state. Use cnfclksrc command.

CSCdr27718

Symptom:

The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.

Conditions:

When an UNI/NNI interface is configured on the Line card.

Workaround:

If the problem persists for sometime, bring the interface administratively down and then administratively UP.

CSCdr28033

Symptoms:

When performing dnpnport on a certain ports with SPVC connections which has stats enabled, some dal/stats error are observed on the UNI AXSM side.

Conditions:

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

E_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are some SPVCs with stats enabled between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through

two trunks.

(5) Perform dnpnports on a certain ports. Some error message are being displayed on the AXSM console.

Workaround:

None.

CSCdr28767

Symptom:

The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.

Conditions:

When an UNI/NNI interface is configured on the Line card.

Workaround:

If the problem persists for sometime, bring the interface administratively down and then administratively UP

CSCdr29013

Symptom:

Much lower via node reroute rate when attempting to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value.

Condition:

When massive SPVCs are being rerouted because of resetting some nodes in the network or when trying to setup SVC connections at a very high call rate.

Workaround:

Try not to exceed call setup rate of 100calls/sec for SVCs or SPVC reroute at this stage.

Additional Information:

Root cause of the problem has already been identified; with the fix, call setup acceptance rate is going to be stabilized around the nodal setup msg congestion threshold, not going to drop dramatically when call attempting rate goes higher.

CSCdr32624

Symptoms:

Any operation involved in file creation or file opening on the Active controller card will start failing continuously.

Conditions:

The repeated upload of configuration results in file descriptor leaking.

Workaround:

You must reset the Active controller card.

CSCdr34225

Symptom:

Cell drops are noticed on OC3 with default line rate.

Conditions:

The line rate specified for OC3 is 353208 cells/sec. But, in fact it is 353207.55 cells/sec. So cell drops are noticed if traffic is pumped in at 353208 cells/sec.

Workaround:

Use following rates(cells/sec)as max line rate for: Max rate for OC3: 353207 Max rate for OC12: TBD Max rate for T3 and E3: TBD Max rate for oc48:

CSCdr34707

Symptom:

Calls will not go through.

Condition:

The address PTSE is present in the database but the address is not present in the network reachable address table.

WorkAround:

None.

CSCdr34851

Symptom:

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.

Conditions:

Two conditions seen in our lab that caused this problem: - clock configured on the line associated with the partition, delpart doesn't fail, but partition removed from the database, but PNNI doesn't get informed of partition delete - tried to add partition on a vnni port with incorrect vpi range, partition added to the database, but PNNI doesn't get informed of the partition add

Workaround:

Workaround after the conditions are seen is to do resetsys on PXM45.

CSCdr36903

Symptom:

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.

Conditions:

PXM switchover with ILMI enabled. If the ILMI protocol across the peer have not reached a steady state this problem has been noticed intermittently.

Workaround:

dnpnport and uppnport the affected port(s) after the switchover is complete.

CSCdr39329

Symptom:

Few connections will be in fail state at one end point (either master end or slave end)

Conditions:

This happens when a large number of connections are established and then some line cards are reset.

Workaround:

None

Additional Information:

If the problem persists, attempt reroute for the failed connections from CLI

CSCdr39684

Symptom:

Cannot display link selection configured on PNNI port.

Conditions:

ILMI (auto-config) is enabled on the port.

Workaround:

disable ILMI (auto-config) on PNNI port.

CSCdr39892

Symptom:

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.

Conditions:

This problem may occur if the axsm card experiences multiple (more than 32) switch plane errors. Switch plane errors such as lost of sync, code violation, crc error, disparity error. Since switch plane error may occur during pxm45 switch cc's, this problem may also occur during pxm45 switch cc's.

Workaround:

Reset the axsm card that is not passing traffic.

CSCdr40167

Symptom:

User see sometimes SPVC fail to route spvc connection on AXSM card resets

Condition:

Repeated AXSM card resets on the POPEYE2 node OR repeated BXM card resets on BPX node

Workaround:

none

CSCdr40333

Symptom:

User did not have the granularity to find out why the clock when bad.

Condition:

A clock can go bad due to excessive jitter, high frequency, etc.

Workaround:

User would have to go to the clock source and verify functionality with the source equipment to find out the reason.

CSCdr40484

Symptom:

User did not have the granularity to find out why the clock when bad.

Condition:

A clock can go bad due to excessive jitter, high frequency, etc.

Workaround:

User would have to go to the clock source and verify functionality with the source equipment to find out the reason.

CSCdr40821

Symptom:

Some SPVC conns are in AIS-FAIL in standby

Conditions:

a. resedcd (PXM or BXM) b. dnpnport/uppnport (PNNI trunk) c. rebooting via nodes

Workaround:

switchcc the PXM.

CSCdr41012

Symptom:

Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections.

Conditions:

When large number of connections are to be resynced after a line card recovery, the control connections (signalling and routing) fails to be reinserted.

Workaround:

None.

CSCdr41170

Symptom:

After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM.

Conditions:

Existing connections have used up all bandwidth corresponding to ADM framing mode (104268 cps).

Workaround:

When T3 framing mode is changed, check if the new line type cell rate is less than the SG rate sum of existing SG belonging to the line. If so, reject the command.

CSCdr41708

Symptom:

After the switchover, the new active Pxm still shows that the above inserted backcard is still missing. This will eventually cause an extra switchover when a healthier standby Pxm is ready.

Conditions:

If inserting a backcard into the standby Pxm's slot resulted in making the standby Pxm the healthier card, the standby Pxm will be made that active Pxm.

Workaround:

If backcards on both Pxms are missing/bad, always replace/insert the backcard on the active Pxm first. This will not trigger the above switchover and bug.

CSCdr42075

Symptom:

port(s) in "vc failure"

Conditions:

Have svc calls, with active and standby pxm. Pull the active

pxm and reset card, causing switchover.

Workaround:

None.

CSCdr43945

Symptom:

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.

Conditions:

Add a connection and pump non-user-data cells e.g OAM/RM cells using a tester or CPE.

Workaround:

For policing compliance test use User data cells only.

CSCdr44255

Symptom:

Svc call on uni port getting released.

Conditions:

Make a svc call on uni(3.0/3.1) port using a tester. Pullout and put back the cable between the node and tester within 10sec(T309).

Workaround:

This problem occurs alternately. There is no work around yet.

CSCdr44537

Symptom:

The connection does not pass the data traffic.

Condition:

The UBR SPVC provisioned with PCR=0 and resync happened.

Workaround:

Do not provision pcr=0. Reactivate the connection using dncon/upcon command.

CSCdr44566

Symptom:

Dax connections are in FAIL state

Condition:

Did a resetsys on the PXM

Workaround:

Check the endpoint interface, do a dnpnport and uppnport on those interfaces, the connection should be in ok state

CSCdr44741

Symptom:

An unsupported card will stay in the Boot state, and the standby Pxm will stay in the Init state.

Condition:

Insert an unsupported card or a card with an invalid novram id into the node, then insert or reset the standby pxm card.

Workaround:

Remove the unsupported card from the card, or program the correct Novram Id onto that card.

CSCdr45063

Symptom:

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.

Conditions:

Assuming a hierarchical PNNI network originally works fine with an address A that associated with a node N at the lowest level, and A is seen as advertised across the peer group boundary just fine. Reboot the node N and A may be missing across the peer group boundary, when the identifier of the address PTSE for A differs from the one before the reboot.

Workaround:

The root of the problem has been found and a fix has been put in and verified as a correct resolution.

In this fix, the PTSE ID is now stored in the local reachable address Trie of a LGN, along with the node index of the node at the child peer group. As such, the identification of a given entry in the local reachable address Trie includes both the node index of the node and the PTSE ID at the child peer group. Note this handling is the same as already existed for network reachable address Trie.

CSCdr45896

Symptom:

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

Conditions:

1. 2 Node PNNI network 2. 2 AXSM trunks on 2 different cards 3. De-Route connections from one trunk to another trunk in another card

Workaround:

Don't de-route/re-route conns between trunks across trunks on different cards. Use multiple trunks if needed on the same card.

CSCdr45962

Symptom:

Some SPVC conns are in AIS-FAIL in active PXM after switchover

Conditions:

After multiple switchover of PXM

Workaround:

issue following command on shellconn of newly active PXM.

For example,

pxm1> conProEnableConnTrap conProEnableConnTrap 

CSCdr46262

Symptom:

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.

Condition:

1000s of non routed master / slave SPVCs are configured on a port which is operationally down. & switchover occurs.

Workaround:

Manual Switchover: Do not try switchover

Automatic Switchover: None

CSCdr46770

Symptom:

The clock is marked as unclockable.

Condition:

Once a clock source is locked, after a period of 12 hours, the clock goes into unlockable state.

Workaround:

Configure the clock source again, in order to trigger the software back to using the clock source.

CSCdr46945

Symptom:

The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link.

Conditions:

The PNNI main task loops infinitively in the function pnni_delete_db_ptse() when the PTSE deleted is a horizontal link.

Workarounds:

None

CSCdr47590

Symptom:

After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before.

Condition:

When we have failure on AXSM or some port which has many thousands SPVC.

WorkAround:

None

CSCdr47916

Symptom:

Connection may not be routed on best path.

Conditions:

Routing table (SPT) may not contain best route with certain network topologies.

Workaround:

Use default AW on all pnni links, or disable routing table.

CSCdr47931

Symptom:

System allows calls to use VPI/VCI below the provisioned minimum value.

Condition:

n/a

Workaround:

Always set the minSvccVpi and minSvccVci to 0.

CSCdr48075

Symptom:

CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB.

Conditions:

The robust Trap Manager Mechanism support from an MGX8850 is not properly working. An additional internal data structure is being prepended to the SNMP Trap PDU.

Workaround:

There is no known workaround.

CSCdr49287

Symptom:

Connection resync will be stuck in one place and so connections will be mismatched between controller and slave

Condition:

All the slaves are inactive and few of them becomes active and resync starts and before it completes another resync starts.

Workaround:

None

CSCdr49592

Symptom:

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.

Condition: No default is provided for mbs/cdvt in SCT tables.

Workaround:

If one wants the mbs/cdvt values programmed in hardware to be consistent with the values shown by "dspcon", workaround is to include defaults for mbs and cdvt in the SCT tables. Note that these defaults override those provided by cnfmbsdft/cnfcdvtdft.

CSCdr50477

Symptom:

The addcontroller command fails.

Condition:

The addcontroller command fails if the slot number being entered is not a logical slot number (e.g. logical slot number = primary slot number).

Workaround:

Supply the command with the logical/primary slot number. Run dspcds to see primary slot number.

CSCdr50497

Symptom:

dspsct command does not display proper information.

Conditions:

dspsct to display content of an SCT file in PXM Disk.

Workaround:

If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.

CSCdr51668

Symptoms:

1.switch gives status.14.0000000000000 as the response to

getnext request on netprefix

2.get negative number in ILMI PDUs from HP test

Conditions:

When running HP 3.0/3.1 ILMI Conformance Test Suite

Workaround:

1. no workaround for symptom 1

2. need to get HP patch for ILMI Conformance Test Suite to encode ILMI PDUs correctly

CSCdr52913

Symptom:

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.

Condition:

Unknown

Workaround:

None

CSCdr53438

Symptom:

cnfchan on slave dax con for cc enable, pnni controller doesn't send vsi msg to SM

Condition:

cnfchan on slave dax con doesn't take effect.

Workaround:

None

CSCdr53470

Symptoms:

SPVCs will fail to route.

Conditions:

Under rare conditions, when uni card fails during the same time as nni card reset and SPVC reroutes will cause this problem to happen.

Workaround:

None

CSCdr54146

Symptoms:

Calls will not get routed through the nodes in the network.

Conditions:

Under rare conditions when neighbor loses or drops PNNI routing messages the neighbor will remain in Exchanging state.

Workaround:

A dnpnport and uppnport will bring the link up and the neighbor state will move to Full state if there are no loss of PNNI routing messages.

CSCdr54798

Symptom:

When 2 mandatory events were sent to the children at the same time, the RAT only kept the last one.

Conditions:

Children of the rat got 2 new events that are the same.

Since they used the RAT structure to retrieve the message

Workaround:

There are no known workarounds for this problem.

CSCdr55821

Symptoms:

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

Conditions:

When the connect message has end-to-end transit delay IE present

with either PNNI Acceptable Fwd CTDI or PNNI Cumulative Fwd CTDI.

Workaround:

Avoid end-to-end transit delay IE with those parameters

(PNNI Acceptable Fwd CTDI or PNNI Cumulative Fwd CTDI), in the setup message.

CSCdr55832

Symptoms:

See the following misleading messages: "+bad length+" and

"Send Status Enquiry"

Conditions:

When turn signaling packet debug on and received signaling

STATUS message or release messages with more than cause IE.

This is only a display error. There are no serious consequences.

Workaround:

None

CSCdr55928

Symptom:

AXSM STM1 card will not handle over 32K connections.

Condition: Only occurs with over 32K connections.

Workaround:

None

CSCdr56173

Symptom:

SPVP connection(s) are not allowed.

Condition:

Try to add SPVC with vci=0 gets rejected with the error message

"Specified vpi/vci not available".

Workaround:

None

CSCdr56897

Symptoms:

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.

Conditions:

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

_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 50K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.

(5) Reset the UNI AXSM on NODE_EP2.

(6) After the UNI AXSM comes up, the tVsiSlave task CPU utilization may go above 90% for a few seconds.

Workaround:

(1) None.

CSCdr57071

Symptom:

Bad IPC messages detected caused by unreported SAR CRC errors.

Unexplained behavior or errors in the shelf.

Condition:

It is not clear that this error has ever happened, however hardware problems on the internal cell bus could cause this symptom.

Workaround:

None.

CSCdr57276

Symptoms:

SHM FAILURE ALERT message is displayed on the console

Condition:

If the PXM45 front card is replaced, user gets into this situation.

Additional information:

Show customer a copy of this message.

***************** SHM FAILURE ALERT *************************** * The PXM card has failed its PXM nativity check. The * PXM nativity check determines if the backplane serial * number recorded in the front card's BRAM or the * hard disk matches the local backplane serial number. * Please see MGX 8850 documentation for more information.

CSCdr58626

Symptom:

See a continuous Trap messages indicating IPC memory leaks.

Condition:

This doesn't happen always. sometimes when switch over happens we may see Vsi Error messages printed over the CLI.

workaround:

None

CSCdr59353

Symptom:

The dspclksrc command shows inaccurate clock information

Condition:

Unknown

Workaround:

None.

CSCdr59423

Symptom:

Switchcc results in clk switch to priority 0 msg.

Condition:

The priority 0 msg occurs when no clock sources are configured. This message does not effect the functionality of the node or the clock source on the node.

Workaround:

None.

CSCdr59709

Symptom:

No event logs when there is a PXM switchover.

Condition:

The problem occurs with PXM switchovers.

Workaround:

None

CSCdr60068

Symptom:

If a resetsys or a switchcc is preformed on the PXM, a

core dump would be preformed during the boot of the formerly active PXM card. When the core dump logs are observe the reason would be a device driver error.

Condition:

This would be seen if the core dump feature is turned on, and a resetsys or a switchcc is preformed.

Workaround:

A workaround would be to turn off the core dump for

the device errors. This is accomplished by using the core mask command:

At the cli enter: core mask

Take the current core mask at set the bit 0x20000 to zero.

For example if: The Current Core mask is 0x262ee

At the cli enter: core mask 0x062ee

CSCdr62126

Symptom:

clralmcnt doesn't clear LOS/LOF alarm counters.

Conditions:

When the link is broken, the red alarms like LOS and LOF is raised. dspalmcnt command shows all the alarms. clralmcnt command is used to restart the alarm counters. bug was LOF/LOS counters were not reset when clralmcnt command was issued. LOF/LOS counters were in fact showing only the history of line from the point axsm was booted and came up active.

workaround:

Reset the axsm. By resetting/rebooting the axsm, the LOF/LOS counters are reset.

CSCdr63104

Symptom:

dspcdstatus shows "No Alarms" for PXM45/any inapplicable slots. When slot number is not specified, it defaults to PXM slot.

Condition:

When the CLI dspcdstatus is executed without slot number being specified or when PXM45 slot is specified the above problem occurs.

Workaround:

None

CSCdr64230

Symptoms:

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

Conditions:

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

(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.

(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.

(4) There are 50K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. SPVCs are DAX (EP1_UNI_PORTS) & Routed. The Routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other turnk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.

(5) Reset uni-AXSM card (NODE_EP1: EP1_UNI_PORTs) followed by DAX con parameter change (via [cnfcon]).

Workaround:

None

CSCdr64564

Symptom:

When the optional parameter, shelf #, was provided in the CLI commands, the commands fail.

Conditions:

The valid value for shelf #, i.e. 0, was not being accepted.

WorkAround:

Shelf # is optional. Commands will go through if it is not entered.

CSCdr65883

Symptoms:

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.

Condition: Powering up a node. This is very rare.

Workaround:

None.

CSCdr66184

Symptoms:

DAX Conns are not in AIS when connection is down

Conditions:

When dncon command is executed.

Workaround:

None

CSCdr66781

Symptom:

dspcdalms shows alarms whereas dspcdstatus does not.

Condition:

When AXSM has lines/connections/feeders in the alarm state, dspcdalms shows the alarms whereas dspcdstatus does not.

Workaround:

None

CSCdr66802

Symptom:

switchcc generates a syntax error message inappropriately

Condition:

Executing the switchcc command

Workaround

None

CSCdr67264

Symptom:

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.

Condition:

Trap sent when all connection alarms clear on a given endpoint.

Workaround:

None.

CSCdr71350

Symptoms:

CLI dsppnni-path displays node name incorrectly

Conditions:

Only occurs when a long node name is used in source node.

Workaround:

None

CSCdr72570

Symptoms:

Some connections exhibit unexpected behavior such as "cannot resolve passthru".

Conditions:

Connections have been added to partition. VPI range of partition is changed so that the new VPI range is smaller than the old one.

Workaround:

Disallow modifications of VPI and VCI range when there are already connections in the partition. In the future when dynamic partitioning is implemented, modifying VPI/VCI should be allowed as long as such modification does not conflict with existing configurations.

CSCdr72621

Symptoms:

Some connections exhibit unexpected behavior (see related bug CSCdr72621) such as "ERR: Could not resolve passthro id" when "dspcon" is executed on some connections.

Conditions under which problem occurs: Connections have been added to partition. VPI range of partition is changed so that the new VPI range is smaller than the old one.

Workaround:

Disallow modifications of VPI and VCI range when there are already connections in the partition. In the future when dynamic partitioning is implemented, modifying VPI/VCI should be allowed as long as such modification does not conflict with existing configurations.

CSCdr73169

Symptom:

SNMP MIB Walk or Sending Traps results in failure(Event Log contains this information)

Condition:

Master Agent allocates memory every time A Subagent Registers its MIBs with it. If AXSM cards are reset without PXM being reset, then we will see memory allocation failure messages for SNMP MIB Walk and while sending traps.

Workaround:

None

CSCdr73423

Symptom:

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.

Condition:

This is command default case when no value is entered.

Workaround:

Always enter a password.

CSCdr75227

Symptom:

dsplns will show "other" for Medium LineType instead of "ShortSMF" etc.

Condition:

This bug will occur if the following backcard types for Sonet are used:

AXSM_BC_1_OC48_IR_B_NVID

AXSM_BC_1_OC48_SR_NVID

AXSM_BC_1_OC48_SR_B_NVID

AXSM_BC_2_OC12_IR_B_NVID

AXSM_BC_1_OC12_IR_C_NVID

AXSM_BC_8_OC3_IR_B_NVID

AXSM_BC_4_OC3_IR_NVID

AXSM_BC_4_OC3_IR_C_NVID

AXSM_BC_1_OC48_LR_B_NVID

AXSM_BC_1_OC48_XLR_NVID

AXSM_BC_2_OC12_LR_B_NVID

AXSM_BC_1_OC12_LR_C_NVID

AXSM_BC_8_OC3_LR_B_NVID

AXSM_BC_4_OC3_LR_NVID

AXSM_BC_4_OC3_LR_C_NVID

AXSM_BC_4_OC3_MMF_C_NVID

AXSM_BC_8_OC3_MMF_B_NVID

Workaround:

None

CSCdr76402

Symptoms:

Board (e.g. PXM-45) fails to boot and issues a NOVRAM checksum error.

Condition:

System boot code attempts to detect the type of NOVRAM installed.

Workaround:

None

CSCdr78869

Symptom:

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

Condition:

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

Workaround:

None

CSCdr80772

Symptom:

Log does not report successful switching of clock source.

Condition:

Unknown

Workaround:

None

CSCdr81154

Symptom:

dsppnport does not show active connections after dnpnport on a UNI port.

Conditions:

Issuing the dnpnport command on a UNI port. dsppnport <port_no> shows the number of connections on the port as zero.

WorkAround:

None

CSCdr83752

Symptoms:

? is taken as the node name and modified the node name to?

Conditions:

User enters the command cnfname with parameter as? to get help on this command

Workaround:

Change the node name back to the previous node name using cnfname command.


Additional Deliverables

SNMP MIB

The MIB release for this 2.0.11 is mibs2011.

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


Note If you purchased your product from a reseller, you can access Cisco Connection On-line (CCO) as a guest. CCO is Cisco Systems' primary, real-time support channel. Your reseller offers programs that include direct access to CCO's services.


For service and support for a product purchased directly from Cisco, use CCO.

Cisco Connection On-line

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

WWW:  http://www.cisco.com

WWW:  http://www-europe.cisco.com

WWW:  http://www-china.cisco.com

Telnet:  cco.cisco.com

Modem:  From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.


Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.



[an error occurred while processing this directive]