2.0.11 Version Software Release Notes Cisco WAN MGX 8850 Software
About These Release Notes
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
About the 2.0.11 Release
Phased Release Strategy:
This is the fifth release of PXM45 and AXSM. Follow on releases are planned to add new feature contents and can be found in Marketing Road Map
Software Release 2.0.11 and related hardware:
AXSM Cards
The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. Other Cisco ATM platforms, and other ATM manufacturers equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
•T3/E3
8 ports per back card, 2 back cards per dual height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 ports optical per back card, 2 back cards per dual height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 Ports per back card, 2 back cards per dual height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single port back card, one back card per slot
SMF Short, long and extra-long reach
ATM Layer Information
•Usage policing supported on all interfaces except OC48c/STM16
•T3 interfaces support both PLCP and direct cell mapping
•64 Logical interfaces -- ports, trunks, or virtual trunks (future)
•16 Class of Service queues for each class of service
•Supports independent queues for each ATM class of service
Network Management Features
•OAM functionality per ITU-T I.610
•Fault management - AIS/RDI at F4 and F5 flow
•User selectable continuity checking at connection endpoints
•Loopback diagnostics
•Automatic alarm generation and propagation for interface failures
The AXSM offers a complete ATM feature set and allows the MGX8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.
PXM 45 Cards
The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4 based PXM-1 design.
Reliability, Availability and Serviceability (RAS) Features
The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the RAS features are listed below:
•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.
•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow
•Hardware design to ensure that if one or both hard disk fails, the cards will still pass traffic with no interruption, although provisioning could be suspended.
•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXMs in a system. This was calculated at greater than 100,000 hours.
PNNI
The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:
•PXM-UI-S3
The PXM-UI-S3 supports the following interfaces:
•One RJ45 10Mbps 802.3 Ethernet port
•Two RJ45 RS232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:
Pin
Signal
Direction
Description
1
RTS
OUTPUT
Request to Send
2
DTR
OUTPUT
Data Terminal Ready
3
TX
OUTPUT
Transmit Data
4
SG
Signal Ground
5
SG
Signal Ground
6
RX
Input
Receive Data
7
DSR
Input
Data Set Ready
8
CTS
Input
Clear to Send
•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The following connections are supported:
–RJ48. Pin Out conforms to Accunet1.5 Specification
–Wire Wrap
–BNC
–DB15
•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.
–PXM-HD
This contains the hard disk for the processor.
PNNI
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and will scale to very large networks.
PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.
PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.
PNNI provides dynamic ATM routing with QoS support as defined by the ATM Forum. PNNI uses link-state and source state route technology, supports aggregation for private ATM addresses and links between switches, and has the ability to scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.
The functions of the PNNI routing protocol include the following:
•Hello protocol (allows adjacent switches to exchange topology information)
•PTSE (PNNI Topology State Elements) database synchronization and management
•PTSE flooding
•Address summarization and advertisement
•Link and nodal aggregation
•Pre-computation of routing tables
•Quality of Service (QoS) based routing
•Multiple Routing Metrics
•Discovery of neighbors and link status
•Synchronization of topology databases
•Load balancing on equal cost paths
•Load balancing on parallel links
•Load balancing with redundant addresses
•Alternate paths
The following PNNI features are supported in Release 2.0 of the MGX.
•UNI 3.0/3.1
•PNNI 1.0 Single Peer Group
•ILMI 4.0
•Point to point ATM SVCC and SVPC
•Support for ABR, CBR, VBR, rt-VBR, and UBR
•Alternate call routing (See separate feature description)
•On demand call routing (See separate feature description)
•Native E.164 and AESA (E.164, ICD, DCC) - formerly NSAP - address format
•Enhanced CAC with per service class policy parameter (See separate feature description)
•Per Class of service overbooking
•Congestion control (See separate feature description)
•PNNI connection and path trace
•OAM fault management
•Address Filtering (see separate feature description)
•Intelligent CAC (see separate feature description)
•Call Processor Redundancy
PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.
Special Installation/Upgrade Requirements
Upgrade Procedure
There are new SCT files that are being released with this version.
Note: When upgrading your node, upgrade in the following order
pxm45 backup boot
pxm45 runtime image
axsm runtime image
Loading the runtime images from 2.0.10 to 2.0.11
For Redundant Systems
Upgrade the standby PXM45 boot code by using the following steps:
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "sysBackupBoot" command
Step 3 - hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove()
Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "LOADREV" command to load the 2.0.11 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(11.3)
Step 8 After the standby card comes back up with the new image in the ready state, use the "RUNREV command to load the 2.0.11 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(11.3)
Step 9 After the redundant card comes up in standby ready, issue the command "COMMITREV" to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(11.3)
Step 10 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the "LOADREV, RUNREV and COMMITREV" command for each AXSM card.
For example:
loadrev <axsm slot> 2.0(11.3)
runrev <axsm slot> 2.0(11.3)
commitrev <axsm slot> 2.0(11.3)
Repeat these steps for all non-redundant AXSM cards.
Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.
loadrev <slot number> <version>
For example: loadrev <axsm slot> 2.0(11.3)
Step 13 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.
runrev <slot number> <version>
For example: runrev <axsm slot> 2.0(11.3)
Step 14 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <axsm slot> 2.0(11.3)
Repeat this step 12-14 for all redundant AXSM cards.
For non-redundant (PXM45) systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
Step 2 Use the "SETREV" command to load the 2.0.11 release:
-- setrev 7 2.0(11.3)
Step 3 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 4 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.
setrev <axsm slot> 2.0(11.3)
Repeat this step for all AXSMs on the card.
New CLI Commands
1. Two new CLI commands have been added on the AXSM card.
a. clrportcnts: There are no parameters to be entered. This command will clear the counts on all the ports.
b. clrchancnts: There are no parameters to be entered. This command will clear the counts on all the connections.
2. The CLI command "clrcnf" has been added to clear a portion of a node's configuration. The following information is retained:
a. IP Connectivity configuration for LAN and ATM
b. nodename
c. Correct primary and secondary software version for all slots
d. SNMP community string, contact and location.
e. timezone
f. GMT offset
g. date and time
3. When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name. This has been changed to reflect the command that was issued. Note, this fix will work for those CLI commands that currently call the areYouSure () function to throw the prompt "Do you want to proceed?". However those CLI commands that don't use the areYouSure () function will continue to throw their own confirmation prompt.
4. Two additional commands have been added for the AXSM card.
a. dspbecnt
b. clrbecnt
Changed CLI Commands
1. The switchcc command has been changed to reject the pxm switchover if the node is not in a stable state. The node is considered not stable if some of the cards in the node are in the process of transitioning to ready state.
2. The dsptasks command now has screen prompting to continue or exit from viewing the information.
3. Before, the card alarms and slot alarms (for the same slot that the card resides in) were being reported by different CLIs i.e., dspcdalms and dspslotalms. Now, both these CLIs have been merged to show both card and slot alarms via dspcdalms. As a result of this change, dspslotalms will no longer be available. Further,
•- dspcdalm <slot> provides alarm type-level information for the slot specified
•- dspndalms contains both slot and card alarms under alarm type "Card Alarms"
–For Example:
Unknown.7.PXM.a > dspcdalms
Card Alarm Summary:
Slot Critical Major Minor
---- -------- ------- -------
1 0 0 1
2 0 0 0
3 0 0 0
4 0 0 0
5 0 0 0
6 0 0 0
7 3 4 5
8 0 2 0
9 0 0 0
10 0 0 0
11 0 0 0
12 0 0 0
13 0 0 0
14 0 0 0
Use dspcdalms <slot> to see more detail.
Unknown.7.PXM.a > dspcdalm 7
Card Alarm Summary
Alarm Type Critical Major Minor
---------- -------- ------- -------
Hardware Alarm 0 0 0
Card State Alarm 0 0 0
Disk Alarm 3 4 5
Line Alarm 0 0 0
Port Alarm 0 0 0
Feeder Alarm 0 0 0
Channel Alarm 0 0 0
Unknown.7.PXM.a > dspndalms
Node Alarm Summary
Alarm Type Critical Major Minor
---------- -------- ------- -------
Clock Alarms 0 0 0
Switching Alarms 4 5 6
Environment Alarms 3 4 5
Card Alarms 3 6 6
Features Not Supported
Committed (but not delivered in this release)
1. AXSM cards with STM1 electrical interface.
2. Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).
3. Connection density: 50K connection per node. 40K connections is supported in this release.
Obsoleted:
none
Notes & Cautions
1. Note upgrading from the 2.0.02 release to 2.0.11 is non-graceful. Upgrading from 2.0.10 to 2.0.11 is graceful.
2. PNNI default min VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (e.g. MPLS and NCDP). For users who would like to add MPLS controller in release 2.1, it is highly recommend to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be established automatically on 0/32.
3. By default, 900 cps and 543 cps will be reserved for SSCOP and PNNI Signalling VC respectively even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.
4. The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert!! Alert!!." In this situation follow the steps below:
a. enter "shmFailDisplay." Display table will show that BRAM is not native.
b. enter "shmFailRecoveryHelp". This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is "shmRecoverIgRblDisk".
c. enter "shmRecoverIgRbldDisk".
5. Do not execute the "delcontroller" CLI when connections/ports still exists. The impact of executing delcontroller with connections is that the connections can not be recovered until the controller is readded via addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in provisioning state). There is now a warning to the user of the impact of the command when there are existing connections/ports.
6. Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.
7. Analysis of the code has identified a situation which has a low probability of occurring and in fast has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, thus minimal bandwidth is available for new SPVC connections, there is a condition which can be encountered where, the initial software check believes there is sufficient bandwidth for the new SPVC connection; however, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.
8. To replace one type of AXSM front card with other type, it is required to delete all connections, partitions, ports and down lines. In case of AXSM card failure, same type of AXSM card must be installed in that slot.
9. If a user has upgraded already to 2.0.11 and then decides to fall back to 2.0.10 he/she should run the following command on the active PXM after falling back to 2.0.10 - gShmRebuildFlagSet(2).
Limitations
1. If the destination address is reachable for both a IISp and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Since IISP does not support ABR connections, the connection setup will fail.
2. SCT can be changed with connections present in this release. However, if service affecting the connections will be rerouted.
3. Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.
4. When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX-8850 PXM45 as lnPci address.
5. For users who would like to add MPLS controller in release 2.1, it is highly recommended to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be automatically established on 0/32.
6. For users who would like to add MPLS partition on a port where other partitions has already been added and have set the min-vci value to be 32, then the users has two options:
a. After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.
b. Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.
7. If 50 users (the maximum is 50) is added and the pxm card is reset, the card does not come back up.
8. Changing or reseating the backcard several times on the AXSM may sometimes cause the front card to reset and cause loss of service. The PhyTask also gets suspended. To avoid this problem, try not to reseat the backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
Recommendations:
•It is recommended to apply the default values for PCR, SCR, etc. to the Control VC. If the values are decreased to a low value, there is a chance that the Control VC (SSCOP or PNNI) will not come up. Note, you must use the SCT files released with 2.0.11 (number 2 and 3) for the Control VC feature.
Compatibility Notes
Compatibility Matrix
Board Pair
Latest Boot Code Version
Minimum
Boot Code
Version
Firmware
Latest
Firmware
Version
Minimum
Firmware
Version
PXM45
pxm45_002.000.011.001_bt.fw
2.0.11.1
pxm45_002.000.011.003_mgx.fw
2.0.11.3
2.0.11.3
AXSM-1-2488
axsm_002.000.0010.000_bt.fw
2.0.10
axsm_002.000.011.003.fw
2.0.11.3
2.0.11.3
AXSM-16-155
axsm_002.000.010.000_bt.fw
2.0.10
axsm_002.000.011.003.fw
2.0.11.3
2.0.11.3
AXSM-4-622
axsm_002.000.010.000_bt.fw
2.0.10
axsm_002.000.011.003.fw
2.0.11.3
2.0.11.3
AXSM-16-T3/E3
axsm_002.000.010.000_bt.fw
2.0.10
axsm_002.000.011.003.fw
2.0.11.3
2.0.11.3
MGX 2.0.11 interoperates with CWM 10.3.
MGX 2.0.11 operates with MGX 1.1.31 as a feeder. Please see 1.1.31 release notes for bugs related to the feeder features.
MGX 2.0.11 operates with Cisco View 5.1x (package 3.3x).
Release 2.0.11 System Content
Switch Software and Boot Codes
The following four images are applicable to the 2.0.11 release:
•Boot Images
– axsm_002.000.010.000_bt.fw
–pxm45_002.000.011.001_bt.fw
Runtime Images
– axsm_002.000.011.003.fw
–pxm45_002.000.011.003_mgx.fw
Hardware Products
Support hardware for Release 2.0.11:
Model
800 Part Number
Revision
PXM45
800-06147-07
B0
PXM-UI-S3
800-05787-02
A0
PXM-HD
800-05052-03
A0
AXSM-1-2488
800-05795-05
A0
SMFSR-1-2488-FC
800-05490-05
A0
SMFXLR-1-2488-FC
800-05793-05
A0
SMFLR-1-2488-FC
800-06635-04
A0
AXSM-16-155
800-05776-06
A0
AXSM-4-622
800-05774-09
B0
AXSM-16-T3/E3
800-05778-08
A0
SMFIR-2-622
800-05383-01
A1
SMFLR-2-622
800-05385-01
A1
SMB-8-T3-BC
800-05029-02
A0
SMB-8-E3-BC
800-04093-02
A0
MMF-8-155
800-04819-01
A1
SMFIR-8-155
800-05342-01
B0
SMFLR-8-155
800-05343-01
A1
APS RDNT CON
800-05307-01
A0
Known Anomalies
The following is the list of known anomalies in this MGX 8850 software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.
Bug ID
Description
S1 Bugs
CSCdr15911
Symptom:
Changing the backcard may sometimes cause the front card to reset and cause loss of service. It may occasionally be difficult to bring up the AXSM.
Conditions:
This problem happens occasionally when someone reseats the backcard several times, the front card is reset.
It is also observed that during power on/off testing, sometime the PhyTask got suspended.
Workaround:
Try not to reseat the backcard too often. If the front card gets stuck during the power-on, try to reseat the front and back card to bring the system.
CSCds20527
Symptom:
The CWM Software(ConnProxy module) will notice timeouts while creating connections continuously.
Condition:
SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).
Workaround:
Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.
Additional Information from CWM:
If client tries to add more than 100 connections through Connection Proxy (Service Agent) Script, they will start getting Time Out's even though the time out frequency is less. Client then needs to find out from the Log file which all connections could not be added. If provisioning is a one time action, Client may bear this, but if they do provisioning very often, it will be a serious concern.
CSCds46636
Symptom:
When a large number of connections get into alarm (like AIS) there is flood of activity on the cPro task, which also happens to handle the provisioning activity. When there is a simultaneous provisioning activity going on in the card, the task stalls because of a deadlock over resources. This is a very rare occurrence, but when this happens all conn. related CLI hangs.
Solution:
The provisioning activity is separated from the alarm handling activity using two different tasks.
Workaround:
None
Frequency:
One time occurrence.
CSCds54248
Symptoms:
All the links may go to 0ne-way-inside or even in reset state. PXM may loose connectivity with SM cards.
Conditions:
Happens during high DMA traffic like having 95 interfaces on the nodes (physical + virtual) with 50K connections and switchcc happens on a via during resetsys happening on a neighboring node. Problem is observed on a via node.
Workaround:
Non.
Additional Information:
Switchcc PXM or resetsys the node.
CSCds54390
Symptoms:
Connections fails to route over OC48 trunk
Conditions:
Routing connection over OC48 trunk
Workaround:
None
Frequency:
One time occurrence.
CSCds55470
Symptom:
PXM crashes after booting. Normally it is attributed to the telnet daemon task.
Conditions:
LAN boot IP address has not been configured.
Workaround:
From console, stop PXM in image startup at the prompt: Press [Enter] to skip initialization...
Execute following commands:
bootChange (setup inet address for lan) sysCardInit (bring the reset of image up)
Once card is completely up, from cli re-execute bootChange command.
CSCds63724
Symptoms:
PNNI interface status is in "building vc" state after loading new image on AXSM.
Conditions:
After loading new image on AXSM, one of the pnni port shows status in "building vc" in dsppnports command. This problem occurs in a fully loaded node (50K connections) and 100 interfaces. The problem occurrence is also rare.
Work around:
Perform dnport and upport on that interface.
Frequency:
Intermittent
CSCds64523
Symptoms:
After adding a port and a partition on the AXSM, the pnport status shows "building vc" instead of "up".
Conditions:
(1) On AXSM, perform addport and addpart.
(2) On PXM, perform dsppnport, and the pnport status for the newly added port shows "building vc" forever because the control vc committing fails on the AXSM.
Workaround:
None.
CSCds65556
Symptoms:
The controller was out of memory and restarted.
Conditions:
Seems a rare scenario caused probably due to flaky links resulting in deroute plus reroute of 50000 spvcs.
Workaround:
None.
CSCds68209
Symptom:
Single PXM card resets itself after upgrading boot
Conditions:
After upgrading boot on non-redundant PXM.
Workaround:
none
Frequency:
One time occurrence.
S2 BUGS
CSCdr89521
Symptom:
dspcon shows routing cost = 0
Condition:
This will happen after swithcc on connections that are not rerouted
Workaround:
Do a dncon or rrtcon
CSCdr90786
Symptom:
When a Primary Clock Source is intentionally deleted with the 0delclksrc command a clock alarm is reported by the dspndalms and the dspclkalms command that states that the Primary clock source is lost.
Conditions:
This symptom will occur when a Primary clock source is intentionally deleted with the delclksrc command.
If a primary clock source is lost i.e becomes unlockable or has loss if signal; without user intervention then this alarm is reported as expected and that symptom is not an error.
Workaround:
None.
CSCds06186
Symptoms:
CC alarm is not always reported.
Conditions:
Enabling and disabling CC on a connection multiple times can cause the CC alarm not to be reported.
Workaround:
None.
CSCds17859
Symptom:
CLI can be held up for up to 10 to 15 seconds when CWM FTPs files from the node.
Conditions:
When CWM FTPs files from the node.
Workaround:
None.
CSCds20527
Symptom:
The CWM Software(ConnProxy module) will notice timeouts while creating Connections continuously.
Condition:
SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).
Workaround:
None.
Additional Information:
Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.
CSCds24362
Symptoms:
Occasionally, when downing a UNI port (dnport) on AXSM followed by upport, some VSIErr are displayed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnport on the UNI on NODE_EP1.
(4) upport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.
Workaround:
None.
CSCds31775
Symptom:
AXSM card continuously resets.
Condition:
Unknown
Workaround:
None.
Additional Information:
Reseat the front and back cards.
Frequency:
One time occurrence.
CSCds36438
Symptom:
Standby card does not come up after a restoreallcnf.
Conditions:
The database for the Standby card is corrupted.
Workaround:
Perform sysClrallcnf on the standby card.
Frequency:
One time occurrence.
CSCds46455
Symptoms:
After a PXM switchover, all AXSMs went to the failed state.
Conditions:
There is a communication failure between the new active PXM and all the AXSM cards in the node. This was seen once and could not be reproduced since.
Workaround:
If there is a standby PXM in the standby Ready state, switch to that card. Otherwise, perform a node reset using the resetsys command.
CSCds46524
Symptom:
The dsppnports show links to be down after APS switchover or after card/node boot up.
Condition:
Some application (APS suspected) generate lots of snmp traps. and this will clog all 1k IPC buffers, leading pxm and axsm comm been broken. since vsi master-slave will have Alloc fails for IPC buff.
Workaround:
Reduce the number of ports.
Frequency:
One time occurrence.
CSCds47626
Symptoms:
After running script to create 50K SPVC conns, there are some connections in FAIL state. dspcon on pxm45 show Last Fail Cause to be "no route to destination" on one end and "Cross Commit Failed" on the other end.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) Run script to create 50K connections from NODE_EP1 to NODE_EP2.
(3) Some connections might failed to route.
Workaround:
none.
CSCds52922
Symptom:
vsiErr 0xe007 is logged on the axsm console
Condition: Not clear.
Workaround:
None
Frequency:
Intermittent.
CSCds54794
Symptoms:
When APS line is added and the controller is reset, the establishment of SSCOP links is delayed.
Conditions:
When APS line is added on a port and after this if the system is reset, then SSCOP link takes a while to re-establish.
Workaround:
None.
Frequency:
Intermittent.
CSCds54946
Symptom:
VP Connections are slow to route
Condition:
There is no reroute handling of SPVCs & SPVPs. The reroute could have failed at the HALF commit if the connections was not previously deleted at the AXSM, due to last deroute failure. In this case, resources (vpi/vci) are not released. The VPI/VCI will stay in use.
WorkAround:
After sometimes, RESYNC detects the error and connection is cleaned up at the AXSM.
CSCds56802
Symptom:
On the standby some ports show the status as ilmi_query even though the ports are up on the active.
Condition:
Node has 50k SPVCs with active & standby controller and active & standby slaves. An upgrade is initiated with "loadrev" and the standby ends up with the updated image. The problem is intermittent.
WorkAround:
None.
Additional Information:
After switchover the ports will be up on the newly active and all connections will Ok.
CSCds57511
Symptoms:
Active PXM may loose communication with all other cards on the shelf. All the links may go down.
Conditions:
This could happen during high activity on the PXM QE1210 SAR, typically during resetsys of the node or resetsys of neighboring nodes.
Workaround:
Switchcc on the active PXM.
Frequency:
One time occurrence.
CSCds60742
Symptom:
Seen log entries about time of date change for standby PXM periodically.
Conditions:
Normal operation
Workaround:
None.
CSCds61188
Symptom:
After switchover from standby to active, the port rate of Resource Manager database is not the same as displayed by "dspport" or "dspports" command. This can cause Resource Manager to reject command that depends on available port bandwidth while the user think the bandwidth resource is OK from dspport.
Condition:
No noticeable condition. IPC failure has probably happened between Equipment Manager and VSI slave.
Workaround:
Use cnfport to force new min/max rate after previously standby card is active.
CSCds63497
Symptom:
TLB exception on one of the FTP tasks.
Conditions:
Noticed only once - on a heavy loaded system. On the PXM card only.
Workaround:
If redundancy is enabled, conduct a switchover.
On a standalone card, you would need to reset the system.
When the exception happens, one of the 4 FTP tasks on the pxm will no longer be available to process requests.
Frequency:
One time occurrence.
CSCds63635
Symptom:
It takes a long time for some connections to route.
Condition:
When some parallel trunks have an insignificant reduction in bandwidth, so that PNNI does not distribute an updated PTSE. The master node continues to choose these trunks (equal to or greater than 3) and the connection cranks back 3 times, after which the same trunks are chosen again.
After 30 minutes the PTSE update clears this problem.
WorkAround:
None
CSCds63689
Symptoms:
PXM card was reset and a core dump was generated.
Conditions:
This problem occurred while the user was trying to change the external BITS clock cable.
Workaround:
Do not adjust the cable if the cable is attached to the active PXM. This will prevent a node reset (if the standby PXM is not ready) and the above problem is triggered.
Frequency:
One time occurrence.
CSCds63745
Symptom:
The tstconseg fails on BPX when it is connected to AXSM.
On AXSM it results in large delay.
Condition:
Interworking issue between BPX and MGX. It only happens in the interworking scenario and not when they are connected to same equipment.
Workaround:
None
CSCds64258
Symptom:
tstdelay and tstconseg takes an order of 2ms longer in some connection configurations.
Condition: This occurs with tstdelay on dax connections. It also occurs with tstconseg that have ports physically looped back to another port on the same card.
Workaround:
None.
CSCds64282
Symptoms:
One end of the dax conn doesn't show alarm, when a down port is executed on the other end.
Conditions:
When a dnport is executed, the other end of DAX connections doesn't go into alarm.
Work Around:
None.
CSCds64302
Symptom:
tVsiSync task crashes, when the standby attempts to load a new firmware revision But the axsm card eventually comes up.
Conditions:
The AXSM card seem to crash while performing a VSIrmGetConnRef or qe_mf_fill operation.
Workaround:
None
Frequency:
Intermittent.
CSCds65195
Symptom:
The shellconn command lkup pnni_base_group causes the pxm to reset.
Condition:
This seems to occur for the specific string pnni_base_group every time.
Workaround:
Avoid using lkup. If this is not possible, avoid "lkup pnni_base_group".
CSCds66741
Symptom:
dspcds shows critical alarm on some AXSM cards but dspndalms does not show any alarm. This is only a display problem.
Condition:
Sometimes this is seen after PXM switchover.
Workaround:
None.
CSCds67334
Symptom:
In an AXSM redundant pair, the standby AXSM become active and active AXSM become Standby.
Condition:
None.
Workaround:
None.
CSCds67426
Symptoms:
Two PXM45 nodes with one end has primary and secondary clock configured (first node) another end has clocking sources (second node) have been reset. The first node is up before the second node. The pxm45 resync clocks will get NAK from AXSM card. This will cause clock configuration status in not configured.
A4A.7.PXM.a > dspclksrc Primary clock type: generic Primary clock source: 6:1.1:1 Primary clock status: not configured Primary clock reason: no clock signal Secondary clock type: generic Secondary clock source: 6:1.2:2 Secondary clock status: not configured Secondary clock reason: no clock signal Active clock: internal clock source switchover mode: non-revertive
Conditions:
One node is up before second node.
Workaround:
Reconfigure the clocks with cnfclksrc commands.
CSCds68426
Symptom:
Sometimes, after non-graceful upgrade, some DAX SPVP stayed in failed state.
Condition:
Occurs sometimes after a non-graceful upgrade which accompanies a system reboot. Happens for DAX connections.
WorkAround:
None.
Additional Information:
dncon and upcon will recover the connection.
CSCds69511
Symptoms:
SVC Based RCC in MPG networks will not get rerouted if the service class NRT VBR is not available.
Conditions:
If the service class NRT VBR is not available on a node in a different peer group or if the bandwidth in the service category is not enough for SVC Based RCC, the SVC Based RCC will not get routed on another service category.
Workaround:
There is no workaround to this situation except to make sure that NRT VBR is available on all nodes with the required bandwidth
CSCds69515
Symptoms:
The Routing failure cause code sent in the Signaling Release message is always Destination Unreachable.
Conditions:
When Signaling on the source node or entry border node (in case of Multi Peer Group) has a problem in routing a call in the network, the cause code will always be returned as Destination Unreachable even though the cause for the routing failure might be different.
Workaround:
There is no workaround to this situation. The Release will not carry the right cause code.
CSCds69518
Symptoms:
SVC Based RCC cannot be established on ABR service category.
Conditions:
When the service categories NRT VBR, RT VBR and CBR are available, PNNI tries to setup the SVC Based RCC with ABR as Service Class. But ABR call will fail at the source node or next node due to invalid IE contents.
Workaround:
There is no workaround to this situation.
CSCds71721
Symptom:
AXSM cards continuously switch between Active and Standby when connected to feeder.
Condition:
Active and Standby back cards were unequal, one had 2, one had 1.
Workaround:
Use the same number and same type of back cards in Active and Standby. This has so far been reported only in one card. If the above doesn't work (replace Front and Daughter cards).
CSCds74175
Symptom:
When bit error are injected on a protection line and if the protection line were to be active (in case of intra card APS), "dspbecnt" would show those errors on the working line stats instead of the protection line stats.
Condition:
This happens only for an intra-card APS case. The problem is still under investigation.
Workaround:
If the working line is active, then the display shown on dspbecnt is correct. If the protection line is active, then use the stats shown on the working line as the protection line bit error stats and vice versa.
CSCds74195
Symptom:
clrchancnts command does not clear all the counts.
Condition:
Pass traffic so that the counters accumulate some counts and then stop the traffic. Now execute "clrchancnts" followed by dspchancnt. Ideally, the counters should show zero as there is no traffic. But the counters show some values.
Workaround:
Use clrchancnts after dspchancnt. The values will be cleared.
CSCds74565
Symptoms:
PNNI node name displayed in dsppnni-node is not the same as command prompt node name.
Conditions:
When the newly configured node name is a matching prefix of the old stored node name, the new node name was not written to the disk. So the PNNI node name won't show the correct node name.
Workaround:
Clear the old node name by typing a completely different node name and then try the new node name.
S3 BUGS
CSCdr50289
Symptom:
XBAR plane available Multicast event buffer got corrupted.
Condition:
When XBAR plane available multicast is generated, which happens after standby inserted.
Workaround:
None.
CSCdr50889
Symptom:/
-dsplns command accepts junk as input parameter.
Condition:
dsplns command takes no parameters. Enter junk after dsplns on command prompt. It is accepted. dspports command is working fine.
Workaround:
None
CSCdr77019
Symptom:
Memory allocation failure detected in stats region on the pxm card.
This is the SNMP region - region2.
Conditions:
On multiple resets on a specific AXSM card in the system, we might get into a situation where we are losing memory per AXSM reset on the PXM card.
Workaround:
None.
Additional Information:
In such cases, conduct a switchover to the other PXM card in the shelf. If you have a single pxm, reset the card. Note: conducting a reset on the PXM card will cause service outage.
CSCdr78943
Symptom:
cnfpnportcac command from PNNI cli will fail.
Condition:
When a combination of MaxBw and Bookfactor values are modified at the same time, AXSM can reject the configuration erroneous.
Workaround:
Perform the configuration of bookfactor and max-bw one after another.
CSCds01758
Symptom:
An incorrect error message is displayed on the CLI when the setrev command is issued.
Condition:
When attempting to do a setrev on an empty slot, an error message is displayed to indicate the file does not exist. This happens because the card type in the slot cannot be determined (slot is empty).
Workaround:
None
CSCds03436
Symptom:
Call to remove a stats file fails and an event is logged. This is an intermittent problem.
Condition:
Remove fails because for a 15 minute bucket interval, there are two files generated. As they have the same name (same interval), the file gets overwritten and there is only one file in memory. Two entries are registered for the same file as it was generated twice. For the first entry, remove is successful. For the second entry, remove fails. The cause of this problem is that there is a synching problem with the ticks and the system clock time. Even though timeout happens after the specified number of ticks, the system time shows a lesser time.
Workaround:
None.
CSCds03683
Symptom:
dsppnni-node command does not display the Node Name.
Condition:
Sometimes, the dsppnni-node does not reflect the node name even though the prompt on the node displays it. This is not service impacting.
WorkAround:
None
CSCds05239
Symptom:
If quit in previous display for dspsarcnt - after that time, if dspsarcnt is done - no output is seen on the screen. The prompt is returned back.
Condition:
Happens every time user quits out of display of dspsarcnt. If however user does not quit - but types CR - then the problem is not seen.
Workaround:
Do not type quit during display of dspsarcnt.
CSCds06083
Symptoms:
addport, addpart, delport or delpart commands can be rejected
Condition:
VSICore port data structure is not initialized at the time of port configuration, this causes garbage to be present in the port data structure, which sometimes turns out that the VSICore thinks that clock is configured, even though it was not.
Workaround:
None
CSCds11605
Symptoms:
When adding connections right after performing a switchcc, occasionally, VSIErr 0x9003 is displayed on the AXSM console even though all connections are successfully added. Please note that this VSIErr is non-service affecting.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) Connections are established from NODE_EP1 to NODE_EP2.
(3) perform a switchcc on NODE_EP1.
(4) Right after the switchcc, add SPVCs on the UNI at NODE_EP1. Occasionally, VSIErr 0x9003 is displayed on the AXSM console even though all connections are successfully added.
Workaround:
Do not add connections right after performing switchcc. Wait for about 0.5 to 1 minute.
CSCds16572
Symptom:
AXSM reboots and is stuck in failed state.
Conditions:
Trying to burn non-existent boot code.
Workaround:
None.
CSCds17159
Symptom:
The data transfer fails in popeye2 node for data option with aesa_ping command
Condition:
This is caused when LCN binding is done before adding the LCN to LCN table.
Workaround:
None.
CSCds17564
Symptom:
On execution of dsperr command using the "-en <errornumber>" option, data can be displayed for a different error number.
Conditions:
Execution of "dsperr -en <errornum> -sl <slotnumb>" where the shelf has experienced at least 100+ errors logged.
Workaround:
This indicates that the error files, 100 per card, have been overwritten due to the numerous errors being logged by the card. The workaround would be to catch the error as early as possible by doing the dsperr command.
CSCds17719
Symptom:
No access to node via LAN
Conditions:
LAN port has hardware failure. Driver does not detect and request processor switchover.
Workaround:
None. Could use IP Connectivity interface for management as the primary. If not, a manual switchover or rebuild is required.
CSCds20339
Symptom:
When "cnfcdsct" command is executed with ports present, the error message is "conns are still present" instead of "down all ports before configuring card SCT".
Condition:
When "cnfcdsct" is called with any port in "upport" state.
Workaround:
Ignore "conns are still present". Go ahead and down all ports before calling "cnfcdsct".
CSCds25447
Symptom:
There should be no visible symptoms for this bug. This bug is raised purely for code maintainability purposes.
Condition:
Not applicable.
Workaround:
Not applicable.
CSCds25483
Symptom:
An active call which receives a Release-Complete message will fail to release the call in a particular case.
Condition:
This case may occur when a badly formatted Release-Complete message is received when the call is active. The data structures associated with the call will remain intact causing a dangling connection. The state of the call will erroneously show N0 state.
Subsequent receipt of a Release message will also fail to clear the call fully.
Workaround:
The audit task which runs in the background periodically will clear the dangling connection.
CSCds27446
Symptoms:
When performing SPVC reroute and switchover the UNI (master side) at the same time, connection delete may fail on the standby. After switchover, if the same connection is recommitted, VSIErr will be observed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on one of the NNI on NODE_VIA.
(4) switchredcd on the UNI (master side of the connection) on NODE_EP1.
(5) When everything is rerouted, perform a switchredcd on the same UNI. Sometime later, some VsiErr are observed on the AXSM console.
Workaround:
Do not perform switchover while rerouting/derouting connections.
CSCds27960
Symptom:
When working line cable is pulled and active line switches to protection line, "dspapsln" command "Alarm State" shows "Clear" even if "Working Line Pending Request" shows "SignalFailLowPriority".
Condition:
Working line fails.
Workaround:
"Working Line Pending Request" is correct. Ignore "Alarm State".
CSCds29751
Symptom:
In a multi node setup, a call cannot be established fully. Before it is established, it gets released from the network.
Condition:
The CONNECT messages are not arriving in time for the call to be set up.
Workaround:
None.
CSCds30648
Symptom:
Standby stays in i state and do not become standby ready
Condition: This has happened only once when tester did reboot of active card when standby was not ready. This is something
not recommended. This problem didn't happen after that.
WorkAround:
None
CSCds31074
Symptom:
Resources could leak.
Condition:
CNTRL-C is pressed to abort a CLI command which is in process.
Workaround:
Avoid aborting an in progress CLI command by CTRL-C.
CSCds31341
Symptoms:
Some connections are not able to reroute, reroute is not even being attempted; i.e. connections are not routed.
Condition:
Cables are pulled off at master and via nodes. Reconnect the cables but connections are not routed.
Work Around:
None
CSCds32464
Symptom:
Sometimes, operator cannot connect to the PXM console port from a PC. This problem is not seen from UNIX based terminals.
Condition:
None.
Workaround:
Execute PXM switchover.
CSCds32847
Symptoms:
When user not specify a CBR connection's CTD/CDV value, it shows in PXM as N/A while -1 in AXSM.
Conditions:
When you provision the CBR connection without specify CTD/CDV values.
Workaround:
Provision with CDV/CTD values.
CSCds33218
Symptom:
TLB exception caused by a an invalid parameter. This causes an event to be logged and the interrupted FTP request must be retried.
Condition:
An FTP request is interrupted during logout.
Workaround:
None.
CSCds33855
Symptoms:
Event log header in the event log being created is not complete. Cannot read logs from that file.
Conditions:
When a event log file is being created, PXM has been reset.
Workaround:
Event logs can be read on redundant PXM card.
CSCds35707
Symptom:
The message header "Cause Rcv Count Xmt Count" displayed repetitively.
Condition:
This is an intermittent problem and happens on some nodes, sometimes.
Workaround:
None.
CSCds38742
Symptoms:
If min VPI and max VPI values are misconfigured on PNNI controller and AXSM then "dsppnport" command will show min VPI to be more than max VPI.
Conditions:
Following is an example where min VPI can be calculated as more than max VPI.
1. On AXSM (a) minVpi = 4095 (b) maxVpi = 4095
2. On Controller (a) minVpi = 0 (b) maxVpi = 255
The usable VPI range can be calculated as (a) minVpi = max of (minVpi on AXSM, minVpi on PXM) (b) maxVpi = min of (maxVpi on AXSM, maxVpi on PXM)
This configuration would mean no VPI on this interface can be used.
Workaround:
Configure the min and max VPI values correctly so that there is always a usable range.
CSCds40655
Symptom:
1. For some successfully routed calls the Master end showed Last Fail cause as Invalid while the slave end showed SPVC Established.
2. No information on how the last fail cause field is being populated.
Condition:
None
Work Around:
None
CSCds42201
Symptom:
Standby PXM45 card is in continuous reset loop, all AXSMs in the shelf are either in Failed state or in reset loop.
Condition:
Injecting a hardware failure on SRAM component of Active PXM45 card manually.
Workaround:
None
CSCds42505
Symptom:
No Major alarm is displayed against AXSM card in card alarms when the card is in Failed state.
Condition:
Injecting a hardware failure on SRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43034
Symptom:
A message appeared on the console when AXSM is in Failed state.
Condition:
Injecting a hardware failure on SRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43093
Symptom:
switchcc allowed to be executed when the standby PXM45 card has a hardware failure.
Condition:
Injecting a hardware failure on SRAM component of Standby PXM45 card manually.
Workaround:
Do not execute switchcc.
CSCds43124
Symptom:
Standby PXM45 card hardware failure is not reported correctly.
Condition:
Injecting a hardware failure on SRAM component of Standby PXM45 card manually.
Workaround:
None
CSCds43165
Symptom:
Active and Standby PXM45 card hardware failure is not reported in the event log.
Condition:
Injecting a hardware failure on SRAM component of either Active or Standby PXM45 card manually.
Workaround:
None
CSCds43545
Symptoms:
popup message appear on screen.
Condition:
When trying to do a delcon.
WorkAround:
None.
CSCds43553
Symptom:
No trap is seen on HP Open View after PXM45 card switchover
Condition:
Injecting a hardware failure on BRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43554
Symptom:
No error log is seen about the BRAM component failure.
Condition:
Injecting a hardware failure on BRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43557
Symptom:
Event log file got corrupted
Condition:
Injecting a hardware failure on BRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43560
Symptom:
PXM45 card status LED is green, when the card is continuous reset loop.
Condition:
Injecting a hardware failure on BRAM component of Active PXM45 card manually.
Workaround:
None
CSCds43563
Symptom:
Sometimes, Standby PXM45 card goes to Failed state.
Condition:
Injecting a hardware failure on SRAM component of Standby PXM45 card manually.
Workaround:
None
CSCds45296
Symptom:
The dspconinfo command was showing x lines of wrong state with x down SPVCs. This was happening because dspconinfo was not handling downed conns. So handling of downed conns will eliminate the problem.
Condition:
When ever there was downed conns and dspconinfo was executed, the Wrong state string used to appear.
Work Around:
None
CSCds45411
Symptoms:
Address search fail errors are sometimes seen in the following setup... 1. NNI ports on different AXSM cards connected back to back with ILMI enabled on both ports. 2. One of the AXSM cards has a redundancy setup and the error messages are seen on that card.
Conditions:
The error messages are seen in the following cases
1. The port is downed (dnport). 2. The AXSM card is switched (switchredcd) 3. The peer AXSM card is reset.
The address tables on the active and standby cards don't get synched up when a new address is added. As a result when an address has to be deleted it is sometimes not found on the standby. This problem does not affect the ILMI servicing any way because when an AXSM card switchover occurs the resynch process synchs up the address tables on the standby card.
Workaround:
None
CSCds45450
Symptom:
The standby PXM45 card fails to become standby.
Condition:
After switchover of PXM45 cards.
Workaround:
Reset the standby PXM45 card.
CSCds53634
Symptom:
When a line on an OC-3 MMF backcard of AXSM is down (using dnln) the laser is not turned off. The other end of the line does not declare LOS.
Condition:
This happens on all OC-3 MMF backcards of AXSM. This is a hardware issue and the investigation is in progress to determine the root cause.
Workaround:
None.
CSCds54873
Symptom:
After the axsm switch over, if there were ilmi sessions been enabled, you will see a few ilmi messages.
Condition:
The data pane switch over faster than control pane, so we will start getting ilmi PDU on the newly Active going card just before the card goes to ActiveReady. The message indicate them.
Workaround:
None
CSCds55631
Symptom:
Whenever a port state changes - the change is not recorded in the event log.
Condition:
All port state changes.
Workaround:
None.
CSCds55940
Symptom:
Card alarm is generated when core redundancy is lost.
Condition:
Even when core redundancy is disabled using cnfndparms.
Workaround:
None
CSCds58507
Symptom:
dpscd and dspcds do not indicate upgrade status for the cards being upgraded
Conditions:
Initiate upgrades on a card set and use the dspcd/dspcds. The card show normal card states.
Work Around:
Look at the Prim/Sec/Current revision using the dspcd for each cards.
CSCds58518
Symptom:
No loss of redundancy alarm is shown while the redundant set is in the middle of upgrades
Conditions:
After the loadrev is completed on a redundant pair and the standby card goes to standby state, the redundancy alarm is cleared
Work Around:
None
CSCds58799
Symptom:
dsppnni-link command takes logical port as the input argument.
Condition:
It is the syntax for this command.
Workaround:
None. Use dsppnport <port> to get the logical port id.
CSCds58912
Symptom:
CC alarm is not always reported.
Condition:
Enabling and Disabling CC multiple times on a connection may cause the CC alarm not to be reported.
Workaround:
None.
CSCds62345
Symptom:
System runs out of memory due to a memory leak.
Condition:
In rare cases, when we try to send out a SETUP message, we could have a situation where a packet is held up and never freed.
Workaround:
None.
CSCds63066
Symptom:
One or more AXSMs fail to come up while Standby PXM is coming up.
Conditions:
When an AXSM is coming up while Standby PXM is coming up, the applications fail to complete the initialization on the AXSM. This results in AXSM failing to come up.
Workaround:
Reset the failed AXSMs once the Standby PXM is READY.
CSCds63506
Symptom:
No defect will be exposed to user.
Condition:
Not applicable.
Work around:
Not applicable.
CSCds65600
Symptom:
"CM_ASYNC_API: force resync start" msg being displayed on the console
Condition:
Whenever the force resync kicks in.
Workaround:
None.
CSCds72007
Symptom:
The AXSMs always download the firmware image from the Active PXM disk.
Conditions:
If the node was previously running 2.0.2.x and upgraded to 2.0.10.x or later, the AXSMs always get downloaded the firmware image from the Active PXM disk even though the AXSMs have the image in their Flash.
Workaround:
Use the shell command gShmForcedSwDnldSet (<slot>, 0), where 'slot' is the physical slot number of the AXSM, to enable AXSM download the image from its Flash.
CSCds73161
Symptom:
On Standby side some times we do see Trf Param: Broken link error in event log. No other functional effects
Condition:
This happens when sometimes traffic index is journaled to standby before traffic parameters. This should not have and side effect at all and act-standby should be in sync. This is just a confusing error message and need not to worry.
WorkAround:
None
Problems Fixed in Release 2.0.11
Bug ID
Description
S1 Bugs
CSCdr70497
Symptoms:
The active PXM card takes over 10 minutes to present the login prompt, and meanwhile, the standby PXM is reset multiple times automatically.
Conditions:
This is a rare condition where the standby PXM has to experience a card reset fault while it is powering up, and the active PXM in is the middle of mastership arbitration with this standby PXM card. Mastership arbitration is performed between the active and the standby PXMs when both PXMs are powered up at the same time.
Workaround:
The active PXM will eventually rebooted itself within 15 minutes and abort the mastership arbitration when the above condition occurred. The node will come automatically afterward.
CSCds07776
Symptom:
The Standby AXSM/PXM fails to come up and is put in FAILED state.
Condition:
After several hundred switchovers, the Standby card fails to come up due to failure of a DB Table Creation. This results in Standby card failing to complete its initialization and hence gets rebooted. After three such attempts, the card is put in FAILED state.
Workaround:
Reset the corresponding ACTIVE card.
Problem Occurrence:
Intermittent or occurs once.
CSCds16063
Symptoms:
SPVCs do not get routed.
Conditions:
When there is a configuration error on two ends of a trunk with a VPI/VCI mismatch, the master SPVCs generated from the node with the lower nodeid with the configuration error will have failed calls. The connections may not get routed even if there are parallel links without any configuration error
Workaround:
The workaround for this problem will be to remove this configuration error.
CSCds22416
Symptoms:
The problem will cause UBR calls to fail
Conditions:
When AVCR for a PNNI link along the route to the destination becomes zero, the route search for that destination will fail even for UBR calls.
Workaround:
None
CSCds24309
Symptom
Switchred repeatedly will cause one of the APS sides to have the following
configuration
J1.3.AXSM.a > dspapsln 3.1.5
Working Index : 3.1.5 Protection Index : 4.1.5
Provisioned Arch : 1+1 Provisioned Direction : bi
Operational Arch : 1+1 Operational Direction : bi
Active Line : working WTR(min) : 5
SFBer 10^-n : 3 SDBer 10^-n : 5
Revertive : Yes Last User Switch Req :
ForcedW->P
Bridge State : WChan Bridged Selector State :
Selector Released
Protection Line Pending Request : SignalFailLowPriority
Repeated switchredcd causes this condition when APS is provisioned.
Effect - This would prevent APS from switching to the protection line in case of any failure on the working line causing loss of traffic.
Work Around.
Executing forced switch from working to protection using switchapsln <bay> <line> 3 <serviceswitch> on both sides should clear it.
CSCds24374
Symptoms:
The card goes to Failed state after 3 SW/HW error resets, with reason SHM_CDF_MAX_RESETS_REACHED.
Conditions:
The card is getting reset continuously because of some SW/HW error in the card. These three resets have to be within a period of 100 hours
Workaround:
None
Additional Information:
Reset the card by using cli command resetCd <slotNo> for that card.
CSCds26049
Symptom:
Standby Card in continuos reset with HW monitor task crashing with TLB exception
Conditions:
When upgrading from release 2.0(23.1) to 2.0(30)A1 using the graceful upgrade method.
Workaround:
Use setrev to go to release 2.0(30)A1
CSCds28030
Symptoms:
CWM will not be able to read the SCT file from the disk.
Condition:
If the SCT file which is not created by the CWM, is used, the SCT-ID fields are always set to 1 even for SCT files with ID other than 1. This causes the CWM to abort the file read operation.
Workaround:
Use the latest SCT file or use the SCT files created by CWM.
CSCds33324
Symptom:
PNNI can't detect bad clock source.
Condition:
The cause effect of this problem is that the PNNI will not get the trap, when the clock manager report the clock has a problem.
Workaround:
Not available
CSCds34606
Symptom:
switchredcd <from-slot> <to-slot> with large and invalid value for from or to slots would cause PXM to crash then switchover.
Conditions:
switchredcd with invalid slot values.
Workaround:
Don't give invalid slot value. Use only slot number from 1 to 32
CSCds34659
Symptom:
Shelf Manager task got suspended.
Condition:
Exception in the Shelf Manager task.
Workaround:
Pullout the PXM45 card and re-insert it.
CSCds34714
Symptom:
After executing a "resetsys" command, on a system with 12 standalone (non redundant) AXSM cards and 2 PXM cards (slot 7 and 8), the ACTIVE PXM card coming up (after the resetsys) might experience going into an ACTIVE-F state. This will cause a switchover to the other PXM card as soon as the other PXM card is available (i.e. gone to STANDBY state).
If you need to execute "resetsys" on a fully loaded shelf/node, and you have experienced this problem, you can recover by removing some of your AXSM cards from the shelf before the resetsys is executed. The recommendation is to leave only 3 cards in the shelf before the resetsys command is executed.
CSCds37401
Symptom:
In a redundancy configuration, repeated valid and/or invalid addred/del red commands may corrupt the back card type. This will be seen in dspcd in AXSM or PXM. Subsequent valid addred commands will be rejected because of back card type mismatch.
Unknown. Till now we have just observed it 2 times in only one network. Have put efforts to reproduce it in the same network but were not successful.
WorkAround:
None
CSCds44402
Symptom:
After a switchredcd, newly active card could not become active ready (see i at CLI prompt) and both cards in redundant pair get reset after a about 5 minutes.
Conditions:
One of the applications on the active card did not transition to active state in time.
Workaround:
None.
CSCds45313
Symptom:
Active PXM card got soft failure (Active-F) when using CLI command of "dspcds". Standby PXM card is also not coming up. The system will come up the error message like pnRedman task is running away CPU.
Condition:
Running many "resetsys" with script file on a node that has more than 20 pnni-links and 14K connections. After about 3 hours the pnRedman task got suspended. The problem is caused by a clocking port coming up and down dynamically, which happens under rare conditions.
Workaround:
None.
CSCds46519
Symptom:
ilmi task crashes and card may reset.
Condition:
There was a problem in vsicore w.r.t passup and if for some reason vsicore blocked the ilmiPassuptask, ilmiMain was crashing.
Workaround:
Normally this problem used to happen only when we had more than 30 interface on a single axsm with ilmi enabled. So reduce the number of interface with ilmi enabled.
CSCds47673
Symptom:
On the affected interface PNNI protocol will be in "ATTEMPT" state and no connections can be routed over this trunk. SSCOP protocol on an affected interface will show "RESET" state. On a PNNI link either PNNI or SSCOP or both might be impacted.
Conditions:
Under rare conditions, resetting of the PXM card may result in PNNI/SSCOP protocols on some interfaces not being able to communicate with their peers. This results in SSCOP being in "RESET" state and PNNI being in "ATTEMPT" state.
Workaround:
None
Other Information:
When an interface is affected by this problem, downing (dnpnport) and subsequently upping (uppnport) the interface will alleviate the problem.
CSCds50617
Symptom:
The Standby PXM/AXSM fails to come up.
Conditions:
The control information on the Active PXM/AXSM used by the Standby PXM/AXSM is corrupted. This results in the applications on the Standby PXM/AXSM fail to complete their initialization failing the card to come up.
Workaround:
The Active peer of the failed card should be rebooted.
CSCds51901
Symptom:
Floating point exception and system gets reloaded automatically.
Condition:
If a task is doing floating point operation and in middle of that context switch happens and new task also does the floating point operation and now when original task is scheduled, floating point registers have invalid value for that task vxworks doesn't store floating point vars on context switch if that task in not spawned with some flag set. Due to this that task will create floating point exception
WorkAround:
none
CSCds52919
Symptom:
PXM45 could crash due to SAR Link list access invalid Pointer. This problem is caused by the changed in CSCds38562, where we cleanup the HUMVEE ILT and ELT table entry The ILT table is not protected so ILT table could delete more than once, once by proxy slave and another by PNNI, when they unbind the GLCN.
Solution:
The solution is to protect the ILT with the reference to refKey, if the refKey is not zero, then we will delete the ILT, after that initialize the refKey to zero.
Workaround:
None
CSCds56700
Symptom:
In a single PXM node, after runrev is done the PXM card resets 2 times and comes back in the older revision
Conditions:
In order to get into this, you have to do a setrev back to the older revision from the higher revision. This causes a rebuild from disk.
Work Around:
Once in the older revision Need to clear the rebuild from disk flag before you do upgrades sh> gShmRebuildFlag 2
CSCds57024
Symptoms:
The sscop is not in Established state or the PNNI link is not up and running though the port status as seen on the controller shows as up and good. The Control VC connections are missing on either or both the slave cards.
Conditions:
After resetsys and when the system is coming up, the ports may look healthy as seen by dsppnport or dsppnports commands.
Workaround:
Reset the card on the switch (AXSM).
CSCds63376
Symptom:
Axsm card resets while attempting to read sct file.
Condition:
The problem happens if the SCT file being read is of size zero (or bad)
Workaround:
Don't leave any corrupted SCT file of size zero bytes, or load latest revision firmware which handles this error case.
CSCds68882
Symptom:
When upgrading from 2.0.10 or earlier AXSM image to 2.0.11 image, both active and standby can get reset.
Condition:
Both active and standby running 2.0.10 or earlier image, when loadrev is executed, standby AXSM may be reset multiple times before finally coming to standby and then active.
Previous active AXSM may also reset itself before finally come to standby state with 2.0.11
Workaround:
- use vsiChkAll to verify all connections are healthy before running loadrev.
Note:
This is caused by a bug in 2.0.10 or earlier image (now fixed in 2.0.11) where invalid connection information may be sent to standby.
CSCds71908
Symptom:
When you enter sysBackupBoot at the command shell prompt pxm45> of a standby pxm45 (where two pxm45 cards installed in the shelf) or from an active pxm45 (where only one pxm45 installed in the shelf), the command prompt does not come back. Furthermore, the pxm45 does not get into backup boot.
Condition:
This condition occurs because the bootline is not initialized similar to the one shown below.
Unknown.7.PXM.a > bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
boot device : lnPci
processor number : 0
host name :
file name :
inet on ethernet (e) : 0.0.0.0
inet on backplane (b):
host inet (h) : 0.0.0.0
gateway inet (g) : 0.0.0.0
user (u) :
ftp password (pw) (blank = use rsh):
flags (f) : 0x0
target name (tn) :
startup script (s) :
other (o) :
Workaround:
To work around this, you can do one of two things: (1) Initialize the bootline by entering bootChange from the CLI prompt to input the appropriate IP addresses. Then reboot the card with Esc-Ctrl-x keys hold down together. This makes VxWorks recognize the new bootline entries. After the pxm45 comes up, you can then issue sysBackupBoot from the shell prompt pxm45>. (2) At the shell prompt pxm45>, enter "sync" command to synchronize the data in DRAM to the hard disk. Then enter sysToMonitor(0xbbee00c4) to reboot into backup boot.
CSCds76260
Symptom: Traps are not being received from the switch. Some traps are getting lost - or no traps are being delivered.
Conditions:
1. On a redundant system, the standby pxm card is reset.
2. On a redundant system, the standby pxm is removed and never reinserted.
3. On a standalone system, a standby pxm is added but is removed and never re-inserted.
4. On a standalone system, a standby pxm is added but fails.
Workaround:
The conditions above will result in a standalone pxm system. In this case, when traps are not being received, the recovery method is to reset the active pxm card.
Further Problem Description:
Due to the bug introduced in the system, the trap client task will go into a state where it will flush its queues and send a lost trap to the CWM/external world in the case where the she generates a card removal for the standby PXM. When we get this event, we flush our queues and stop sending out the traps. This persists until a standby card is inserted and we get a card avail event for the standby PXM OR the active PXM card is rebooted.
NOTE: Any time we get a card unveil from the standby pxm we will get into this state until a card avail is received by the trap client task. So, inserting a standby card and unplugging it will cause us to get into this state.
S2 Bugs
CSCdr50503
Symptom:
Command Line Interface (either via a telnet session or via the console port) will hang indefinitely using lkup "bit"'m
Condition:
Issuing the command lkup "bit", lkup "bitstring" or any substring between "bit" and "bitstring" will cause the command line interface to hang on an AXSM. It is a problem with the underlying symbol table display utility.
Workaround:
None
CSCdr78869
Symptom:
Events of type "CHUNKNOTOWNER" are logged in the event log.
Condition:
CLI does a ssiIpcMessageFree before it assigns the memory to itself. This has been corrected an CLI now assigns the memory to itself before freeing it.
Workaround:
None
CSCdr89686
Symptom:
Upon deletion of a secondary clock source with the primary clock source already bad, the node tries to lock to the Primary (even though it is bad.)
Conditions:
This symptom occurs on the MGX8850 running release 2.0, 2.0(01) or 2.0(02) software. The use should have both clock sources configured.
Workaround.
Wait for about 300 seconds and do a dspclksrcs command. The node will display the correct status of the clock with the Primary bad and the active being the internal.
CSCdr94471
Symptoms:
Standby PXM45 card gets reset 3 times and stays in Failed state.
Conditions:
Upgrading PXM45 image from previous version to a new version.
Workaround:
Reset the standby PXM45 card
Problem Occurrence:
Intermittent or occurs once.
CSCds01593
Symptom:
After issuing an "upln" or "dnln" command, the CLI prompt does not appear to be displayed.
Condition:
An debug alarm summary (similar to "Alarm summary critical 1 Major 0 Minor 1.") was displayed at the end of the CLI prompt without a return character.
Workaround:
Press the "Enter" or "Return" key in order display the CLI prompt again.
CSCds08941
Symptoms:
While performing SPVC deroute (initiated at NODE_VIA, the AXSM card in node NODE_EP1 (AXSM slot 2) showed IPC allocation failure.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on the NNI on NODE_VIA.
(4) On the AXSM on NODE_EP1, IPC allocation failure was observed.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
CSCds09512
Symptoms:
AIS is not generated when dnport issued on AXSM
Conditions:
a. Issue dnport for a dax conn where both the UNI ports belong to same slave
b. Issue dnport for a routed connection where both UNI port and Trunk port belong to same slave
Workaround:
None.
CSCds09604
Symptom:
On an initial boot up of two AXSM boards. After both boards are booted, redundancy is added. Then you add APS for the intercard case. With this scenario, the trap generates 60126 when the fiber is already moved prior to adding APS. 60126 implies APS Redundancy Alarm.
Conditions:
Once the APS is deleted and added back on later, it does not generate 60126. This behavior does not correspond to the real behavior and therefore is a bug.
Workaround:
This problem can not be avoided. However, it is not critical to the system not to see this trap. However, it is an error because it is not report an alarm.
CSCds09708
Symptom:
SNMP GETs on the following variables:
cwspOperMaxSvpcVpi, cwspOperMinSvpcVpi, cwspOperMaxSvccVpi, cwspOperMinSvccVpi, cwspOperMaxSvccVci, and cwspOperMinSvccVci may return incorrect value. And the value mismatches with that shown on CLI command. For instance, 'dsppnport' show MaxSvccVci value is 65535, however SNMP get on 'cwspOperMaxSvccVci' variable shows 255.
Condition:
This occurs when the value of these variables is greater than 255.
Workaround:
None
CSCds12955
Symptom:
Calls not routed after setrev
Condition:
Issue the setrev command when 15.5 k SPVCs connections are established between two popeye nodes.
WorkAround:
None:
Addition Information:
Down and up the nni port which is in attempt state
CSCds13444
Symptom:
The following message is generated in the event log: 08-06262 08/23/2000-15:06:51 SYS-3-RUNAWAYTASK E:02239 tRootTask 0x80132248 Task 0x3f008c[tTnInTsk01] is running away on CPU - logging task.
Condition:
A telnet client attached to a CLI session with no user input was echoing control characters.
Workaround:
None.
CSCds13984
Symptom:
The addlnloop command is getting executed when addln is entered. The parser does not check for the exact command entered. The nearest match is returned.
Condition:
Problem occurs when addln is entered instead of addlnloop.
Workaround:
Enter the exact command "addlnloop" or "dellnloop".
CSCds14832
Symptom:
Two nodes (Feeder and another with T3 line, line type PLCP) are interconnected to each other, upon disconnection of T3 RX/TX cable and reconnecting back, AXSM T3 line showed RcvRAI alarm. Feeder side showed communication Failure.
Condition:
False alarm was generated for EM by which RcvRAI was never get cleared.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
CSCds16776
Symptom:
The conn pending congestion counter shows negative values.
Condition:
Calling the free SVC routine again is suspected in case of a particular infrequent error path.
Workaround:
None.
CSCds17876
Symptoms:
The node allows SPVCs with VCI less than 32 to be added.
Conditions:
With the port's minsvccvci set to 32, attempts to add SPVCs with VCI less than 32 are not rejected.
Workaround:
In order to properly use SPVCs with VCI values less than 35 (default), perform the command:
cnfpnportrange <portid> -minsvccvci <desired minimal VCI value> before adding SPVCs with low VCI values.
Since the VCI range below 32 is not recommended by ATM Forum and more control VCs are reserved below VCI=35, a warning message listed below will be displayed when the minSvccVci is changed to be below 35:
** Warning: MinSvccVci HAS BEEN ASSIGNED A VALUE LESS THAN 35
CSCds18258
Symptoms:
Some connections are not able to reroute, reroute is not even being attempted; i.e. connections are not routed.
Condition:
Cables are pulled off at master and via nodes. Reconnect the cables but connections are not routed.
Work Around:
No work around
CSCds18328
Symptom:
The switch has changed the default value of SvccVci from 32 to 35. This has not been reflected in the MIB variable 'cwspMinSvccVci' in "CISCO-WAN-SVC-MIB.my".
Condition: From the MIB, an user would assume the SvccVci value is 32, yet when the user tries to configure SVC or SPVC, the switch only allow configuration for 35 and above.
Workaround:
The user can configure SVC or SPVC with VCI only from 35 or above if the user decides to use the default value. The user can also do an snmp GET of this variable for the interface
CSCds19314
Symptom:
The dsppnports on pxm will show ilmi state as autoconfig but axsm is in UpandNormal state or on pxm ilmi will be showed as disable when it was really enabled on axsm. Condition:
Happens more when axsm is rebooted or node is reset. Normally resetting card/node will solve the problem. or even dnpnport and uppnport.
Workaround:
Reduce the number of ports on this card. Happens more when we have more than 35 ports (vnni) with ilmi enabled on them
CSCds20504
Symptom
This behavior is seen when the APS operates in bi directional mode. The side which sees a channel mismatch failure will go to the selector released state. The other side remains in the protection line selected state.
Condition:
This could cause loss of data as the other side may not have bridged the appropriate line.
Work around
The only way to get out of this situation is to cause a forced switch to the work line. This is done using switchapsln <bay> <line> 4 <service switch>. Do this on both ends of the line.
CSCds23341
Symptom:
Vsierr 0xe007,... is displayed on the screen
Condition:
Combination of cnfpnportcac, addcon and dnport can cause the bandwidth to go negative.
Workaround:
Disable ingress cac. Need to verify this
Problem Occurrence:
Intermittent or occurs once.
CSCds23518
Symptom:
Cell bus connection between PXM and AXSM is lost, AXSM is reset.
Condition:
Problem has occured during trunk switching when there are more than 25K connections.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
CSCds23525
Symptom:
Pnni-link port is in attempt state.
Condition:
Multiple switch overs and reset of slave cards.
Workaround:
Bring the port down and up. The port will be up and pnni-link will be in two-way inside.
Problem Occurrence:
Intermittent or occurs once.
CSCds23579
Symptoms:
Occasionally, when downing a UNI port (dnport) on AXSM after dnpnport and uppnport on the PXM, some VSIErr are displayed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on the UNI on NODE_EP1.
(4) uppnport on the same UNI on NODE_EP1.
(5) dnport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
CSCds24399
Symptom:
switchredcd following by a switchcc could make the old active service module stuck in boot state _ the old standby service module is OK and in active state.
Conditions:
switchcc shortly after a switchredcd
Workaround:
1. Wait until both service modules come back to active/standby pair before doing switchcc.
2. If old active service module is stuck in boot then reset it from active PXM.
CSCds25413
Symptom:
In a node with thousands of SPVC calls, deroute of calls followed by a reroute is very slow.
Condition:
Once the node is in a state of congestion caused by too many calls in the state of being setup or being torn down, we need to process RELEASE messages immediately so as to alleviate the congestion. There was a problem noticed in this path where RELEASE message processing was being deferred.
Workaround:
None
CSCds25534
Symptom:
Connections are not able to route due to running out of trk vpi/vci even vpi/vci should not be running out
Condition:
Reset either master node or via node
Workaround:
reset the trunk card
CSCds26981
Symptom:
The AXSM fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.
Condition: There are more than 4 AXSMs in the shelf and the file descriptor list gets corrupted on the ACTIVE or STANDBY PXM.
Workaround:
None
Additional Information:
1. Reset the PXM card which has the file descriptor list corrupted if redundancy is available. 2. Call the support to rectify the file descriptor list to avoid resetting the card.
CSCds28316
Symptom:
A nni port with ilmi on is stuck in auto cfg.
Condition:
A "none" port or "ip" port was reconfigured as "pnni10" port and ilmi is enabled on the port.
Workaround:
Configure the port as "uni31" and then back to "pnni10". The port will come up as nni.
CSCds28453
Symptom:
When a dncon / upcon is performed on an endpoint, the connections' upload counter is not updated. Use dspcons to see the upload counter.
Description:
Whenever there is a change in the conn. cnfg the upload counter is updated. This was caused by a error in coding (which excluded the admin status change as a config change).
Workaround:
None.
CSCds28520
Symptom:
OC48 Card CLI hangs, and one cannot execute any commands.
Condition:
Some event on the OC48 back card such as APS switchover, card switchover and back card pull.
Workaround:
Reset the hung card.
CSCds30075
Symptoms:
The PSB condition caused by any condition other than the invalid code is cleared even though the PSB condition has not disappeared.
Condition:
This problem can be created by causing a PSB condition through any cause other than the invalid code.
Workaround:
None
CSCds30425
Symptoms:
An AXSM card may be reset immediately after a PXM switchover.
Conditions:
If an user executes a switchcc command (graceful PXM switchover) while an AXSM card is in the process transitioning to the Active Ready state, that AXSM card will be reset by the new active PXM after the PXM switches over.
Workaround:
Run dspcds to verify that all cards are in a steady state (steady card states are: READY, FAIL, EMPTY, MISMATCH) before executing a grace pxm switchover.
CSCds30710
Symptom:
Standby OC-48 card stuck in reset init state.
Condition:
Standby card was reset.
Workaround:
None
CSCds30721
Symptom:
LCN resource not available and connection commit keep failing
Condition:
de-routing of connections and switchredcd of the trunk card at the same time.
Workaround:
None
CSCds31496
Symptom:
Root task could not delete a suspended task.
Condition:
When a software download task gets suspended.
Workaround:
Reset the card using resetcd command.
CSCds32205
Symptom:
User adds feeder on an interface on which connections exist
Conditions:
User will not be able to delete feeder unless connections are deleted. This could be a problem since feeder might have being added by mistake. A CLI prompt should be added to warn users about this.
WorkAround:
Before adding feeder on a particular interface, make sure it is the right interface especially if there are previous connections on it.
CSCds32276
Symptom:
No immediate symptom. Over time when many addapsln/delapsln/dspapsln commands have been executed, we may get IPC message allocation errors.
Conditions:
Execute addapsln, delapsln or dspapsln commands.
Workaround:
None
CSCds32318
Symptoms:
Line shows that there are some statistical alarms, although, the line has no defects. There are no adverse effects of this.
Conditions:
On a t3 line, when line is enabled.
Workaround:
None.
CSCds32413
Symptom:
After a addred or switchredcd, there may be alarms on some channels in the Active AXSM card.
Condition:
Happens after a addred or a switchredcd
Workaround:
None.
CSCds34183
Symptom:
The symptom is that the VSICore and RM database are not in sync. The vsicore indicates the connection is in committed state, and RM is in reserved state.
Condition:
This situation will happen when the Commit timeout, VSICore will Nak the controller, instead of putting the connection is NULL state, the connection is put in commit state.
Workaround:
None
CSCds34687
Symptom:
The VPI range will be 0-255 for NONE port even the AXSM port is a NNI. This blocks the user to use the VPI bigger than 256.
Condition:
None.
Workaround:
None.
CSCds35591
Symptom:
swichred on PXM, standby becomes active, reset the newly standby PXM,
Condition:
Couple of connections stay in failed state
Work Around:
reroute the failed cons (via rrtcon)
CSCds35710
Symptom:
In a node with thousands of calls, we see that the unacknowledged status enquiry counter is beyond the threshold value. This is seen using the command dspintfcongcntr for a particular interface.
Condition:
We might get into this condition due to PXM switchover. The effect of this is that status enquiry can no more be initiated for audit purposes resulting in erroneous dangling connections being present forever.
Workaround:
none
CSCds36145
Symptom:
Getting incremental RAM Sync send error after line/port/partition commands are executed. See description for display details.
Condition:
Card redundancy are setup. Both active and standby are in ready state. Then standby card is removed.
Workaround:
Do not execute line/port/partition command in redundancy setup when standby card is absent.
CSCds36182
Symptom:
During AXSM switchred, previously standby card gets PHYTask exception while transitioning to active. Ports go into provisioning state.
Condition:
This happens on non-OC3 AXSM cards. Should not be problem for all AXSM card if there is no redundancy.
Workaround:
Do not switchred.
Problem Occurrence:
Intermittent.
CSCds36677
Symptoms:
After AXSM sends a passup command to the controller, the message counter doesn't increment for the passup cmd message.
Conditions:
(1) On AXSM, perform addcon, causing a passup command to be sent from the AXSM to the PXM.
(2) After the command is transmitted, perform the shell command vsiPduCountShow. The counter for passup command is not incremented.
Workaround:
-none.
CSCds37301
Symptom:
ports in standby card stay in "vc failure"
Condition: with multiple switch over of two controller cards
Workaround:
none
CSCds37761
Symptom:
The Active PXM gets a software exception and resets unexpectedly when a file is transferred onto the Active PXM using FTP.
Conditions:
When a file is transferred using FTP onto the Active PXM hard disk to a directory that is replicated to the Standby PXM, at times, the Active PXM completes the replication of the file to the Standby PXM at the same time as an internal software timeout. This results in Active PXM generating a software exception which causes the Active PXM to reset.
Workaround:
None
CSCds38135
Symptom:
dspenvalms shows DC Level outside of threshold range, but no node alarm generated
Conditions:
Power entry module being used to generate power supply voltage. When voltage drops below 3 volts, monitoring software declares that the inputted voltage for threshold check purposes is zero.
Workaround:
None. Under this condition there is no alarm. Should this voltage had been generated in a system with a resident power supply module, an alarm would be generated.
CSCds38320
Symptom:
Some SPVC connections will not be routed and stays in fail state
Condition: Unknown
WorkAround:
Delete SPVC end point and re-add it again.
CSCds38562
Symptom:
Two GLCN programs the same ELT Entry in HUMVEE. HUMVEE will indicates ELT Mismatch, no traffic will be passing through.
Condition:
PNNI try to commit the same SSCOP/RCC/IP connection on two different GLCN.
Workaround:
dnpnport and uppnport to check whether problems goes away, if not, please reset the PXM45.
CSCds39375
Symptom:
A nni port has a vpi range of (0-255) available instead of the complete range (0-4095).
Condition:
When ports are provisioned to controller, the default interface type is UNI which at release 2.0.30(D) takes on an enforced range of 0-255. Add nni ports with vpi range 0-4095 on AXSM card. Ilmi is turned on these interfaces. The interfaces on used as nni links.
WorkAround:
Use "cnfpnportrange" command to increase the range to (0-4095).
CSCds41314
Symptom:
Alarms show up in dspcdalms <slot> for the standby card after a switchred.
Condition: Occurs intermittently after switchred.
Workaround:
Another switchred can clear the condition.
CSCds41496
Symptom:
Resources are not updated for a trunk even after connections have routed along them. This is visible in the dsppnportrsrc command. Connections may not route along expected paths.
Condition:
Upon AXSM reset, addcontroller-delcontroller, AXSM switchover.
WorkAround:
None
CSCds41592
Symptoms:
Before switchcc, take the physical connection out (ex. 3:1.1:1).
dspclksrc
Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: no clock signal Secondary clock type: generic Secondary clock source: 14:1.1:1 Secondary clock status: ok Secondary clock reason: locked Active clock: secondary source switchover mode: non-revertive
After switchcc
Primary clock source: 3:1.1:1 Primary clock status: bad Primary clock reason: not configured Secondary clock type: okay Secondary clock source: 14:1.1:1 Secondary clock status: not configured Secondary clock reason: okay Active clock: internal clock source switchover mode: non-revertive
Conditions:
During switchover (the clock resynchronization), If we get NAK from AXSM, the existing code did not assign the right slave id. This cause the set clk message did not send to the clk manager. The display never been updated according to clock manager current status.
Workaround:
Make sure the clock port is up (or make sure the port physically connect the clock source), before doing switchcc.
CSCds41617
Symptom:
Receive RAI count is not cleared by clralmcnt command.
Condition:
For each instance that RDI is received, RAI count is incremented. This can happen in T3/E3 and SONET AXSM cards.
Workaround:
Keep a log of the current "Num of RAI" in order to recognize new RDI received.
CSCds41628
Symptom:
Power supply failure does not generate a node alarm.
Conditions:
External DC power source is used to generate power for node. Circuit breaker is tripped on the power source.
Workaround:
None. Software declares a missing power source normal if it has a power reading of zero volts.
CSCds41931
Symptom:
Connection routing failure due to AvCR being zero on PNNI link that previously was out of LCNs.
Conditions:
In addition to the above symptom the condition for this problem to occur is that the LCN availability remains under 8 on the link of interest.
Workaround:
None.
CSCds42022
Symptom:
Trap 60004 cwShelfRestart was not received after a node reset from CLI "resetsys" command.
Condition:
Upon CLI "resetsys", "reboot", or "resetcd"; On certain hardware, the SNMP master agent takes longer to read the disk DB to extract the trap manager IP addresses and configure the trap communities. Thus, by the time the trapserver needs to send traps out, the community strings are not configured and the traps are dropped.
Workaround:
No known workaround.
CSCds44016
Symptoms:
When SPVCs are tunneled through an DAX-SVP connecting two VTs configured with different VPIs, the connection will not be accepted.
Conditions:
When there is a configuration error in provisioning different VPIs across VTs connected via DAX-SVP
Workaround:
The workaround for this problem will be to remove this configuration error and use the same VPI across the VTs
CSCds45150
Symptom:
Port gets stuck in down in progress.
Condition:
The network should have 50k routed spvc connections. Multiple nni links on a node.Down a a nni port on axsm on one of the node.
Workaround:
No work around.
CSCds45453
Symptoms:
Standby AXSM gets reset multiple times before it becomes standby ready
Condition:
When the syncRamElementAdd fails while connection bulksync, the code erroneous released the iovPtr, which was still used by the higher layer for adding connections into the list. This corrupts memory and when syncRamIovSend is attempted on this bogus iovPtr, the send fails and the active card calls for ramSyncFatalError which resets standby card.
Workaround:
None.
CSCds46551
Symptoms:
When a large number of IISP trunks are configured on the node and a switchover is attempted, system goes into busy state.
This might cause some mismatched connections across the IISP trunks.
Conditions:
When there is a a large number of IISP links are configured on the node and a switchover is attempted.
Workaround:
None
CSCds47500
Symptom:
No event logging is done for APS.
Condition:
None.
Workaround:
None
CSCds47575
Symptom:
Any command on the PXM that accesses the disk will pause for a couple of minutes and displays nothing. Also, any file transfer to the PXM disk will fail. Also, an AXSM fails to load an SCT file and uses default traffic parameters.
Conditions:
When the dsplog attempts to access the log files that have been corrupted, it fails to close the associated file descriptor. This results in exhausting all the file descriptors available on the system over a period of time.
Workaround:
The PXM card should be rebooted.
CSCds50779
Symptoms:
Some connections are derouted and rerouted continuously.
Conditions:
When the SPVCs are provisioned across IISP and the slave endpoints are in the same node of the IISP link, and the IISP is the user side.
Workaround:
Do not provision the SPVC slave endpoint in the same node with the IISP User side.
CSCds51173
Symptom:
-In a popeye2 node, we might have a case where traffic on an SPVC DAX connection cannot be passed though the connection is in OK state on the PXM.
Condition:
This case may occur when the line card containing a DAX connection is removed and re-inserted. After the card-reinsert, the cross connects are not committed to the AXSM in a specific case.
Workaround:
None.
CSCds52449
Symptom:
Configuration on active AXSM is destroyed.
Conditions:
Redundancy is added with active AXSM declared as secondary card.
Workaround:
Make sure that no configuration is enabled on AXSM before adding to redundancy.
CSCds52468
Symptoms:
The ILMI address will not be sent to PNNI for advertisement.
Conditions:
During switchover, the new active will not send the ILMI addresses to PNNI and the addresses will not be visible in the system address tables. The calls for these addresses will not get routed.
Workaround:
There is no workaround to this situation except to reregister the ILMI addresses or switch over the system again.
CSCds52601
Symptom:
With T3 backcard, "addport" or "cnfport" commands fail with min/max port rate at max T3 cell rate (96000 for PLCP mode, 104268 for ADM mode). "dsplns" does show the lines as T3 lines and not E3.
Condition:
The AXSM was reset with E3 backcard in the past, but no "upln" is done using the E3 backcard, i.e., backcard is not reserved for E3. Then the E3 backcard is replaced with T3 backcard and "upln" is done so that ports can be added.
Workaround:
If AXSM T3/E3 backcard is not reserved for a particular type (T3 or E3), reset card when new backcard is inserted before upping lines.
CSCds52916
Symptom:
VTs are still up even when the UNI endpoints on SPVP tunnel are brought down.
Condition:
Two Virtual trunks are connected through a SPVP tunnel. The uni ports the VTs connected are brought down on the controller.
Workaround:
Bring down the ports on the axsm and VTs will stop communicating.
CSCds53212
Symptom:
Active and Standby system were out of sync with each other from PNNI controller point of view. Active side of controller doesn't know that standby is exist.
Condition:
WIN_TIME_OUT means active tries to send but it times out before it can send.
Workaround:
None
CSCds54891
Symptom:
Previously standby AXSM card cannot transition to active ready state after switchred is performed.
Condition:
The AXSM switchred is executed on PXM while AXSM is still in the middle of provisioning ports (using scripts, so once it starts, it does not stop until all ports are done).
Workaround:
Do not switchred until AXSM provisioning is completed. Safer still, wait a few seconds after provisioning before switchred.
CSCds55452
Symptoms:
The problem was handling crankback when VP resources are not available.
Conditions:
Under rare conditions, when VPC resources (like VPI values) was not available for outgoing calls, the release was not generated with a crankback and so an alternate route was not selected.
Workaround:
The workaround for this would be to increase the number of crankbacks or increase the VP resources on the failed link.
CSCds55584
Symptoms
SPVC connections FAILED to route. the Last Fail Cause to be Call Rejected.
Condition:
When adding the partition on AXSM, it is required to configure the maxConns for the partition. The maxConns is constrained to the number of channels supported by a port group. CLI detects, for a given partition ID, if the maxConns entered by the operator exceed the total supported channels with the port group. However, if the operator is adding partitions for different ports that fall within the same port group, as long as each individual partition does not exceed the total supported channels, CLI does not complain the aggregation number exceeding the total supported channels. The problem can be solved by reporting the available channels to PNNI based on the port-group availability which is more accurate.
Workaround:
None
CSCds57279
Symptom:
No traffic passes, PNNI link does not come up, when NNI trunk is configured with a minimum Vpi greater than 255 over an OC48 line.
Condition:
Problem caused by Vpi greater than 255 on OC48 line.
Workaround:
Use a Vpi less than 255 on OC48 lines to avoid this problem.
CSCds57791
Symptoms:
Failure to configure the clock source.
Conditions:
The static memory information has been overwritten by unknown function.
Workaround:
Step 1 goto shellConn by sh command.
Step 2 d &ncdpClockingDb
Step 3 modify the address at &ncdpClockingDb+0xa4 m &ncdpClockingDb+0xa4 (clear to zero).
This procedure will cause the internal code to reallocate new memory to store privateData pointer.
In this way, we can continue to configure the clock.
CSCds58806
Symptoms:
The problem was an unexpected routing failure where some calls never get routed.
Conditions:
Under rare conditions, when the node has many parallel links and many calls using up a small bandwidth, the routing may choose some of the links which cannot support the bandwidth which a new call has requested. This is because the bandwidth change due to previous calls was not significant and so routing doesn't know that the link cannot support the requested bandwidth. In such scenarios, the path table update relies on crankback. With many parallel links, the crankback might not update the path table.
Workaround:
The workaround for this problem is to disable the path table and bring it back up.
CSCds61572
Symptom:
When "dsplns" or "dspln" is executed, there is a "?" in the Frame Scramble field. The line does not come out of alarm by adding physical loopback on backcard or terminal loopback with "addlnloop" command. Resetting card does not get rid of problem. "dspcds" on PXM shows "Active-F" for the slot.
Condition:
This is seen with 2.0(92)A1 sanity label build. It does not happen with earlier build. At some point, "addlnloop" or "dellnloop" has been executed with this label software, after which the Frame Scramble field becomes a "?".
Workaround:
Do not use "addlnloop" or "dellnloop" commands with this build.
CSCds62686
Symptoms:
Some of the ports are in Building VC state after one of the service module cards are reset.
Conditions:
After one of the AXSM cards are reset or reloaded, then the ports may go into Building VC state and never recover.
Workaround:
Reset the card on the switch (AXSM) again.
CSCds63119
Symptom:
When SHM could not update its database to standby PXM, SHM just logs an error. It should reset standby PXM to recover.
Conditions:
N/A
Workaround:
NONE
Further Problem Description:
NONE
CSCds72181
Symptoms:
1) when the active PXM powers up, it stays at the pxm45> prompt with an error message printed saying SHM_BRAM_VER_MISMATCH.
Conditions:
1) The above problem will occur under the following scenario:
a) move a PXM45 card that is running Release 2.1 or greater to a node running release 2.0.11.0 or less
b) insert this card as a standby card in the release 2.0 node
c) when the card becomes standby, make this new standby card the active PXM card in the node.
d) sometimes in the future, reset the node with new active PXM in it.
e) This new active PXM will fail to come up as the active card afterward. It can only be brought up as a standby card only.
or
2) Performing an abortrev or setrev from release 2.1 to 2.0 on the PXM slot on a node can cause the above problem.
or
3) Performing a loadrev/runrev from release 2.0+ to 2.1+ using the standby PXM that was previously already running release 2.1. The database will not be upgraded from release 2.0 to 2.1 when a 2.1 PXM card is inserted as a standby card into this 2.0 node.
Workaround:
1) avoid moving PXM45 cards that are running different software releases (2.0 versus 2.1).
S3 Bugs
CSCdr45241
Symptom:
Selecting the front card for testing based in the command syntax given by diagnostics produced an "Invalid syntax" message.
Condition:
Selecting the front card for testing.
Workaround:
None
CSCdr45875
Symptom:
Even with "pagemode off" in effect some CLI command output still pause in the middle with the prompt "Press <CR> to continue, Q<CR> to quit:"
Condition: An off-by-one error in scanning of output caused an inadvertent miss of the Continuation string. This caused the output to be incorrectly halted waiting for user input.
Workaround:
There is no known work around. It is necessary to enter a <CR> in order to continue output. This will allow the output to complete or until the off-by-one error case is once again encountered.
CSCdr86751
Symptom:
AXSM does not detect loss of cell delineation (LOCD), therefore not generating RDI as a result.
Condition:
Line signal with LOCD is injected into AXSM.
Workaround:
No workaround.
CSCdr91962
Symptom:
No mechanism to clear a portion of a node's configuration.
Conditions:
PXM will full configuration including ports, lines and connections. No mechanism to clear provisioning config without also clearing shelf config
Workaround:
None. New mechanism needs to be supported. New command will be clrcnf.
CSCdr95809
Symptom:
When a command name is abbreviated, the prompt is issued, "Do You Want To Proceed". without including the full command name.
Condition:
Service affecting command such as switchcc, resetsys, resetcd display the confirmation prompt.
Workaround:
Avoid using command abbreviations.
CSCds05064
Symptom:
Reserved BC (Back Card) alarm missing alarm persists.
Condition:
Even when the cards have been unreserved.
Workaround:
Do shmAlarmUpdate on the for the slot.
CSCds05178
Symptom:
Under certain situations, the restoreallcnf may fail and the node's configuration is not restored.
Conditions:
In a node with both PXMs inserted, if the user performs a restoreallcnf of a database that was saved using a different S/W version, the restoreallcnf may not be successful.
Example:
DB Configuration saved with saveallcnf while the active PXM is running S/W version 2.0.1.0.The PXM F/W is then upgraded and is now running 2.0.2.0. The user then perform a restoreallcnf of the database that was saved from 2.0.1.0.
Workaround:
Remove the standby PXM from the node, then perform the above restoration.
CSCds12357
Symptom:
pnCcb takes too much (75-85%) CPU time
Condition:
When nni ports are brought down in a network with 50K routed connections.
Workaround:
None
CSCds13955
Symptoms:
The dspcds, dspcd and dspcdalms do not show the same alarm information.
Conditions:
Alarms reported on an AXSM card is not integrated into the dspcd and dspcds command.
Workaround:
Use dspndalms to find out the different alarms reported under the different categories.
Use the dspcdalms command to show alarms reported under "Alarms From Cards" category.
Use the dspcd/dspcds commands to show alarms reported under "Shelf Slot Alarms" category by the dspndalms command.
In this version of the Software, the above dspcdalms/dspcd/dspcds commands do not show the combined alarm state from "Alarms From Cards" and "Shelf Slot Alarms".
CSCds15147
Symptom:
The connection summary information displayed by command dsppnport wraps after 80 columns (the output exceeds 80 columns).
Condition:
None.
Workaround:
None.
CSCds16241
Symptom:
output from CLI command dsptasks scrolls off screen
Condition:
Always
Workaround:
None
CSCds16452
Symptom:
dspnodalcongth/cnfnodalcongth: some keyword does not match. The threshold names in these commands were different. For consistency and documentation purpose, the threshold names were made same.
Condition:
None
Work Around:
None
CSCds17195
Symptom:
dsppncon command displays SCR and MBS values for CBR and UBR calls.
Condition:
When CBR and UBR SPVC or SPVP are added, dspcon is not displaying SCR and MBS value where as dsppncon is displaying the same.
Workaround:
None
CSCds17592
Symptom:
Configuration commands cnfspvcprfx cnfilmienable cnfnodalcongth cnfabrtparmdft cnfrrtparm execution is allowed on standby card.
Condition:
Command Descriptor table of ccb showing ANYSTATE for the above commands.
Workaround:
None
CSCds21295
Symptom:
dsplog -task dbClnt will show error sometimes during switchcc of two POPEYE21 pxm cards.
Condition: happen during switchcc
Workaround:
none
CSCds21451
Symptom:
User is allowed to add feeder on a VNNI trunk.
Conditions:
The above should not be allowed since this is not a valid configuration. CLI should be blocked. A feeder should be added only on a physical interface.
Workaround:
Do not add feeder on a VNNI trunk.
CSCds26368
Symptom:
AXSM remains in Init state.
Conditions:
When AXSM is reset, AXSM card remained in INIT state with the following error message:
EmTask - emInitFeeder fails for feeder x because ILMI is enabled.
This occurs if ILMI is enabled on an interface and feeder is added on another interface on the same AXSM card.
Work Around:
Do not enable ILMI on the same AXSM if feeder is added on that card.
CSCds26640
Symptoms:
Can not configure the clock sources.
Conditions:
During ncdp resync.
Workaround:
Step 1 Go to ShellConn.
Step 2 Run the ncdpResetNcdpState command
CSCds27986
Symptom:
When "dspapsln" command is executed using protection line ID as input, the working line ID is same as protection line.
Condition:
No special condition.
Workaround:
Use "dspapsln" with working line ID to find out protection line ID.
CSCds31066
Symptom:
Risky commands such as shutdisk are available and are not needed.
Condition: Users with cisco access level can access these commands.
Workaround:
Avoid using commands, shutdisk and format.
CSCds31146
Symptom:
No mechanism to display current community string value.
Conditions:
Issue cnfsnmp command. Display shows garbage instead of valid community string.
Workaround:
None.
CSCds32730
Symptom:
Programming the backplane NOVRAM on a Jupiter backplane fails with a write error.
Condition:
ATMEL AT93C66 parts are installed on the Jupiter backplane.
Workaround:
None
CSCds33798
Symptom:
On a resetsys, the event was not logged indicating the command and username.
Condition:
Enough activity on the system so the lower priority CLI did not run before the system was reset.
Workaround:
None
CSCds33824
Symptom:
Currently when we try to delete clock, it is an implicit set. This will take longer for the clock manager to re-lock the clock source.
Condition:
When user try to use the command "delclksrc" on PXM45, the implicit set clock will happen.
Workaround:
Don't use the "delclksrc" to del clock source. The new fix will only delete the clock source. It will not try to re-lock the clock.
CSCds34234
Symptom:
When PNNI controller sends a msg which is not recognized by the slave, we send a general Response error msg to the controller. Within the response msg, there is slaveCode which VSI Slave copy the msg header sent. Since the Msg header contains LLC-SNAP header, so VSI Slave copy that as well. But PNNI controller don't interpret SNAP Header.
Condition:
PNNI controller could send a msg which is not supported on VSI SLave.
Workaround:
Make sure that the msg is supported by Slave, if not, the VSI master might not be able to handle the response probably.
CSCds34340
Symptoms:
When you give incorrect value for the line option, it complains about incorrect value for the following option instead. There is no destructive effect of this error.
Condition:
Happens when you do "cnfapsln" command with incorrect value for working line.
Workaround:
There is no workaround.
CSCds35712
Symptom:
PNNI link is in attempt state.
Conditions:
After Y red switchover.
WorkAround:
None
CSCds37762
Symptom:
After executing addlnloop command on axsm card - the event is not recorded in event log.
Condition: Executing addlnloop command.
Workaround:
None.
CSCds40637
Symptom:
SNMP responses and SNMP traps being sent out the incorrect network interface.
Conditions:
Node is being managed by only one CWM or has only one trap manager. During operation, the network interface being used for connectivity is changed.
Workaround:
For traps, create a second trap manager.
CSCds43543
Symptom:
When a switchcc is executed, the following messages appear on the console port of the PXM that transitions from standby to active:
go_active, sync_flag=1 SPVC transiting from Standby to Active
Condition:
None
Workaround:
None
CSCds43550
Symptom:
Pop up messages were seen during configuration of SPVC with cnfcon command
Install has both Legs A(1011801,13,102) and (10c1801,0,42)Configuration successful
Condition:
When trace mod PNNET 1 1 is enabled on the node for debugging purpose, above pop up messages use to appear on the screen
Workaround:
Moved the corresponding debug statement to be seen only when CM debug is enabled.
CSCds44287
Symptom:
No particular symptom. AXSM Diagnostic may cease to run.
Condition:
When some error triggers AXSM diagnostic to print out error traces.
Workaround:
Disable AXSM Diagnostic task traces.
CSCds48531
Symptom:
This was noticed in a customer beta trial. The dspcons on AXSM does not show any alarm. However the dspcdalm <slot> on the PXM45 would display chan alarms for that particular slot. This would translate to a node level alarm in the system;
Solution:
Clearing of card level alarms were not being synchronous with the clearing of channel alarms. This was the cause of mismatch.
Workaround:
Rebooting of the AXSM card will clear the alarms.
CSCds48589
Symptom:
Multiple switchred can trigger XBAR remap twice error. The error is also reported to alarm manager. "Card Crossbar" major alarm will be registered.
Condition:
The problem is intermittent. It is rarely observed. The experiment indicates that the spurious errors can be generated when programming XBAR ASIC even though XBAR remap configuration is correct.
WorkAround:
None
CSCds51524
Symptom:
The different values of K1 when doing switchred and when removing cards is cleared when the redundant card comes up.
Condition:
This condition is created by the inconsistent values transmitted on K1.
WorkAround:
A higher priority command such as lockout of protection of forced switch might clear this condition.
CSCds51688
Symptom:
dspcdalms shows alarms for a card in a particular slot (reported by the card) and dspslotalms shows alarms for the slot reported by the shelfmanager.
Condition:
dspcdalms and dspslotalms show different alarms for the same card.
Workaround:
In order to view alarms for a particular slot, dspcdalms and dspslotalms CLIs need to be used.
Known Anomalies from Previous Releases
CSCdr15133
Duplicate of CSCdr20887 conDelError when SPVCs are de-routed due to dnpnport*25k*
CSCdr15197
Un-reproducible IPC buffer memory leak during swichcc with 10K spvc &1k svc *BLOCK*
CSCdr19636
Verified in 2.0.02 dspalm and dspln cmds show diff alarm status
CSCdr20887
Un-reproducible AXSM: vsi error - Cant delete VC entry
CSCdr22569
Verified in 2.0.01 80 abr failed to route in parallel link situation(SLT)(BLOCK)
Un-reproducible CLI gets Hang while switching to the AXSM1 card
CSCds20318
Duplicate of CSCds23518: SLT-sw: AXSMs reset due to SAR error, which is fixed in 2.0.11
CSCds21342
Closed -- not a problem.
CSCds22604
Duplicate of CSCds45453: AXSM: standby AXSM card keeps rebooting due to syncRamError -- which is fixed in 2.0.11
CSCds22824
Duplicate of CSCds26981: SSI DIO: Recover from task deleted while accessing a file, which is fixed in 2.0.11
CSCds22862
Un-reproducible cc to AXSM OC48 slot with AXSM-Yred fails & exit user from
telnet ss.
CSCds22946
Un-reproducible AXSM-RED: AXSM PXM db mismatch causes reroute fail (AXSM-RED-DF)
CSCds23335
Duplicate of CSCds26981: SSI DIO: Recover from task deleted while accessing a file, fixed in 2.0.11
CSCds23586
Duplicate of CSCds00727: Discrepancy in card state between CLI cmd prompt and dspcds output
CSCds23866
Duplicate of CSCds04573: AXSM-red:OC48 failed after switchcc on PXM, Hello msg
miss, fixed in an earlier release.
CSCds24168
Closed -- some of the hardware was missing.
CSCds24320
Un-reproducible axsmred: All VTs go down after swithcc on PXM
CSCds24905
Duplicate of CSCds46551: axsmred: Number of SPVCs do not match between crossing ports.
CSCds28506
Un-reproducible SLT-sw: Tlb load exception at task pnCcb
CSCds33133
Duplicate of CSCds04573: AXSM-red:OC48 failed after switchcc on PXM, Hello message miss, fixed in an earlier release.
CSCds35713
Un-reproducible DLS:DAX conns stayed in conditioning after interface recovered
Release 2.0.01, 2.0.02 and 2.0.10
Problems Fixed in Release 2.0.10
Bug ID
Description
S1 Bugs
CSCdr70591
Symptom:
The SRCV task in AXSM gets an address exception.
Condition:
Problem has occured during trunk switching when there are more than 25K connections.
Workaround:
None.
CSCdr74831
Symptom:
Receive 60905 or 60904 trap as soon as CWM requests for a config upload file.
Condition:
This condition can be reach, when the system is really busy and the scheduler task does not receive a work request acknowledgement from the worker task. Once the scheduler time out exceeds the threshold, the scheduler task will mark it worker control block for that particular worker task as fail. This will disable that particular worker task from servicing any future work request. Currently, we have three worker task in service. If all three tasks are marked in the worker control block as CUT_FAIL, CWM will no longer be able to request any config upload file. Any request set by CWM will be result in receiving trap 60905 or 60904
Work around:
None
CSCdr87841
Symptom:
Vsi master fails to recover on trying to commit a connection on an existing vpi/vci.
Condition:
Add a connection between 2 AXSM cards. Delete one leg of the connection. Try and commit the connection made earlier again.
Workaround:
None
CSCdr88211
Symptoms:
PXM45 fails to send config message to slave.
Conditions:
If we did not get response or trap message from the vsimw, the ncdpClockingDb. privateMsgPtr never been reset.
Workaround:
The solution is using shell command to reset state(ncdpResetNcdpState).
CSCdr89807
Symptom:
Configure an address filter and associate it with a port. Do not have any addresses added to the filter. Make incoming and outgoing svc/spvc calls through the port. System may restart.
Condition:
If the address present in the SETUP message does not have a match in the filter configured against the port, the system may reset.
Workaround:
Do not associate an address filter with a port.
CSCdr99509
Symptom:
SNMP MIB Walk fails even though the cards are in active state.
Condition:
When CiscoView is used for configuring Redundancy and other things, switch might fail to service mib requests. During registration of the MIBs by Subagent, Master agent gets the maximum bytes to be registered and looks for that many bytes using ssiIpcMessageReceive call with WAIT FOR EVER timeout value. In case the subagent could not send all the bytes due to failure of the cards(Reset, fail ec), master agent waits for ever and other Subagent requests and responses can not be serviced. This will cause the EPID queue to be full and causing IPC messages to be dropped from the subagent.
Workaround:
None
CSCds01070
Symptom:
CWM did not receive trap 60901 to let CWM know that File creation has been started.
Condition:
This occur to any file creation that takes less than one minute. These files are, PXM genrict file, PNNI file, AXSM generic file.
Workaround:
None.
CSCds03375
Symptom:
Cpro shows status indicating AIS state when no AIS state exists.
Condition:
This problem may occur when a connection is modified while in the AIS detection state.
Workaround:
Do not modify connections while they are in the AIS detection state.
CSCds05585
Symptom:
When addpart or and "set partition" type command is executed for VT (VNNI) ports, AXSM card gets SW exception and resets.
Condition:
When addpart, delpart or cnfpart commands on VT (VNNI) ports are executed. This does not happen with UNI and NNI ports.
The ifName format has been modified to conform to dependency doc (see CSCds01124). When ifName is made, it is stored in a static variable of fixed length. The old ifName array length is not enough to contain VNNI ifName, thus overwriting adjacent variables and causes memory corruption. This memory corruption cause SW exception.
Workaround:
Increase the ifName static variable array length to cover VNNI ifName
CSCds07804
Symptoms:
The problem is an unexpected system reload.
Conditions:
When a partition is deleted on the service module and when the load info from the service module is received and processed, the system may reload.
Workaround:
None.
CSCds09032
Symptoms:
When connection reroute is triggered from CWM, the operation would fail
Condition:
Happens when rerouting is attempted from CWM on any routed connection.
Workaround:
Attempt reroutes only from CLI, till this bug fix makes it to the release.
CSCds09374
Symptom:
When pulling out an active AXSM, PXM goes into reset
Condition:
Error threshold time is zero. This can be caused by a corrupted database. User can also use cnfxbarerrthresh to intentionally set the error threshold time to zero.
Workaround:
Do not set error threshold time to zero.
CSCds24374
Symptoms:
The card goes to Failed state after 3 SW/HW error resets, with reason SHM_CDF_MAX_RESETS_REACHED. These three resets have to be within a period of 100 hours.
Conditions:
If a card is getting reset continuously because of some SW/HW error in the card.
Workaround:
Reset the card by using cli command resetCd <slotNo> for that card.
S2 Bugs
CSCdp73120
Symptom:
When adding asymmetric connections, meaning local traffic parameters are different from remote traffic parameters, AXSM card doesn't handle it correctly. Inconsistent traffic load info will be seem be doing dsppnportrsrc.
Condition:
This is because in AXSM card, resource manager doesn't support asymmetric connections, all connections are assume symmetric, and only egress side traffic parameters are being used.
Workaround:
None
CSCdr50497
Symptoms:
dspsct command does not display proper information.
Conditions:
dspsct to display content of an SCT file in PXM Disk.
Workaround:
If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.
CSCdr71440
Symptoms:
Currently, if a SHM/CTC message protocol timeout occur, only an error is logged. The card will eventually be reset. The timeout for this may be up to 1.5 hours. If the protocol error occurred during a node power up against an AXSM card, the AXSM will be stuck in the INIT state; in addition, the STANDBY PXM card may be affected by this, and may get stuck in the INIT state also.
Condition:
The SHM/CTC message protocol timeout error can be triggered every time there is a communication between the PXM card and any other cards (this is a rare problem.) Typical activity that triggers communication between the SHM(active PXM) and the CTC (any card) are: a) node powering up/reset b) card powering up/reset c) card switches
Workaround:
If a SHM/CTC message protocol timeout error is seen in the log, and the card seems to be stuck in some state (e.g. INIT), reset the stuck card manually using the resetcd command.
CScdr74604
Symptom:
On one of the nodes in a devtest network, a few connections were reporting an egress AIS alarm even though the connection was perfectly passing traffic. This gave a false impression of failure to the user.
Condition:
The exact condition under which this happened is unknown. Workaround:
None.
CSCdr74850
Symptom:
Trap managers don't see any trap for PXMs switch over.
Condition:
PXMs switch over trap is sent too early when newly active card is not fully up so the trap is lost.
Workaround:
None
CSCdr75239
Symptoms:
During the powering up of a standby PXM, the disk is marked "disk not ready" temporarily while the disk sync is being performed. During this time, the Disk Not Ready alarm is reported under the slot alarm category. There is also an alarm category called disk alarms which is not being utilized at the moment. Thus the disk alarms count is shown as zero.
Condition:
Powering up a standby card.
Workaround:
When there is a slot alarm, run dspcds/dspcd to show the specific alarm which could be a disk alarm.
CSCdr75434
Symptoms:
Some SPVCs will appear as failed even though the connections are active
Conditions:
This condition will happen when AXSM Switchover is preceded by a trunk LOS causing reroutes.
Workaround:
None.
CSCdr77408
Symptoms:
uni or nni port state goes up and down intermittently.
Conditions:
Problem occurs on any uni or nni port in the axsm card. Problem occurs more often if the card is running at full card bandwidth.
Workaround:
None.
CSCdr77525
Symptom:
To reproduce this problem,
1. add a partition, and pxm cli> cnfpnportcac port-id cbr -minbw 50 axsm sh> rmPartDtlInfoShow.
2. axsm cli> cnfpart.... -emin 100000
3. axsm sh>rmPartDtlInfoShow will shows the interface policy info in each cos has been reset to wrong values.
Condition:
Currently, cnfpart only apply recorded interface policy percentage to each cos, without recalculating the maxbw, and maxvc
, based on how much minbw, minvc has been taken for certain cases.
Workaround:
Don't config interface policy minbw.
CSCdr82076
Symptom:
dspcdalms command does not break after 24 lines to give user an option to either continue display or quit.
Condition:
This happens only when there are more than 6 AXSM cards on the shelf that could cause the display to be more than 24 lines
Workaround:
None
CSCdr85279
Symptoms:
SVC connection is constantly torn down and rebuilt. This causes intermittent outages between node and CWM.
Condition:
SVC connection to router used for IP Connectivity.
Workaround:
None
CSCdr86184
Symptom:
Applications complaining about IPC message allocation failures due to IPC message leak.
Condition:
Applications calling IPC send function with lcn = 0 erroneously.
Workaround:
None
CSCdr86324
Symptoms:
Standby card will be waiting in Init state
Condition:
If any AXSM card in the shelf is waiting indefinitely in Init state, the standby PXM cannot come up.
Workaround:
Reset AXSM card. This will bring up the standby PXM.
CSCdr86680
Symptoms:
Event log entries indicating IPCONN could not send message to vcid 0.
Condition:
SVC connection to router used for IP Connectivity.
Workaround:
Issue reset of SVC using svcifconfig command svcifconfig atm0 router xxxx reset
CSCdr89700
Symptom:
When dspswalms/dspslotalms commands are used to display alarms, displays are inconsistent when there are alarms present compared to when they aren't present.
Conditions:
The inconsistency exists only happens only when an alarm of each
alarm type (displayed when there are no alarms in the system) isn't present.
Workaround:
None
CSCdr90786
Symptom:
When a Primary Clock Source is intentionally deleted with the delclksrc command a clock alarm is reported by the dspndalms and the dspclkalms command that states that the Primary clock source is lost.
Conditions:
This symptom will occur when a Primary clock source is intentionally deleted with the delclksrc command.
(If a primary clock source is lost i.e becomes unlockable or has loss if signal; without user intervention then this alarm is reported as expected and that symptom is not an error)
Workaround:
None.
CSCdr91277
Symptom:
A redundancy-deleted trap is sent with secondary slot number set to zero.
Condition:
This problem occurs after deleting redundancy
Workaround:
None
CSCdr93427
Symptoms:
The Cross bar status displayed by the command dspxbarstatus does not reflect the correct status.
Conditions:
This symptom occurs when errors are detected on a XM60 Card.
Workaround:
None.
CSCdr93676
Symptom:
getone on an instance of caviStatEgressTable object does not return the value.
Condition:
Happens when you try to get the value of a single instance of statistics table of any virtual interface.
Workaround:
Use getmany to get the value.
CSCdr94049
Symptom:
The message "Function ssiTaskDelay called by ISR." may appear in the dsplog output.
Condition:
Using CTL-C is used to exit from a CLI lkup command.
Workaround:
Do not use CTL-C to exit the "lkup" command. Use "Q" instead.
CSCdr94469
Symptom:
Message Of IPC Allocation failure seen on the console
Condition:
When we have upgrades going on with many AXSMs and at the same time we have many connections.
WorkAround:
Wait until all the AXSMs come up.
CSCdr94654
Symptom:
Event log messages are not generated.
Condition:
Executing dncon/dnport commands causes the problem.
Workaround:
None.
CSCdr96243
Conditions:
(1) Created 100 ports using addcon.
(2) Did a dnpnport on each of the ports.
(3) Changed the signalling vpi and vci for each port using the following: cnfpnportsig <port-id> -vpi 10 -sigVci 32
The cnfpnportsig command causes a warning to be printed for each port as follows: "** Warning: Signalling VPI IS OUTSIDE OF THE VPI RANGE IT OWNS"
Symptoms:
After about 75 (out of the 100) ports issued the above error message, PXM would temporarily lock up (for about 40 sec) and then continue.
Workaround:
Do not change the signalling vpi to the value which is outside the vpi range it owns
CSCdr97659
Symptom:
For a Service Module that supports master agent/subagent agent architecture, its subagent MIBs need to be un-registered from the master agent when it is removed, reset, failed, switchredcc, etc. Otherwise, MIB walk will hang/timeout since the master agent sees the registered subagent MIBs and continue to send requests to a Service Module that may be physically removed, failed, or rebooted/reset and did not come back up successfully.
Condition:
When a Service Module is physically removed, failed, "addred", "switchredcd", or "resetcd" command is run from CLI, or "reboot" command is run from shell.
Workaround:
None.
CSCdr97665
Symptom:
Failure condition for addred/delred from CWM will always indicate a general error.
Conditions:
CWM used to delred/addred on the node A failure condition occurs for the command from CWM
Workaround:
None.
CSCdr99149
Symptom:
Frame discard field comes as 0 when it is disabled. It should be 2.
Condition:
Problem occurs when FrameDiscard is disabled.
Workaround:
None.
CSCds01843
Symptom:
Link goes down and up when ilmi is enabled in IISP
Conditions:
Two mgx connected via trunk with configuration as IISP and ILMI is enabled in both side.
Workaround:
Disable ILMI.
CSCds02379
Symptom:
After a setrev or a soft reset, a NOVRAM will be corrupted. The specific symptom is a failure of the checksum verification.
Condition:
This problem will occur on rare occasions after a setrev was issued to a node full of AXSM Service Modules. Perhaps one in 60 will fail.
Workaround:
None:
CSCds03654
Symptom:
When the networking controller NAKs a connection provisioning request (due to lack of resources/invalid parameters), the proper error string is not presented to the user. This happens only when using the CWM.
Condition:
Caused by a failure in the translation routine which converts the internal error codes to a string that the CWM understands.
Workaround:
None.
CSCds03787
Symptom:
User can't modify cdvt of slave endpoint of dax con. Also, in the case of popeye2 node, when user modifies cdvt of master endpoint of dax con, the slave endpoint then is assigned cdvt = -1.
Condition:
Dax con endpoints only.
Workaround:
None.
CSCds03927
Symptom:
setrev causes a card reset regardless of card state when the command is issued at the CLI prompt. Card will become unusable during the burnboot since the flash is corrupted.
Conditions:
"burnboot" command is in progress at a service module slot
"setrev" command is issued before the card is ready
Workaround:
Make sure the flash is updated with the correct boot and the card is ready before doing a setrev on the card.
CSCds03954
Symptom:
When user enters the command "dspvsicons -cksm 0" the CLI task would take an exception.
Condition:
Caused by entering the above CLI command.
Workaround:
Do not use the -cksm option of the CLI command dspvsicons.
CSCds04883
Conditions:
Whenever an APS trap number 60124, 60125
Symptoms:
The trap oid for cwIfIndex is wrong.
Workaround:
None
CSCds05071
Symptom:
MIB Requests(Get,Set, Get-next) comeback with NO SUCH INSTANCE error.
Condition:
At least 13 subagents to be supported in the MGX8850 R2 shelf. However found that we support only 12(a bug) subagents at any point of time. If there are 12 standalone AXSMs in the shelf, then the registration of the last subagent (not necessarily the last slot) will result in error and the MIB Objects for the last subagent will result in errors.
Workaround:
None
CSCds06500
Symptom:
1. When adding signalling channel, ingress ecr is not calculated.
2. After change booking factor, only ingress card load changes, ingress part load stay the same.
Condition:
1. Adding a new service type for signalling channel caused the problem, on ingress side, one case statement was missing for calculating ecr.
2. It was decided not to apply booking factor to ingress side, after some discussion, we decided to apply booking factor to both sides.
Workaround:
1. None.
2. in shell command line, does sh> VrmEnbIgrCosCac(), will turn on ingress booking factor applying.
CSCds07835
Symptom:
OC12 card result in wrong cell delineation because of the wrong C2 byte configuration.
Condition:
C2 byte was configured with default 01h which does not say the signal contain ATM payload.Now default is changed to 13h(ATM payload).
Workaround:
None
CSCds09194
Symptoms:
If tstdelay is not successful for a given connection, then all subsequent attempts for performing tstdelay on that connection will fail with the reason "test in progress".
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) Perform a tstdelay on the connection.
(4) If the tstdelay is not successful, then the result will discontinue in "test in progress" mode. Consequently, any subsequent attempts will fail for that reason.
Workaround:
None
CSCds09375
Condition:
Error threshold time is zero. This can be caused by a corrupted database. User can also use cnfxbarerrthresh to intentionally set the error threshold time to zero.
Symptom:
When pulling out an active AXSM, PXM goes into reset
Workaround:
Do not set error threshold time to zero.
CSCds10319
Symptom:
There was buffer overflow in one of trace messages. if the attachment point change doesn't happen, then ilmiTask will be fine. The ilmiTask fails only when it tries to print an error message.
Workaround:
None.
CSCds10564
Symptom:
When connections enter into "mismatch" state on the AXSM, alarm traps are generated to the CWM to indicate this. Also an alarm file on the card should be updated to indicate this failure condition. This did not happen.
Condition:
"mismatch" Condition can be created by turning off the segment endpoint using command "cnfoamsegep" on the PXM45. After this, if the AXSM were to be rebooted all the persistent endpoints on the card would enter into mismatch state. Now, if the alarm file is uploaded and parsed, it would indicate no alarms on the card.
Workaround:
None.
CSCds11187
Symptom:
Operational status of Protection line is not displayed correctly
Condition:
The problem has been fixed.
Workaround:
None
CSCds13606
Symptom:
SSI event logged as EVENT_ERROR with stack trace of event.
Condition:
When VC manager retries for control VC fails for any reason.
Workaround:
None
CSCds13978
Symptom:
dspcd and dspcds show a card is in failed state but no alarm is raised.
Conditions:
Whenever a card is moved to failed state.
Workaround:
None.
CSCds14777
Symptoms:
Update port sig parameters when the port status is up, it will cause the inconsistence in information display between the dsppnport and dsppnportsig.
Conditions:
The port status is up.
Workaround:
Do not do the cnfportsig command, when the port status is up.
CSCds16773
Symptom:
Standby PXM45 fails to come up after a PXM switchover or new Standby PXM45 insertion.
Condition:
The disk synchronization on Standby PXM45 may fail when, an one or more AXSMs are also coming up at the same time and they are taking longer time due to burning the image onto the flash.
Workaround:
Reset the Standby PXM45 from Active PXM45 using 'resetcd' one more time.
CSCds18258
Symptoms:
Some connections are not able to reroute, reroute is not even being attempted; i.e. connections are not routed.
Condition:
Cables are pulled off at master and via nodes. Reconnect the cables but connections are not routed.
Work Around:
None
CSCds19129
Symptom:
Calls with AAL parameter IE octet 12.1 (i.e. partially filled cells method) set to 0 are rejected.
Condition:
As per UNI 3.1 page 201 - AAL parameter IE octet 12.1 partially filled cells method range is 0x01-0x2F. However, in the case of non-compliance equipment, octet 12.1 is set to 0.
Work Around:
None.
CSCds22540
Symptoms:
When performing SPVC reroute and switchover the UNI (master side) at the same time, connection delete may fail on the standby. After switchover, if the same connection is recommitted, VSIErr will be observed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on one of the NNI on NODE_VIA.
(4) switchredcd on the UNI (master side of the connection) on NODE_EP1.
(5) When everything is rerouted, perform a switchredcd on the same UNI. Sometime later, some VsiErr are observed on the AXSM console.
Workaround:
Do not perform switchover while rerouting/derouting connections.
CSCds22868
Symptom:
Provision spvcs through an IISP link. On repeated setup and release of spvcs, it was noticed that the user side IISP had some connection data structures which were not getting cleared when the call was released.
Condition:
The problem was been identified as a user state machine error. It will surface in a rare scenario where the sscop link is down while trying to release the active call in the state u10.
Workaround:
The problem will not surface so long as the sscop link is up.
Problems Fixed in Release 2.0.02
Bug ID
Description
S1 Bugs
CSCdr22185
Symptom:
VsiErr message with a string explaining the error such as
"Interslave timeout" and others get displayed; these messages
are indications of a recoverable condition and are not
meant to be displayed.
Conditions:
These messages can show up when the system is under stress, such
as on system rebuild, and VsiErr due to real errors are meant
to be displayed, but instead warning VsiErrs are displayed
Workaround:
None
CSCdr23168
Symptom:
Resetting the AXSM UNI card in the edge node while the PNNI is establishing connections on it might intermittently cause the tVsiSlave task to crash on the AXSM UNI when it eventually comes up.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset NODE_EP1.
(6) While SPVCs are being established (about 15K), reset the AXSM UNI card.
(7) After the AXSM has come up, a lot of VsiErrs are observed, and then the tVsiSlave task crashed.
Workaround:
(1) Do not reset the UNI AXSM while the PNNI is rebuilding the connections.
CSCdr27919
Symptoms:
Performing PXM45 switchover while derouting 25k SPVCs by downing one of the nni port in the edge node might intermittently
cause a lot of vsierrs (0xcoo3, 0x5011...etc) to be displayed on the corresponding UNI AXSM on the same node, and may even
cause its tVsiSlave task to stop working which may results system reload.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE
_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) down one of the two NNI trunk on NODE_EP1.
(6) While SPVCs are being established (about 15K), reset the active PXM card on NODE_EP1 to cause a PXM switchover.
(7) On the UNI AXSM, a lot of VsiErrs are observed, and then the tVsiSlave task stopped working causing a system reload.
Workaround:
(1) Do not perform PXM switchover while the PNNI is rebuilding the connections.
CSCdr34387
Symptom:
A few SPVCs are not seen after resetsys. Not all SPVCs on any one interface have been lost.
Condition:
Happens when a node is fully loaded to 50K connection capacity.
WorkAround:
Avoid connection addition during heavy connection re-routing, link status changes.
After the problem has occurred - SPVCs can be re-added.
CSCdr36772
Symptom:
Bucket statistics file name has incorrect file name.
Conditions:
Suppose the file is created at 5:30 it will have a time of 5:15. The interval is 15 to 30 min. This means that the beginning time is used instead of the ending time.
WorkAround:
None.
CSCdr36954
Symptom:
VC Failure due to insufficient LCNs used up by the user conns. The port stays in VC failure forever.
Conditions:
When more SPVCs are provisioned than the available LCNs, the port could go into VC failure upon few resets on the controller or the Slaves. This happens because of failure conditions to establish connections and if user connections could be established before the control VC connections.
Workaround:
Never provision more than the available LCNs.
CSCdr37025
Symptom:
Some of the provisioning command operation does not get reflected on standby and disk.
Condition:
When there are many spvcs are getting added/deleted/modified within a very short period of time and also at the same time many ports status is oscillating between up and down in that case this may happen.
Work Around:
When port status is oscillating, do not add/mpdify/delete spvcs on it.
CSCdr37302
Symptom:
Unable to ping/telnet to the node intermittently.
Conditions:
This problem occurs in a redundant PXM node. When ping the node from a workstation, the ifShow command shows that the receiving packet counts is incrementing while the send packet counts remains the same.
Workaround:
Reconfigure the interface with the same IP address again using command
CSCdr38809
Symptom:
After restoring the configuration using restoreallcnf command, and controller card switchover happened, the some of the SPVC end points may be missing and/or the attributes of some of the VCs may be changed.
Condition:
When restoreallcnf is performed, the configuration on the disk is overwritten by the restored configuration on the Active controller card and the configuration needs to be cleared on the Standby controller card before it could synchronize the configuration with that on the Active controller card. This clearing of configuration on the Standby controller card is not done as a part of restoreallcnf. This causes the problem.
Workaround:
You need to clear the configuration using clrallcnf before restoring the configuration. You should make sure that the Standby controller card is in operational state when configuration is cleared. If the Standby controller card is not in operational state when clrallcnf was performed on the node, you should clear the configuration on the Standby controller card when the card is in the boot state using sysClrallcnf command.
CSCdr39120
Symptom:
Reset of AXSM cards and switchover will cause SPVC to reroute.
Condition:
When ILMI is turned on the AXSM, when reset the Peer ILMI module will trigger a Loss of Connectivity and all the calls on the interface will be derouted.
Workaround:
If Using Orion 1.0.x or P-II 2.0.x, disabling the Securelink procedures will not allow the calls to be derouted (cnfilmiproto command can be used to turn off Secure link on a port basis). If not using the above, there is no workaround as secure link is enabled on NNI/UNI links.
pxm1Cli> cnfilmiproto <portid> -securelink no
- turns off the securelink on the NNI trunks. By default its turned on for all the interfaces.
CSCdr40126
Symptom:
If there are more than 31K connections on a single AXSM in a VIA node, the connections on the AXSM are not deleted when PNNI deroute the connection.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 31K+ SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Down either of the trunk connecting either NODE_EP1 or NODE_EP2 to the NODE_VIA to cause connections deroute. After the deroute completes, it was observed that the connections in the NODE_VIA are not deleted, and no error were observed.
Workaround:
(1) Restrict the number of connections on the NODE_VIA to less than 31K. This can be done by configuring the partitions for NNI trunks on the NODE_VIA to support less than 31k connections (combined).
CSCdr40620
Symptom:
NO SPVCS. After PXM rebuild some interfaces might disappear.
WITH SPVCS Every time PXM card (both cards in case of redundancy) is rebooted, Node cannot come up. pnRedman may be in exception.
Condition:
If any image built between Apr 21, 2000 & Apr 29, 2000 had been used in a node, then there is a possibility for data base corruption, which will lead to this problem.
Workaround:
No workaround.
CSCdr43586
Symptoms:
'ssiIpcMessageAllocate fails' appears on screen periodically.
Conditions:
a. copychans/delchans b. pull out the high speed trunk. For example, we have lot of connection routed over OC3. If we pull out OC3, all the routed conns on OC3 need to be rerouted on, say, T3/E3
Workaround:
1. Avoid using copychans/delchans 2. program the SSCOP signalling channels with higher values of PCR/SCR/MBS. Use cnfpnctlvc to change the default values.
CSCdr43665
Symptom:
The call does not routing with VPI/VCI assignment error.
Condition:
When you have big number of calls (around 16K) in one interfaces and switch-over.
Workaround:
Do not do switch-over when call is in progress and # of calls is around 16K.
CSCdr45695
Symptom:
Could not run "dspln", dspports, etc. Could not walk mib tables.
Conditions:
The "dsplog" CLI output might contain following message:
01-00127 05/12/2000-11:14:26 MIBS-4-SEMTAKE_FAILED E:06412 snmpSA 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.
tSmCmdTskcl: doMibTbls(): Can't get resrc semaphore.: Err from snmpMibSemTake 01-00104 05/12/2000-09:21:54 MIBS-4-SEMTAKE_FAILED E:06409 tSmCmdTskc 0x8012a2f8 snmpMibSemTake_104: Semaphore Take failed for singleThrMibFuncSem, return value 0xfffffffe.
Work around:
The Card which has this problem (dsplog -sl <x> has the above message) will have to be reset.
CSCdr46104
Symptom:
Exception in pnCcb task causing the active processor to
reset.
Condition:
Observed on derouting and rerouting SPVCs over an IISP link.
Workaround:
None.
CSCdr47782
Symptom:
Standby PXM reloads
Condition:
When there is too much traffic going on to standby from Active, sometimes connection path gets congested and it may take more than 5 sec.
WorkAround:
None
CSCdr47834
Symptom:
Connection add / delete problems when number or connections is around
30,000+. Possible error message includes, delete failure, non-existing ConnID entry.
Condition:
This problem exists only when the number of connections gets to be around 30,000 or greater.
Workaround:
None
CSCdr47947
Symptom:
After resetting the AXSM (UNI) card in endnode, and performed pxm45 switchover while the port is still in down in progress, once the AXSM card is up, and all uni ports are in "up" state, vsi error 0x502a (connection reserve failure) are observed.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset the UNI card in NODE_EP1.
(6) While the port is in "down in progress" state, perform pxm45 switchover.
(7) VsiErr 0x5017 are observed once the UNI AXSM card is up and all UNI ports are in "up" state.
Workaround:
One of the following: (1) Do not perform pxm45 switchover while any of the UNI port is in "down in progress" state. (2) If the failure has already occured, rectify this problem by resetting the UNI card.
CSCdr50312
Symptom:
Standby card will be reset and come back in the higher revision (2.0(1))
The card will then transition to the failed state.
Conditions:
Upgrading gracefully (through the loadrev command) on the PXM with
redundancy available (2 PXMs in the node) between release 2.0(0) and 2.0(1)
Workaround:
Do a non-graceful upgrade by using the setrev command
This will cause the PXMs to be reset and come back in the higher revision
setrev 7 2.0(1)
CSCdr55652
Symptom:
provision the SPVC, the conn is ok but the cell dropped.
Condition:
The SPVC percent util was applied to FWD EP bandwidth and that made the pcr to be 0. This caused the dropping cells.
Workaround:
None
CSCdr56267
Symptom:
Standby PXM45 waits indefinitely in INIT state.
Condition:
Intermittent. Occurs when inserting the standby PXM45 card.
Workaround:
None
CSCdr61082
Symptom:
The applications on Active PXM45 fail to communicate with other
applications on the same card and other cards due to lack of IPC
message buffers.
Condition:
This problem occurs on error conditions like failure of a node,
causes PNNI to report errors (with no throttling) to SHM results in
exhausting the error buffers which in turn results in exhausting
the IPC buffers due to buffer leak.
Workaround:
Reboot the PXM45 card.
CSCdr61204
Symptom:
dspcds will show that the card is in the BOOT state.
Condition:
Card Bringup will sometime get stuck in the BOOT state because a bringup message being sent to the card is lost.
Workaround:
If the card is stuck in the BOOT state, reset the card manually.
CSCdr67620
Symptom:
Intermittently, AXSM cards will get reset due to MCAST_MSG_LOSS.
Condition:
On a fully populated POPEYE2 node when restoreallcnf is performed or when there is a lot of activity during the system bringup.
Workaround:
None
CSCdr71695
Symptom:
Node and card redundancy configuration is lost.
Condition:
Insert a standby PXM45 into a node with a failed active PXM45 can result in the lost of the database on the standby PXM45 card.
Workaround:
Do not insert a standby PXM into a node whose active PXM is already in the failed state (use dspcds on the active PXM to show the card state before inserting the standby PXM.) Remove the failed active PXM before inserting the new standby PXM.
CSCdr73806
Symptom:
dspcds and many other CLI commands will not work.
Condition:
After a long period of time, the PXM45/AXSM cards run out of IPC buffer memory.
Workaround:
Switchcc
CSCdr75500
Symptoms:
SPVCs will fail to route.
Conditions:
This condition will happen when some connections are deleted and a switchover is followed by that.
Workaround:
None
CScdr78831
Symptom:
After clrallcnf, access to the node via TCP/IP makes connection to the standby card rather than the active.
Condition:
Redundant PXM45 configuration using ethernet access for IP connectivity. Boot IP addresses of the PXM45 as well as disk IP address are the same.
Workaround:
Reconfigure boot IP addresses of the PXM45 cards to be unique.
CSCdr80279
Symptom:
When a VPC connection is added a connection add trap is sent to the CWM. In this trap a MIB object cwaChanVpcFlag is set to indicate if the connection is a VPC or a VCC. This was erroneously set to indicate VCC instead of a VPC.
Condition:
All connection related traps (add/del/modify/down/up/fail) carried the wrong encoding of the cwaChanVpcFlag for VPC connections.
Workaround:
None.
CSCdr80807
Symptom:
System restarts.
Condition:
Provision 50K SPVC routed connections. In the source node perform the following: - dnpnport <trunk or port> - wait for the connections to be released. When connection are being re-routed, perform uppnport.
Condition:
Workaround:
Disable internal audit by using the CLI command "actaudit disable".
CSCdr82611
Symptom:
When a large number of endpoints are provisioned and if all of them had stats collection enabled, then it is impossible to login or cc to the AXSM card.
Condition:
This was caused by the conn. stats task hogging the CPU time while collecting stats on all those connections. The basic problem was narrowed down to an inefficient search algorithm in the code.
Workaround:
Do not enable stats on connections, without a fix for this bug. The fix involved correcting the inefficient algorithm and reducing the priority of the stats collection task, so that the control point applications can run.
CSCdr82868
Symptom:
IP connectivity cannot be established and remains in SETUP state.
Condition:
If the IP AESA address does not match with the pnni node prefix (the default summary address), the svc connection cannot be established.
Workaround:
Configure the IP AESA address to match the pnni node prefix.
CSCdr85316
Symptom:
IP connectivity setup fails with cause ATM_CAUSE_VPCI_UNAVAIL (35).
Condition:
This happens only within a very small window during PXM switchover. If a RELEASE is received from the link before an application re-listens (registers the address with sigap) on the newly active PXM, the RELEASE would fail and the connection resources would not be freed properly. Therefore, subsequent SETUPs would fail because the vpci is still in use.
Workaround:
None.
CSCdr87319
Symptoms:
PNNI Link might occasionally go down or remain in oneWayInside/Attempt state. Connections may reroute on any other available trunk or stay derouted in case no other trunk is available.
Conditions:
Large number of ports configured on the system or high bandwidth data traffic on OC48 cards have shown symptoms like this.
Workaround:
None
S2 BUGS
CSCdr25037
Symptom:
Many [vsierr] messages and [egress ConnID add failure] messages are reported by the trunk card on NODE_EP1 while the rebooted UNI card does NOT have error messages.
Conditions:
In a three-node network with two nodes (NODE_EP1 & NODE_EP2) connected directly as well as via a third node (NODE_VIA), approximately 5000 SPVCs are added between NODE_EP1 and NODE_EP2.
All of these AXSM cards operate in stand-alone (e.g., non-redundant) mode.
The UNI card in NODE_EP1 is rebooted (by resetcd from PXM45 or ESC-CTRL-X).
Immediately after the PXM45 console reports the insertion of the UNI-AXSM, a [switchcc] command is issued.
Workaround:
One of the following: (1) Do not [switchcc] at all. (2) Do not [switchcc] until the rebooted UNI-card is burning the flash (by observing a few cycles of [burning xxxxx verify... ok] messages) (3) If the failure has already occured, rectify this problem by doing [resetsys] on every PXM45 in the network.
CSCdr27033
Symptom:
Clock source does not revert back to primary bits clock when revertive mode enabled. This can also appear in the form that clock is not switched to a valid clock source that should have a good clock signal.
What is really the case is that the clock source has been previously declared as unusable/unlockable by the clock source manager. This clock source will not be chosen again until after clock source reconfiguration.
Condition:
The clock source manager is the traffic cop for maintaining the correct/best clock source and managing the state of all clock sources. To make sure that the current clock source is valid, frequency and phase error tests are continuously run on the clock source. Should there ever be a sample that shows invalid frequency or phase error, the clock source is placed into "out of lock" state and a more intensive test is done on the clock source. If this intensive test shows enough failure, the clock source is declared unlockable.
To determine if a clock source has been labelled as unusable, there are two methods:
1. From shellconn issue command nclkm_status. Look for the MUXA/MUXB "programmed as" lines of the display. If the source is programmed as "TOP SRM", it has been labelled as unusable.
2. From shellconn issue command dspclockinfo. If clock source is configured but programmed to NULL, then it is labelled as unusable. (NOTE: This display is in the process of change to be more clear about this special clock source state.)
Workaround:
Reconfigure the clock source, even if it is to the same exact configuration to clear the unlockable state. Use cnfclksrc command.
CSCdr27718
Symptom:
The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.
Conditions:
When an UNI/NNI interface is configured on the Line card.
Workaround:
If the problem persists for sometime, bring the interface administratively down and then administratively UP.
CSCdr28033
Symptoms:
When performing dnpnport on a certain ports with SPVC connections which has stats enabled, some dal/stats error are observed on the UNI AXSM side.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NOD
E_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are some SPVCs with stats enabled between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through
two trunks.
(5) Perform dnpnports on a certain ports. Some error message are being displayed on the AXSM console.
Workaround:
None.
CSCdr28767
Symptom:
The SSCOP, PNNI protocol states would not be in Established state, two-way inside respectively. The protocol PDUs will be discarded at SAR level.
Conditions:
When an UNI/NNI interface is configured on the Line card.
Workaround:
If the problem persists for sometime, bring the interface administratively down and then administratively UP
CSCdr29013
Symptom:
Much lower via node reroute rate when attempting to reroute SPVCs at a higher call rate than nodal setup msg congestion threshold value.
Condition:
When massive SPVCs are being rerouted because of resetting some nodes in the network or when trying to setup SVC connections at a very high call rate.
Workaround:
Try not to exceed call setup rate of 100calls/sec for SVCs or SPVC reroute at this stage.
Additional Information:
Root cause of the problem has already been identified; with the fix, call setup acceptance rate is going to be stabilized around the nodal setup msg congestion threshold, not going to drop dramatically when call attempting rate goes higher.
CSCdr32624
Symptoms:
Any operation involved in file creation or file opening on the Active controller card will start failing continuously.
Conditions:
The repeated upload of configuration results in file descriptor leaking.
Workaround:
You must reset the Active controller card.
CSCdr34225
Symptom:
Cell drops are noticed on OC3 with default line rate.
Conditions:
The line rate specified for OC3 is 353208 cells/sec. But, in fact it is 353207.55 cells/sec. So cell drops are noticed if traffic is pumped in at 353208 cells/sec.
Workaround:
Use following rates(cells/sec)as max line rate for: Max rate for OC3: 353207 Max rate for OC12: TBD Max rate for T3 and E3: TBD Max rate for oc48:
CSCdr34707
Symptom:
Calls will not go through.
Condition:
The address PTSE is present in the database but the address is not present in the network reachable address table.
WorkAround:
None.
CSCdr34851
Symptom:
After addpart with incorrect parameters, the partition gets added on AXSM, but dsppnports on PXM45 either doesn't show the port, or it shows the IF status as provisioning.
After delpart, dsppnports shows the IF status up for the port on the PXM45, although dspparts on the AXSM doesn't show the partition anymore. There is no error message displayed.
Conditions:
Two conditions seen in our lab that caused this problem: - clock configured on the line associated with the partition, delpart doesn't fail, but partition removed from the database, but PNNI doesn't get informed of partition delete - tried to add partition on a vnni port with incorrect vpi range, partition added to the database, but PNNI doesn't get informed of the partition add
Workaround:
Workaround after the conditions are seen is to do resetsys on PXM45.
CSCdr36903
Symptom:
ILMI fails to transition to a steady state and PNNI ports may not come up. As a calls might fail to route or use another available heathy trunk.
Conditions:
PXM switchover with ILMI enabled. If the ILMI protocol across the peer have not reached a steady state this problem has been noticed intermittently.
Workaround:
dnpnport and uppnport the affected port(s) after the switchover is complete.
CSCdr39329
Symptom:
Few connections will be in fail state at one end point (either master end or slave end)
Conditions:
This happens when a large number of connections are established and then some line cards are reset.
Workaround:
None
Additional Information:
If the problem persists, attempt reroute for the failed connections from CLI
CSCdr39684
Symptom:
Cannot display link selection configured on PNNI port.
Conditions:
ILMI (auto-config) is enabled on the port.
Workaround:
disable ILMI (auto-config) on PNNI port.
CSCdr39892
Symptom:
The symptoms of this problem is that all traffic that is coming into the axsm card is being discarded. Specifically, ingress traffic does not go into the switch planes and since the queues in the QE48 gets full, the incoming traffic reaches the maximum cell threshold and all cells are discarded.
Conditions:
This problem may occur if the axsm card experiences multiple (more than 32) switch plane errors. Switch plane errors such as lost of sync, code violation, crc error, disparity error. Since switch plane error may occur during pxm45 switch cc's, this problem may also occur during pxm45 switch cc's.
Workaround:
Reset the axsm card that is not passing traffic.
CSCdr40167
Symptom:
User see sometimes SPVC fail to route spvc connection on AXSM card resets
Condition:
Repeated AXSM card resets on the POPEYE2 node OR repeated BXM card resets on BPX node
Workaround:
none
CSCdr40333
Symptom:
User did not have the granularity to find out why the clock when bad.
Condition:
A clock can go bad due to excessive jitter, high frequency, etc.
Workaround:
User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
CSCdr40484
Symptom:
User did not have the granularity to find out why the clock when bad.
Condition:
A clock can go bad due to excessive jitter, high frequency, etc.
Workaround:
User would have to go to the clock source and verify functionality with the source equipment to find out the reason.
CSCdr40821
Symptom:
Some SPVC conns are in AIS-FAIL in standby
Conditions:
a. resedcd (PXM or BXM) b. dnpnport/uppnport (PNNI trunk) c. rebooting via nodes
Workaround:
switchcc the PXM.
CSCdr41012
Symptom:
Ports go to Down in Progress after Reset/Downing the AXSM. This is due to failure to resync the connections.
Conditions:
When large number of connections are to be resynced after a line card recovery, the control connections (signalling and routing) fails to be reinserted.
Workaround:
None.
CSCdr41170
Symptom:
After changing T3 line framing mode from ADM to PLCP, continuous vsi error messages are reported on ASXM.
Conditions:
Existing connections have used up all bandwidth corresponding to ADM framing mode (104268 cps).
Workaround:
When T3 framing mode is changed, check if the new line type cell rate is less than the SG rate sum of existing SG belonging to the line. If so, reject the command.
CSCdr41708
Symptom:
After the switchover, the new active Pxm still shows that the above inserted backcard is still missing. This will eventually cause an extra switchover when a healthier standby Pxm is ready.
Conditions:
If inserting a backcard into the standby Pxm's slot resulted in making the standby Pxm the healthier card, the standby Pxm will be made that active Pxm.
Workaround:
If backcards on both Pxms are missing/bad, always replace/insert the backcard on the active Pxm first. This will not trigger the above switchover and bug.
CSCdr42075
Symptom:
port(s) in "vc failure"
Conditions:
Have svc calls, with active and standby pxm. Pull the active
pxm and reset card, causing switchover.
Workaround:
None.
CSCdr43945
Symptom:
One can exceed the peak cell rate up to line rate thereby starving all resources to other connections. This is due to the fact that OAM and RM cells do not get policed.
Conditions:
Add a connection and pump non-user-data cells e.g OAM/RM cells using a tester or CPE.
Workaround:
For policing compliance test use User data cells only.
CSCdr44255
Symptom:
Svc call on uni port getting released.
Conditions:
Make a svc call on uni(3.0/3.1) port using a tester. Pullout and put back the cable between the node and tester within 10sec(T309).
Workaround:
This problem occurs alternately. There is no work around yet.
CSCdr44537
Symptom:
The connection does not pass the data traffic.
Condition:
The UBR SPVC provisioned with PCR=0 and resync happened.
Workaround:
Do not provision pcr=0. Reactivate the connection using dncon/upcon command.
CSCdr44566
Symptom:
Dax connections are in FAIL state
Condition:
Did a resetsys on the PXM
Workaround:
Check the endpoint interface, do a dnpnport and uppnport on those interfaces, the connection should be in ok state
CSCdr44741
Symptom:
An unsupported card will stay in the Boot state, and the standby Pxm will stay in the Init state.
Condition:
Insert an unsupported card or a card with an invalid novram id into the node, then insert or reset the standby pxm card.
Workaround:
Remove the unsupported card from the card, or program the correct Novram Id onto that card.
CSCdr45063
Symptom:
The address or address prefix associated with a PNNI node at a lowest level peer group, if not summarized by any of the default or configured summary address, may sometimes be failed to be advertised across the peer group boundary even when its advertising scope is wide enough.
Conditions:
Assuming a hierarchical PNNI network originally works fine with an address A that associated with a node N at the lowest level, and A is seen as advertised across the peer group boundary just fine. Reboot the node N and A may be missing across the peer group boundary, when the identifier of the address PTSE for A differs from the one before the reboot.
Workaround:
The root of the problem has been found and a fix has been put in and verified as a correct resolution.
In this fix, the PTSE ID is now stored in the local reachable address Trie of a LGN, along with the node index of the node at the child peer group. As such, the identification of a given entry in the local reachable address Trie includes both the node index of the node and the PTSE ID at the child peer group. Note this handling is the same as already existed for network reachable address Trie.
CSCdr45896
Symptom:
1. The problem is not observable, but the problem can be identified/observed when the traffic parameters are verified by doing "dalConnParamsShow" after de-routing the connections from one trunk to another on a different card
Conditions:
1. 2 Node PNNI network 2. 2 AXSM trunks on 2 different cards 3. De-Route connections from one trunk to another trunk in another card
Workaround:
Don't de-route/re-route conns between trunks across trunks on different cards. Use multiple trunks if needed on the same card.
CSCdr45962
Symptom:
Some SPVC conns are in AIS-FAIL in active PXM after switchover
Conditions:
After multiple switchover of PXM
Workaround:
issue following command on shellconn of newly active PXM.
For example,
pxm1> conProEnableConnTrap conProEnableConnTrap
CSCdr46262
Symptom:
When switchover occurs, all the master / slave endpoints are attempted to route / half commit, and it will hit congestion, which will not recover dspnodalcongflags will show connpendingflg set to TRUE.
Condition:
1000s of non routed master / slave SPVCs are configured on a port which is operationally down. & switchover occurs.
Workaround:
Manual Switchover: Do not try switchover
Automatic Switchover: None
CSCdr46770
Symptom:
The clock is marked as unclockable.
Condition:
Once a clock source is locked, after a period of 12 hours, the clock goes into unlockable state.
Workaround:
Configure the clock source again, in order to trigger the software back to using the clock source.
CSCdr46945
Symptom:
The PNNI main task is looping when calling pnni_delete_db_ptse() for a horizontal link.
Conditions:
The PNNI main task loops infinitively in the function pnni_delete_db_ptse() when the PTSE deleted is a horizontal link.
Workarounds:
None
CSCdr47590
Symptom:
After Switchover Standby(newly active) doesn't have the same number of SPVCs as Active had before.
Condition:
When we have failure on AXSM or some port which has many thousands SPVC.
WorkAround:
None
CSCdr47916
Symptom:
Connection may not be routed on best path.
Conditions:
Routing table (SPT) may not contain best route with certain network topologies.
Workaround:
Use default AW on all pnni links, or disable routing table.
CSCdr47931
Symptom:
System allows calls to use VPI/VCI below the provisioned minimum value.
Condition:
n/a
Workaround:
Always set the minSvccVpi and minSvccVci to 0.
CSCdr48075
Symptom:
CWM has difficulty understanding the contents of a SNMP trap when retrieved from the RTM MIB.
Conditions:
The robust Trap Manager Mechanism support from an MGX8850 is not properly working. An additional internal data structure is being prepended to the SNMP Trap PDU.
Workaround:
There is no known workaround.
CSCdr49287
Symptom:
Connection resync will be stuck in one place and so connections will be mismatched between controller and slave
Condition:
All the slaves are inactive and few of them becomes active and resync starts and before it completes another resync starts.
Workaround:
None
CSCdr49592
Symptom:
A user adds a connection without specifying mbs/cdvt, this programs the hardware with values that are shown by dspmbsdft/dspcdvtdft. But when user does "dspcon", the value shown for both mbs/cdvt is -1.
Condition: No default is provided for mbs/cdvt in SCT tables.
Workaround:
If one wants the mbs/cdvt values programmed in hardware to be consistent with the values shown by "dspcon", workaround is to include defaults for mbs and cdvt in the SCT tables. Note that these defaults override those provided by cnfmbsdft/cnfcdvtdft.
CSCdr50477
Symptom:
The addcontroller command fails.
Condition:
The addcontroller command fails if the slot number being entered is not a logical slot number (e.g. logical slot number = primary slot number).
Workaround:
Supply the command with the logical/primary slot number. Run dspcds to see primary slot number.
CSCdr50497
Symptom:
dspsct command does not display proper information.
Conditions:
dspsct to display content of an SCT file in PXM Disk.
Workaround:
If the SCT is already applied to an active port/card, use dspcdsct or dspportsct command to display the contents of the sct. For the SCT files not applied to any port or card, there is no workaround available on MGX platform. Use CWM to display contents of such SCTs.
CSCdr51668
Symptoms:
1.switch gives status.14.0000000000000 as the response to
getnext request on netprefix
2.get negative number in ILMI PDUs from HP test
Conditions:
When running HP 3.0/3.1 ILMI Conformance Test Suite
Workaround:
1. no workaround for symptom 1
2. need to get HP patch for ILMI Conformance Test Suite to encode ILMI PDUs correctly
CSCdr52913
Symptom:
While the node is running, a couple of error messages are shown in the log. When Line Failure occurs, it was not identified by an easily understandable message, the line that failed was not printed.
Condition:
Unknown
Workaround:
None
CSCdr53438
Symptom:
cnfchan on slave dax con for cc enable, pnni controller doesn't send vsi msg to SM
Condition:
cnfchan on slave dax con doesn't take effect.
Workaround:
None
CSCdr53470
Symptoms:
SPVCs will fail to route.
Conditions:
Under rare conditions, when uni card fails during the same time as nni card reset and SPVC reroutes will cause this problem to happen.
Workaround:
None
CSCdr54146
Symptoms:
Calls will not get routed through the nodes in the network.
Conditions:
Under rare conditions when neighbor loses or drops PNNI routing messages the neighbor will remain in Exchanging state.
Workaround:
A dnpnport and uppnport will bring the link up and the neighbor state will move to Full state if there are no loss of PNNI routing messages.
CSCdr54798
Symptom:
When 2 mandatory events were sent to the children at the same time, the RAT only kept the last one.
Conditions:
Children of the rat got 2 new events that are the same.
Since they used the RAT structure to retrieve the message
Workaround:
There are no known workarounds for this problem.
CSCdr55821
Symptoms:
Certain connection will not establish. If you can trace the
signaling message, you'll see the switch received connect and sends status message with cause 100 (invalid IE contents).
Conditions:
When the connect message has end-to-end transit delay IE present
with either PNNI Acceptable Fwd CTDI or PNNI Cumulative Fwd CTDI.
Workaround:
Avoid end-to-end transit delay IE with those parameters
(PNNI Acceptable Fwd CTDI or PNNI Cumulative Fwd CTDI), in the setup message.
CSCdr55832
Symptoms:
See the following misleading messages: "+bad length+" and
"Send Status Enquiry"
Conditions:
When turn signaling packet debug on and received signaling
STATUS message or release messages with more than cause IE.
This is only a display error. There are no serious consequences.
Workaround:
None
CSCdr55928
Symptom:
AXSM STM1 card will not handle over 32K connections.
Condition: Only occurs with over 32K connections.
Workaround:
None
CSCdr56173
Symptom:
SPVP connection(s) are not allowed.
Condition:
Try to add SPVC with vci=0 gets rejected with the error message
"Specified vpi/vci not available".
Workaround:
None
CSCdr56897
Symptoms:
Resetting the UNI AXSM on the edge node of a three node network with 50K+ connections may cause the tVsiSlave task cpu utilization to go above 90% for a few seconds after it comes up.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE
_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 50K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through two trunks.
(5) Reset the UNI AXSM on NODE_EP2.
(6) After the UNI AXSM comes up, the tVsiSlave task CPU utilization may go above 90% for a few seconds.
Workaround:
(1) None.
CSCdr57071
Symptom:
Bad IPC messages detected caused by unreported SAR CRC errors.
Unexplained behavior or errors in the shelf.
Condition:
It is not clear that this error has ever happened, however hardware problems on the internal cell bus could cause this symptom.
Workaround:
None.
CSCdr57276
Symptoms:
SHM FAILURE ALERT message is displayed on the console
Condition:
If the PXM45 front card is replaced, user gets into this situation.
Additional information:
Show customer a copy of this message.
***************** SHM FAILURE ALERT *************************** * The PXM card has failed its PXM nativity check. The * PXM nativity check determines if the backplane serial * number recorded in the front card's BRAM or the * hard disk matches the local backplane serial number. * Please see MGX 8850 documentation for more information.
CSCdr58626
Symptom:
See a continuous Trap messages indicating IPC memory leaks.
Condition:
This doesn't happen always. sometimes when switch over happens we may see Vsi Error messages printed over the CLI.
workaround:
None
CSCdr59353
Symptom:
The dspclksrc command shows inaccurate clock information
Condition:
Unknown
Workaround:
None.
CSCdr59423
Symptom:
Switchcc results in clk switch to priority 0 msg.
Condition:
The priority 0 msg occurs when no clock sources are configured. This message does not effect the functionality of the node or the clock source on the node.
Workaround:
None.
CSCdr59709
Symptom:
No event logs when there is a PXM switchover.
Condition:
The problem occurs with PXM switchovers.
Workaround:
None
CSCdr60068
Symptom:
If a resetsys or a switchcc is preformed on the PXM, a
core dump would be preformed during the boot of the formerly active PXM card. When the core dump logs are observe the reason would be a device driver error.
Condition:
This would be seen if the core dump feature is turned on, and a resetsys or a switchcc is preformed.
Workaround:
A workaround would be to turn off the core dump for
the device errors. This is accomplished by using the core mask command:
At the cli enter: core mask
Take the current core mask at set the bit 0x20000 to zero.
For example if: The Current Core mask is 0x262ee
At the cli enter: core mask 0x062ee
CSCdr62126
Symptom:
clralmcnt doesn't clear LOS/LOF alarm counters.
Conditions:
When the link is broken, the red alarms like LOS and LOF is raised. dspalmcnt command shows all the alarms. clralmcnt command is used to restart the alarm counters. bug was LOF/LOS counters were not reset when clralmcnt command was issued. LOF/LOS counters were in fact showing only the history of line from the point axsm was booted and came up active.
workaround:
Reset the axsm. By resetting/rebooting the axsm, the LOF/LOS counters are reset.
CSCdr63104
Symptom:
dspcdstatus shows "No Alarms" for PXM45/any inapplicable slots. When slot number is not specified, it defaults to PXM slot.
Condition:
When the CLI dspcdstatus is executed without slot number being specified or when PXM45 slot is specified the above problem occurs.
Workaround:
None
CSCdr64230
Symptoms:
In a multi slave system with combined DAX & routed cons (50K), pnccb task is suspended when reset of the uni-AXSM card is followed by DAX con being modified (committed).
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 50K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. SPVCs are DAX (EP1_UNI_PORTS) & Routed. The Routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other turnk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.
(5) Reset uni-AXSM card (NODE_EP1: EP1_UNI_PORTs) followed by DAX con parameter change (via [cnfcon]).
Workaround:
None
CSCdr64564
Symptom:
When the optional parameter, shelf #, was provided in the CLI commands, the commands fail.
Conditions:
The valid value for shelf #, i.e. 0, was not being accepted.
WorkAround:
Shelf # is optional. Commands will go through if it is not entered.
CSCdr65883
Symptoms:
If the active PXM's disk is not synced (e.g. not all data on the disk is valid), the node is allowed to come up. This will result in lost of database configuration.
Condition: Powering up a node. This is very rare.
Workaround:
None.
CSCdr66184
Symptoms:
DAX Conns are not in AIS when connection is down
Conditions:
When dncon command is executed.
Workaround:
None
CSCdr66781
Symptom:
dspcdalms shows alarms whereas dspcdstatus does not.
Condition:
When AXSM has lines/connections/feeders in the alarm state, dspcdalms shows the alarms whereas dspcdstatus does not.
Workaround:
None
CSCdr66802
Symptom:
switchcc generates a syntax error message inappropriately
Condition:
Executing the switchcc command
Workaround
None
CSCdr67264
Symptom:
When a connection (which is in alarm) gets cleared of all the alarms, a connActive trap is sent to the CWM. This trap contains a bit map of conn. alarms in a mib object cwaChanAlarmStatus. When all the connection alarms clear this bitmap takes a value of zero. This was not documented in the MIB. Hence the confusion.
Condition:
Trap sent when all connection alarms clear on a given endpoint.
Workaround:
None.
CSCdr71350
Symptoms:
CLI dsppnni-path displays node name incorrectly
Conditions:
Only occurs when a long node name is used in source node.
Workaround:
None
CSCdr72570
Symptoms:
Some connections exhibit unexpected behavior such as "cannot resolve passthru".
Conditions:
Connections have been added to partition. VPI range of partition is changed so that the new VPI range is smaller than the old one.
Workaround:
Disallow modifications of VPI and VCI range when there are already connections in the partition. In the future when dynamic partitioning is implemented, modifying VPI/VCI should be allowed as long as such modification does not conflict with existing configurations.
CSCdr72621
Symptoms:
Some connections exhibit unexpected behavior (see related bug CSCdr72621) such as "ERR: Could not resolve passthro id" when "dspcon" is executed on some connections.
Conditions under which problem occurs: Connections have been added to partition. VPI range of partition is changed so that the new VPI range is smaller than the old one.
Workaround:
Disallow modifications of VPI and VCI range when there are already connections in the partition. In the future when dynamic partitioning is implemented, modifying VPI/VCI should be allowed as long as such modification does not conflict with existing configurations.
CSCdr73169
Symptom:
SNMP MIB Walk or Sending Traps results in failure(Event Log contains this information)
Condition:
Master Agent allocates memory every time A Subagent Registers its MIBs with it. If AXSM cards are reset without PXM being reset, then we will see memory allocation failure messages for SNMP MIB Walk and while sending traps.
Workaround:
None
CSCdr73423
Symptom:
When the cnfpasswd command is executed, and the enter key is hit twice, (instead of actually entering in a new password), the password is set to the defaults.
Condition:
This is command default case when no value is entered.
Workaround:
Always enter a password.
CSCdr75227
Symptom:
dsplns will show "other" for Medium LineType instead of "ShortSMF" etc.
Condition:
This bug will occur if the following backcard types for Sonet are used:
AXSM_BC_1_OC48_IR_B_NVID
AXSM_BC_1_OC48_SR_NVID
AXSM_BC_1_OC48_SR_B_NVID
AXSM_BC_2_OC12_IR_B_NVID
AXSM_BC_1_OC12_IR_C_NVID
AXSM_BC_8_OC3_IR_B_NVID
AXSM_BC_4_OC3_IR_NVID
AXSM_BC_4_OC3_IR_C_NVID
AXSM_BC_1_OC48_LR_B_NVID
AXSM_BC_1_OC48_XLR_NVID
AXSM_BC_2_OC12_LR_B_NVID
AXSM_BC_1_OC12_LR_C_NVID
AXSM_BC_8_OC3_LR_B_NVID
AXSM_BC_4_OC3_LR_NVID
AXSM_BC_4_OC3_LR_C_NVID
AXSM_BC_4_OC3_MMF_C_NVID
AXSM_BC_8_OC3_MMF_B_NVID
Workaround:
None
CSCdr76402
Symptoms:
Board (e.g. PXM-45) fails to boot and issues a NOVRAM checksum error.
Condition:
System boot code attempts to detect the type of NOVRAM installed.
Workaround:
None
CSCdr78869
Symptom:
Events of type "CHUNKNOTOWNER" are logged in the event log.
Condition:
CLI does a ssiIpcMessageFree before it assigns the memory to itself. This has been corrected an CLI now assigns the memory to itself before freeing it.
Workaround:
None
CSCdr80772
Symptom:
Log does not report successful switching of clock source.
Condition:
Unknown
Workaround:
None
CSCdr81154
Symptom:
dsppnport does not show active connections after dnpnport on a UNI port.
Conditions:
Issuing the dnpnport command on a UNI port. dsppnport <port_no> shows the number of connections on the port as zero.
WorkAround:
None
CSCdr83752
Symptoms:
? is taken as the node name and modified the node name to?
Conditions:
User enters the command cnfname with parameter as? to get help on this command
Workaround:
Change the node name back to the previous node name using cnfname command.
Additional Deliverables
SNMP MIB
The MIB release for this 2.0.11 is mibs2011.
Obtaining Service and Support
For service and support for a product purchased from a reseller, contact the reseller. Resellers offer a wide variety of Cisco service and support programs, which are described in the section "Service and Support" in the information packet that shipped with your chassis.
Note If you purchased your product from a reseller, you can access Cisco Connection On-line (CCO) as a guest. CCO is Cisco Systems' primary, real-time support channel. Your reseller offers programs that include direct access to CCO's services.
For service and support for a product purchased directly from Cisco, use CCO.
Cisco Connection On-line
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information,productdocumentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
•WWW: http://www.cisco.com
•WWW: http://www-europe.cisco.com
•WWW: http://www-china.cisco.com
•Telnet: cco.cisco.com
•Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.
[an error occurred while processing this directive]