Guest

Cisco MGX 8800 Series Switches

2.0.10 Release Notes for MGX 8850 Software

 Feedback

Table Of Contents

2.0.10 Version Software Release Notes
Cisco WAN MGX 8850 Software

About These Release Notes

About the 2.0.10 Release

Phased Release Strategy:

Software Release 2.0.10 and related hardware:

AXSM Cards

PXM 45 Cards

PNNI

Special Installation/Upgrade Requirements

General

Upgrade Procedure

Loading the runtime images from 2.0.02 to 2.0.10

Features Not Supported

Committed (but not delivered in this release)

Obsoleted:

Notes & Cautions

Limitations

Recommendations:

AXSM/Redundancy/Multi Fault Scenarios:

APS:

Compatibility Notes

Compatibility Matrix

Release 2.0.10 System Content

Switch Software and Boot Codes

Hardware Products

Known Anomalies

Problems Fixed in Release 2.0.10

Known Anomalies from Previous Releases

Problems Fixed in Release 2.0.02

Additional Deliverables

SNMP MIB

Appendices

Obtaining Service and Support

Cisco Connection On-line


2.0.10 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.10 Release

Phased Release Strategy:

This is a third 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.10 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 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

General

Upgrade Procedure

The new SCT files are being released with this version

Loading the runtime images from 2.0.02 to 2.0.10

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.010.000_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.10 release:

setrev <slot number> <primary version>

For example: setrev 7 2.0(10.2)

Step 8 To upgrade the AXSM boot code, issue the "burnboot" command:

For example: burnboot <axsm slot> 2.0(10)

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

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

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


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.010.000_bt.fw"

d. - enter "y" to confirm

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

-- setrev 7 2.0(10.2) 

Step 3 To upgrade the AXSM boot code, issue the "burnboot" command:

burnboot <axsm slot> 2.0(10)

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

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

setrev <axsm slot> 2.0(10.2)

Repeat this step for all AXSMs on the card.

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. 25K connections is supported in this release.

4. Graceful upgrade from previous release to 2.0.10.

Obsoleted:

none

Notes & Cautions

1. Following a resetsys with an excess of 20 NNI interfaces we have intermittently experienced NNI interfaces remaining in Attempt State. The workaround in this case would be to execute a down port followed by an up port.

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. In the MGX Rel 2.0, PNNI prevents adding dax SPVC endpoints with different parameters for forward/backward bandwidth. However, for the internode SPVCs, the addition of master/slave endpoints with different parameters for forward/backward bandwidth goes through but the connection remains failed and in mismatch state.

4. Following CLI commands were changed since publication of user documentation. Reason for the change is to make these commands consistent with other products.

Documented
Implemented
Purpose

addchan

addcon

Add SPVC endpoint

cnfchan

cnfcon

Change parameters of SPVC

delchan

delcon

Delete SPVC endpoint

dspchans

dspcons

Display all SPVCs in the node

dspchan

dspcon

Display a specific SPVC


Further, "addslave" and "addmaster" are obsolete.

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

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

7. Non user data cells are not policed.

8. It is possible to add ports at cell rate fractionally higher than maximum line rate. This may cause cell drop.

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

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

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

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. The user is unable to generate SCT files in this release. The user will have this capability in a future release.

3. For an asymmetric connection where the ingress bandwidth is not the same as egress bandwidth, the AXSM allows the connections to be added, however, the bandwidth calculation is incorrect. The computation of the egress and ingress will be based on the egress bandwidth.

4. For the MGX-PXM 1 feeder (Release 1.1.30) to MGX-PXM45 routing node (Release 2.0.10), currently the only narrowband modules supported are the FRSM, and AUSM, other narrowband cards will be supported in a later release. The following features from release 1.1.30 are NOT supported in this release as a feeder to a PXM45 system running 2.0.10:

a. All service modules except the FRSM T1/E1 channelized and unchannelized, and the AUSM

b. VBRrt is not supported

c. Online diagnostics for the PXM1

d. DS3 loopback on PXM1-T3

e. CoS mapping on FRSM

These features, and the other service modules are planned to be added in a future release.

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

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

7. If port(s) and trunk(s) are configured on same AXSM card and port level failure occurs, it will cause SPVC deroutes.

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

9. OC48 BC intermittently fails to detect the optical input after power recycle. If this happens, the back Card should be reseated.

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

11. On power cycle of the node, the OC48 line may not come out of LOS/LOF condition. One may have to physically disconnect and reconnect the cable to get this going. This is a hardware bug and is currently being worked with the vendor.

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

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

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.10 (number 2 and 3) for the Control VC feature.

AXSM/Redundancy/Multi Fault Scenarios:

AXSM Redundancy and Multi Fault scenarios have been tested with traffic on up to 25,000 connections. Problems have been encountered with the Multi Fault scenarios. Please see the Known Anomalies section for more details.

APS:

The following anomalies have been seen:

a. On switchredcd, APS may declare a signal fail incorrectly on protection line. This leads to a locked state which may not clear even when the new standby card comes up. A forced switch would be required to clear the condition. However, this situation does not affect the traffic but only causes APS protocol anomaly.

b. Detecting Channel Mismatch from a Protection Line selected state in bidirectional mode, causes only the side that detects the mismatch to reach selector released state without causing a switch on the remote end. This condition can potentially hit traffic in 1:1 mode.

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.010.000_bt.fw

2.0.10

pxm45_002.000.010.002_mgx.fw

2.0.10.2

2.0.10.2

AXSM-1-2488

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.010.002.fw

2.0.10.2

2.0.10.2

AXSM-16-155

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.010.002.fw

2.0.10.2

2.0.10.2

AXSM-4-622

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.010.002.fw

2.0.10.2

2.0.10.2

AXSM-16-T3/E3

axsm_002.000.010.000_bt.fw

2.0.10

axsm_002.000.010.002.fw

2.0.10.2

2.0.10.2


MGX 2.0.10 interoperates with CWM 10.3.

MGX 2.0.10 operates with MGX 1.1.30 as a feeder.

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

Release 2.0.10 System Content

Switch Software and Boot Codes

The following four images are applicable to the 2.0.10 release:

Boot Images

axsm_002.000.010.000_bt.fw

pxm45_002.000.010.000_bt.fw

Runtime Images

axsm_002.000.010.002.fw

pxm45_002.000.010.002_mgx.fw

Hardware Products

Support hardware for Release 2.0.10:

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


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 loss service. It may occasionally 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 reset the backcard too often. If the front card gets stuck during the power-on, try to reset the front and back card to bring the system.

Problem Occurrence:

Intermittent or occurs once.

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.

CSCds20318

Symptoms:

An AXSM is with a log event indicating FAT_CD_DEAD. This event indicates that the card is not responding to poll messages from the active PXM and is now declared dead and thus is reset to revive the card. If this problem occurs 3 times in a hour, the card will be moved to the failed state with the failed reason to equaled to MAX NUMBER OF RESET reached.

Conditions:

A node operating in steady state.

Workaround:

Reset the failed card.

Problem Occurrence:

Intermittent or occurs once.

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.

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

CSCds22824

Conditions:

If an AXSM card gets reset during the FW download.

Symptoms:

The AXSM card fails to download FW image the next time and dspcd shows "Failed" Reason: SHM_CDF_SW_DNLD_FAILED"

Workaround:

None

Problem Occurrence:

Intermittent or occurs once.

CSCds22946

Symptom:

Some connections are not being routed

Condition:

Master node: swichover the AXSM redundancy on AXSM UNI, switchcc (PXM),

switchover the AXSM redundancy on AXSM NNI Via node: switchover the AXSM NNI ingress side, switchcc (PXM), and switchover AXSM NNI on egress side Do this continuously overnight. Then via node is congested

Work Around:

Reset the via node

Problem Occurrence:

Intermittent or occurs once.

CSCds23866

Symptoms:

An axsm can get reset intermittently to due to timeout condition.

Conditions:

Under Which the Problem Occurs: Perform a PXM switchover.

Workaround:

Avoid doing a PXM switchover when the AXSMs are busy with connection changes (e.g. connection setup/tear down.)

Problem Occurrence:

Intermittent or occurs once.

CSCds24168

Symptoms:

This bug reports that the card slot is shown as Empty when it is in fact inserted.

Conditions:

Run the dspcds command.

Workaround:

This may be just a display problem. Resetting the card may correct the problem.

Problem Occurrence:

Intermittent or occurs once.

CSCds24320

Symptom:

All PNNI links for virtual trunks goes down. No calls routed

Condition:

Have many virtual trunks. Typically around 60 vts and then do switchcc on PXM. This is also very rare problem. In fact this is the only occurrence of problem.

Workaround:

None

Problem Occurrence:

Intermittent or occurs once.

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.

S2 BUGS

 

CSCdr20887

Symptom:

After the trunk card comes back from reset, vsierr 0x5017 messages and [egress ConnID add failure] messages are observed.

Condition:

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

(2) A 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 one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other trunk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.

(5) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA.

(6) Reset this trunk card (hosting TRK_A & TRK_B) while in [down in progress] state.

Workaround:

One of the following:

(1) Do not reset trunk card while rerouting takes place.

(2) If the failure has already occurred, rectify this problem by doing [resetsys] on every PXM45 in the network.

Problem Occurrence:

Intermittent or occurs once.

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

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.

CSCdr93447

Symptom:

PNNI links go up and down.

Conditions:

QE1210 chip which handles SAR traffic on PXM goes into an unrecoverable bad state where it arbitrarily discards cells on the control channels. This translates into invalid CRC and invalid Length errors on the AAL5 frames which belong to PNNI / SSCOP. This condition is very rare, happens due to simultaneous multiple faults in the network having high number of connections. Massive flood of reroutes / status requests on the PNNI links cause this condition.

Workaround:

Reset the PXM card having this problem.

Problem Occurrence:

Intermittent or occurs once.

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.

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

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.

Problem Occurrence:

Intermittent or occurs once.

CSCds13760

Symptom:

Unplugging and plugging the standby PXM card can cause the card to reset continuously

Conditions:

Remove the standby PXM card and plug it in where it might not be seated correctly.

Workaround:

Remove the standby card and plug it in carefully making sure it is plugged and seated correctly and secured

Problem Occurrence:

Intermittent or occurs once.

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

CSCds14824

Symptom:

Incorrect local or remote NSAP address for one or more SPVCs leading to routing failure for such SPVCs.

Conditions:

Has been observed once after a non-graceful upgrade. There are no related specific conditions.

Workaround:

Delete and Add affected SPVC endpoint.

Problem Occurrence:

Intermittent or occurs once.

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.

CSCds15089

Symptom:

dsppnports on pxm shows the port down but axsm shows the port as up (operationally and administratively).

Condition:

Pull out a cable in a pnni-link between two nodes.

Workaround:

None

Problem Occurrence:

Intermittent or occurs once.

CSCds15159

Symptom:

Crossbar errors and alarm are observed using CLI commands dspxbarerrcnt and dspswalm

Condition:

When PXM-HD backcard was removed from standby PXM45. The standby card will be reset. The errors appears transient during PXM45 reset.

Workaround:

None

CSCds16742

Symptoms:

AXSM card may bet reset or moved to the failed state.

Conditions:

Any activity that triggers a PXM switchover.

Workaround:

If the AXSM is in the failed state, reset the axsm card again to bring it back.

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.

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.

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

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

CSCds18690

Symptoms:

PNNI links for virtual trunks are not up and so calls do not route over those virtual links

Condition:

When we reset AXSMs or do resetsys and after that resync takes place between VSIM and VSIS. Now sometimes control vc commits by resync module are rejected by slave and if it happens then resync informs VCM and vcm deletes control vc and tries to establish again but at that time PNNI is already bound to LCN and so proxy slave rejects this request and so nowonwards pnnilink will not come up. This is very rare. Very hard to reproduce.

WorkAround:

None

Problem Occurrence:

Intermittent or occurs once.

CSCds19282

Symptoms:

Intermittently, some PXMs will fail to boot up.

Conditions:

Perform a resetys multiple times in a row.

Workaround:

Try to bring up the node using only 1 PXM, if that PXM fail to come up.

Problem Occurrence:

Intermittent or occurs once.

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

CSCds20227

Symptoms:

One end of SPVC connections go into E-AISRdi alarm even though the other end does not have any line failure.

Condition:

Under rare circumstances (which is still under investigation), clearing of line alarm condition does not cause clearing of ATM layer AIS in the ingress direction. The exact sequence of events which cause this condition is presently unknown. When this happens the QE48 generates F5/F4 AIS in the ingress direction on all conns. on the affected port. This causes the far end of the connection to enter into alarm.

Workaround:

Induce a line fault on the far end and restore the line to normalcy. This could be done by simply plugging out the cable and putting it back. This would clear all connection alarms in the local end.

Problem Occurrence:

Intermittent or occurs once.

CSCds20287

Symptom:

Unable to CC to axsm possibly after a switchred.

Conditions:

This is an axsm OC48 with APS.

Workaround:

None

Problem Occurrence:

Intermittent or occurs once.

CSCds20318

Symptoms:

An AXSM is with a log event indicating FAT_CD_DEAD. This event indicates that the card is not responding to poll messages from the active PXM and is now declared dead and thus is reset to revive the card. If this problem occurs 3 times in a hour, the card will be moved to the failed state with the failed reason to equaled to MAX NUMBER OF RESET reached.

Conditions:

A node operating in steady state.

Workaround:

Reset the failed card.

Problem Occurrence:

Intermittent or occurs once.

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.

CSCds21342

Symptom:

Node resets intermittently

Condition:

DC supply voltage is abnormally high and derived voltages are fluctuating.

Workaround:

Lower the DC input

Problem Occurrence:

Intermittent or occurs once.

CSCds22862

Symptom:

Was not able to CC to the axsm after a switchred sometimes.

Condition:

An axsm OC48 card with APS (automatic protection switching) following a switchred sometimes caused excessive axsm cpu usage.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

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.

CSCds22604

Symptom:

There are multiple problem,

1. Ramsync send failure

2. Connection are not in sync between active and standby card

Condition:

Trigger a AXSM card switchover and pull the new active cards back card while the switchover is going on.

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

CSCds23335

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:

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.

Problem Occurrence:

Intermittent or occurs once.

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.

CSCds23586

.Symptoms:

After the switchover is completed, try to cc to the new active card. On the new active card, the user prompt shows an incorrect state momentarily (e.g A2b.14.AXSM.i). It should have shown the prompt as A2b.14.AXSM.a

Conditions:

Perform a switchredcd on a pair of AXSM cards that have APS configured

Workaround:

None.

Problem Occurrence:

Intermittent or occurs once.

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.

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.

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.

CSCds24905

Symptom:

Connection commits get rejected for lack of LCN resource / BW resource

Condition: Bw resource get negative, because of a bug in Ingress CAC feature.LCN resource goes negative when a trunk is derouting and a switchredcd is forced on the axsm cards.

Workaround:

None

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

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.

CSCds28506

Symptom:

Active processor resets due to TLB exception in pnCcb while performing operation on a resync element.

Conditions:

There are no particular conditions which cause this to happen. This problem was seen only in one particular weeks' build/image and has not been seen in subsequent images.

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.

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

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.

CSCds35297

Symptoms:

Core files are generated with core dump reason equaled to "Device Driver Error".

Conditions:

After a PXM reset, a core file may be generated.

Workaround:

To disable core collection, use the core mask CLI command.

CSCds33133

Symptom:

AXSM card state is shown as Empty for a brief period of time ( < 1 minute)

Condition: Either after PXM45 card resets or switchover.

Workaround:

None

Additional Information

Wait for few seconds and the AXSM card would come up finally.

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

CSCds35713

Symptoms:

Add SPVC DAX connection. Put the slave end-interface in alarm state. PXM45 switchover, caused the connections to go into condition state. Connections stayed in Condition after interface recovery (from alarm).

Conditions:

Connection stays in Condition state and does not route.

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.


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.

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

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 msgs. if the attachment point change doesn't happen, then ilmiTask will be fine. The ilmiTask fails only when it tries to print an error message.

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.


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

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

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.

CSCdr93317

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

CSCdr86343

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

CSCdr89804

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


Release 2.0.01 and Release 2.0.02

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

(List the MIB change in this release compared to the last release)

Appendices

(List the sub releases for each firmware type that works with this software release following the same format of the main release.)

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.