Table Of Contents
2.0.10 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
About the 2.0.10 Release
Phased Release Strategy:
Software Release 2.0.10 and related hardware:
AXSM Cards
PXM 45 Cards
PNNI
Special Installation/Upgrade Requirements
General
Upgrade Procedure
Loading the runtime images from 2.0.02 to 2.0.10
Features Not Supported
Committed (but not delivered in this release)
Obsoleted:
Notes & Cautions
Limitations
Recommendations:
AXSM/Redundancy/Multi Fault Scenarios:
APS:
Compatibility Notes
Compatibility Matrix
Release 2.0.10 System Content
Switch Software and Boot Codes
Hardware Products
Known Anomalies
Problems Fixed in Release 2.0.10
Known Anomalies from Previous Releases
Problems Fixed in Release 2.0.02
Additional Deliverables
SNMP MIB
Appendices
Obtaining Service and Support
Cisco Connection On-line
2.0.10 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
About the 2.0.10 Release
Phased Release Strategy:
This is a third release of PXM45 and AXSM. Follow on releases are planned to add new feature contents and can be found in Marketing Road Map
Software Release 2.0.10 and related hardware:
AXSM Cards
The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. Other Cisco ATM platforms, and other ATM manufacturers equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
•
T3/E3
8 ports per back card, 2 back cards per dual height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 ports optical per back card, 2 back cards per dual height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 Ports per back card, 2 back cards per dual height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single port back card, one back card per slot
SMF Short, long and extra-long reach
ATM Layer Information
•Usage policing supported on all interfaces except OC48c/STM16
•T3 interfaces support both PLCP and direct cell mapping
•64 Logical interfaces -- ports, trunks, or virtual trunks (future)
•16 Class of Service queues for each class of service
•Supports independent queues for each ATM class of service
Network Management Features
•OAM functionality per ITU-T I.610
•Fault management - AIS/RDI at F4 and F5 flow
•User selectable continuity checking at connection endpoints
•Loopback diagnostics
•Automatic alarm generation and propagation for interface failures
The AXSM offers a complete ATM feature set and allows the MGX8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.
PXM 45 Cards
The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4 based PXM-1 design.
Reliability, Availability and Serviceability (RAS) Features
The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the RAS features are listed below:
•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.
•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow
•Hardware design to ensure that if one or both hard disk fails, the cards will still pass traffic with no interruption, although provisioning could be suspended.
•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXMs in a system. This was calculated at greater than 100,000 hours.
PNNI
The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:
•PXM-UI-S3
The PXM-UI-S3 supports the following interfaces:
•One RJ45 10Mbps 802.3 Ethernet port
•Two RJ45 RS232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:
Pin
|
Signal
|
Direction
|
Description
|
1
|
RTS
|
OUTPUT
|
Request to Send
|
2
|
DTR
|
OUTPUT
|
Data Terminal Ready
|
3
|
TX
|
OUTPUT
|
Transmit Data
|
4
|
SG
|
|
Signal Ground
|
5
|
SG
|
|
Signal Ground
|
6
|
RX
|
Input
|
Receive Data
|
7
|
DSR
|
Input
|
Data Set Ready
|
8
|
CTS
|
Input
|
Clear to Send
|
•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The following connections are supported:
–RJ48. Pin Out conforms to Accunet1.5 Specification
–Wire Wrap
–BNC
–DB15
•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.
–PXM-HD
This contains the hard disk for the processor.
PNNI
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and will scale to very large networks.
PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.
PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.
PNNI provides dynamic ATM routing with QoS support as defined by the ATM Forum. PNNI uses link-state and source state route technology, supports aggregation for private ATM addresses and links between switches, and has the ability to scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.
The functions of the PNNI routing protocol include the following:
•Hello protocol (allows adjacent switches to exchange topology information)
•PTSE (PNNI Topology State Elements) database synchronization and management
•PTSE flooding
•Address summarization and advertisement
•Link and nodal aggregation
•Pre-computation of routing tables
•Quality of Service (QoS) based routing
•Multiple Routing Metrics
•Discovery of neighbors and link status
•Synchronization of topology databases
•Load balancing on equal cost paths
•Load balancing on parallel links
•Load balancing with redundant addresses
•Alternate paths
The following PNNI features are supported in Release 2.0 of the MGX.
•UNI 3.0/3.1
•PNNI 1.0 Single Peer Group
•ILMI 4.0
•Point to point ATM SVCC and SVPC
•Support for CBR, VBR, rt-VBR, and UBR
•Alternate call routing (See separate feature description)
•On demand call routing (See separate feature description)
•Native E.164 and AESA (E.164, ICD, DCC) - formerly NSAP - address format
•Enhanced CAC with per service class policy parameter (See separate feature description)
•Per Class of service overbooking
•Congestion control (See separate feature description)
•PNNI connection and path trace
•OAM fault management
•Address Filtering (see separate feature description)
•Intelligent CAC (see separate feature description)
•Call Processor Redundancy
PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.
Special Installation/Upgrade Requirements
General
Upgrade Procedure
The new SCT files are being released with this version
Loading the runtime images from 2.0.02 to 2.0.10
For Redundant Systems
Upgrade the standby PXM45 boot code by using the following steps:
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "sysBackupBoot" command
Step 3 - hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove()
Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.010.000_bt.fw"
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "SETREV" command to load the 2.0.10 release:
setrev <slot number> <primary version>
For example: setrev 7 2.0(10.2)
Step 8 To upgrade the AXSM boot code, issue the "burnboot" command:
For example: burnboot <axsm slot> 2.0(10)
Step 9 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 10 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.
For example: setrev <axsm slot> 2.0(10.2)
For non-redundant systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.010.000_bt.fw"
d. - enter "y" to confirm
Step 2 Use the "SETREV" command to load the 2.0.10 release:
Step 3 To upgrade the AXSM boot code, issue the "burnboot" command:
burnboot <axsm slot> 2.0(10)
Step 4 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 5 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.
setrev <axsm slot> 2.0(10.2)
Repeat this step for all AXSMs on the card.
Features Not Supported
Committed (but not delivered in this release)
1. AXSM cards with STM1 electrical interface.
2. Inter operability with LS1010 and BPX-SES (BPX-SES is in beta phase).
3. Connection density: 50K connection per node. 25K connections is supported in this release.
4. Graceful upgrade from previous release to 2.0.10.
Obsoleted:
none
Notes & Cautions
1. Following a resetsys with an excess of 20 NNI interfaces we have intermittently experienced NNI interfaces remaining in Attempt State. The workaround in this case would be to execute a down port followed by an up port.
2. PNNI default min VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes (e.g. MPLS and NCDP). For users who would like to add MPLS controller in release 2.1, it is highly recommend to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be established automatically on 0/32.
3. In the MGX Rel 2.0, PNNI prevents adding dax SPVC endpoints with different parameters for forward/backward bandwidth. However, for the internode SPVCs, the addition of master/slave endpoints with different parameters for forward/backward bandwidth goes through but the connection remains failed and in mismatch state.
4. Following CLI commands were changed since publication of user documentation. Reason for the change is to make these commands consistent with other products.
Documented
|
Implemented
|
Purpose
|
addchan
|
addcon
|
Add SPVC endpoint
|
cnfchan
|
cnfcon
|
Change parameters of SPVC
|
delchan
|
delcon
|
Delete SPVC endpoint
|
dspchans
|
dspcons
|
Display all SPVCs in the node
|
dspchan
|
dspcon
|
Display a specific SPVC
|
Further, "addslave" and "addmaster" are obsolete.
5. By default, 900 cps and 543 cps will be reserved for SSCOP and PNNI respectively even when you disable SSCOP and PNNI. These values are configurable by the cnfpnctlvc command.
6. The database stores the backplane serial number and backcard serial numbers. Therefore if cards are moved from one node to other, console will display "SHM Alert!! Alert!!." In this situation follow the steps below:
a. enter "shmFailDisplay." Display table will show that BRAM is not native.
b. enter "shmFailRecoveryHelp". This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is "shmRecoverIgRblDisk".
c. enter "shmRecoverIgRbldDisk".
7. Non user data cells are not policed.
8. It is possible to add ports at cell rate fractionally higher than maximum line rate. This may cause cell drop.
9. Do not execute the "delcontroller" CLI when connections/ports still exists. The impact of executing delcontroller with connections is that the connections can not be recovered until the controller is readded via addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in provisioning state). There is now a warning to the user of the impact of the command when there are existing connections/ports.
10. Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.
11. Analysis of the code has identified a situation which has a low probability of occurring and in fast has not been encountered in any test scenarios to date. This caution and associated workaround is provided as a precautionary measure. When the link bandwidth for SPVC connections is reaching full capacity, thus minimal bandwidth is available for new SPVC connections, there is a condition which can be encountered where, the initial software check believes there is sufficient bandwidth for the new SPVC connection; however, the final software confirmation for available bandwidth may be rejected because there is no bandwidth available. If this problem occurs, the system will recover when the PNNI updates are refreshed. (This will happen at the default time of 30 minutes.) The user can recover from this problem by making the Administrative weight of that link very high to avoid that link from being used.
Limitations
1. If the destination address is reachable for both a IISp and a PNNI link from the same node, ABR connections will not route. The current routing algorithm will always choose IISP links over PNNI links because it is local. Since IISP does not support ABR connections, the connection setup will fail.
2. The user is unable to generate SCT files in this release. The user will have this capability in a future release.
3. For an asymmetric connection where the ingress bandwidth is not the same as egress bandwidth, the AXSM allows the connections to be added, however, the bandwidth calculation is incorrect. The computation of the egress and ingress will be based on the egress bandwidth.
4. For the MGX-PXM 1 feeder (Release 1.1.30) to MGX-PXM45 routing node (Release 2.0.10), currently the only narrowband modules supported are the FRSM, and AUSM, other narrowband cards will be supported in a later release. The following features from release 1.1.30 are NOT supported in this release as a feeder to a PXM45 system running 2.0.10:
a. All service modules except the FRSM T1/E1 channelized and unchannelized, and the AUSM
b. VBRrt is not supported
c. Online diagnostics for the PXM1
d. DS3 loopback on PXM1-T3
e. CoS mapping on FRSM
These features, and the other service modules are planned to be added in a future release.
5. SCT can be changed with connections present in this release. However, if service affecting the connections will be rerouted.
6. To replace one type of AXSM front card with other type, it is required to delete all connections, partitions, ports and down lines. In case of AXSM card failure, same type of AXSM card must be installed in that slot.
7. If port(s) and trunk(s) are configured on same AXSM card and port level failure occurs, it will cause SPVC deroutes.
8. Connection statistics at CLI and Bucket level is not available in AXSM-1-2488 cards. However, connection debug statistics are available in all types of cards.
9. OC48 BC intermittently fails to detect the optical input after power recycle. If this happens, the back Card should be reseated.
10. When CWM is connecting to the network, the IP address 10.0.x.x cannot be used for MGX-8850 PXM45 as lnPci address.
11. On power cycle of the node, the OC48 line may not come out of LOS/LOF condition. One may have to physically disconnect and reconnect the cable to get this going. This is a hardware bug and is currently being worked with the vendor.
12. For users who would like to add MPLS controller in release 2.1, it is highly recommended to set the min-vci value to be 35 or more for all partitions on the port where the MPLS partition will be added. By doing so, the TDP sig vc for MPLS will be automatically established on 0/32.
13. For users who would like to add MPLS partition on a port where other partitions has already been added and have set the min-vci value to be 32, then the users has two options:
a. After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.
b. Do a dnport and cnfpart to move the min-vci to 35 for all partitions on the port.
Recommendations:
•It is recommended to apply the default values for PCR, SCR, etc. to the Control VC. If the values are decreased to a low value, there is a chance that the Control VC (SSCOP or PNNI) will not come up. Note, you must use the SCT files released with 2.0.10 (number 2 and 3) for the Control VC feature.
AXSM/Redundancy/Multi Fault Scenarios:
AXSM Redundancy and Multi Fault scenarios have been tested with traffic on up to 25,000 connections. Problems have been encountered with the Multi Fault scenarios. Please see the Known Anomalies section for more details.
APS:
The following anomalies have been seen:
a. On switchredcd, APS may declare a signal fail incorrectly on protection line. This leads to a locked state which may not clear even when the new standby card comes up. A forced switch would be required to clear the condition. However, this situation does not affect the traffic but only causes APS protocol anomaly.
b. Detecting Channel Mismatch from a Protection Line selected state in bidirectional mode, causes only the side that detects the mismatch to reach selector released state without causing a switch on the remote end. This condition can potentially hit traffic in 1:1 mode.
Compatibility Notes
Compatibility Matrix
Board Pair
|
Latest Boot Code Version
|
Minimum
Boot Code
Version
|
Firmware
|
Latest
Firmware
Version
|
Minimum
Firmware
Version
|
PXM45
|
pxm45_002.000.010.000_bt.fw
|
2.0.10
|
pxm45_002.000.010.002_mgx.fw
|
2.0.10.2
|
2.0.10.2
|
AXSM-1-2488
|
axsm_002.000.010.000_bt.fw
|
2.0.10
|
axsm_002.000.010.002.fw
|
2.0.10.2
|
2.0.10.2
|
AXSM-16-155
|
axsm_002.000.010.000_bt.fw
|
2.0.10
|
axsm_002.000.010.002.fw
|
2.0.10.2
|
2.0.10.2
|
AXSM-4-622
|
axsm_002.000.010.000_bt.fw
|
2.0.10
|
axsm_002.000.010.002.fw
|
2.0.10.2
|
2.0.10.2
|
AXSM-16-T3/E3
|
axsm_002.000.010.000_bt.fw
|
2.0.10
|
axsm_002.000.010.002.fw
|
2.0.10.2
|
2.0.10.2
|
MGX 2.0.10 interoperates with CWM 10.3.
MGX 2.0.10 operates with MGX 1.1.30 as a feeder.
MGX 2.0.10 operates with Cisco View 5.1x (package 3.3x).
Release 2.0.10 System Content
Switch Software and Boot Codes
The following four images are applicable to the 2.0.10 release:
•Boot Images
– axsm_002.000.010.000_bt.fw
–pxm45_002.000.010.000_bt.fw
Runtime Images
– axsm_002.000.010.002.fw
–pxm45_002.000.010.002_mgx.fw
Hardware Products
Support hardware for Release 2.0.10:
Model
|
800 Part Number
|
Revision
|
PXM45
|
800-06147-07
|
B0
|
PXM-UI-S3
|
800-05787-02
|
A0
|
PXM-HD
|
800-05052-03
|
A0
|
AXSM-1-2488
|
800-05795-05
|
A0
|
SMFSR-1-2488-FC
|
800-05490-05
|
A0
|
SMFXLR-1-2488-FC
|
800-05793-05
|
A0
|
SMFLR-1-2488-FC
|
800-06635-04
|
A0
|
AXSM-16-155
|
800-05776-06
|
A0
|
AXSM-4-622
|
800-05774-09
|
B0
|
AXSM-16-T3/E3
|
800-05778-08
|
A0
|
SMFIR-2-622
|
800-05383-01
|
A1
|
SMFLR-2-622
|
800-05385-01
|
A1
|
SMB-8-T3-BC
|
800-05029-02
|
A0
|
SMB-8-E3-BC
|
800-04093-02
|
A0
|
MMF-8-155
|
800-04819-01
|
A1
|
SMFIR-8-155
|
800-05342-01
|
B0
|
SMFLR-8-155
|
800-05343-01
|
A1
|
Known Anomalies
The following is the list of known anomalies in this MGX 8850 software delivery. Included with each is a brief discussion of the problem. A more in depth discussion is available in the release note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
S1 Bugs
|
|
CSCdr15911
|
Symptom:
Changing the backcard may sometimes cause the front card to reset and loss service. It may occasionally difficult to bring up the AXSM.
Conditions:
This problem happens occasionally when someone reseats the backcard several times, the front card is reset. It is also observed that during power on/off testing, sometime the PhyTask got suspended.
Workaround:
Try not to reset the backcard too often. If the front card gets stuck during the power-on, try to reset the front and back card to bring the system.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds07776
|
Symptom:
The Standby AXSM/PXM fails to come up and is put in FAILED state.
Condition:
After several hundred switchovers, the Standby card fails to come up due to failure of a DB Table Creation. This results in Standby card failing to complete its initialization and hence gets rebooted. After three such attempts, the card is put in FAILED state.
Workaround:
Reset the corresponding ACTIVE card.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds16063
|
Symptoms:
SPVCs do not get routed.
Conditions:
When there is a configuration error on two ends of a trunk with a VPI/VCI mismatch, the master SPVCs generated from the node with the lower nodeid with the configuration error will have failed calls. The connections may not get routed even if there are parallel links without any configuration error
Workaround:
The workaround for this problem will be to remove this configuration error.
|
CSCds20318
|
Symptoms:
An AXSM is with a log event indicating FAT_CD_DEAD. This event indicates that the card is not responding to poll messages from the active PXM and is now declared dead and thus is reset to revive the card. If this problem occurs 3 times in a hour, the card will be moved to the failed state with the failed reason to equaled to MAX NUMBER OF RESET reached.
Conditions:
A node operating in steady state.
Workaround:
Reset the failed card.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds20527
|
Symptom:
The CWM Software(ConnProxy module) will notice timeouts while creating connections continuously.
Condition:
SNMP Agent currently support only 16 outstanding requests. Any requests received after it has 16 requests outstanding will be dropped(timeout for NMS Application: Dropped meaning no responses sent back to the NMS application).
Workaround:
Timeouts do not cause any harm except that Users or the CWM modules might log multiple events mentioning that Agent timed out.
Additional Information from CWM:
If client tries to add more than 100 connections through Connection Proxy (Service Agent) Script, they will start getting Time Out's even though the time out frequency is less. Client then needs to find out from the Log file which all connections could not be added. If provisioning is a one time action, Client may bear this, but if they do provisioning very often, it will be a serious concern.
|
CSCds22416
|
Symptoms:
The problem will cause UBR calls to fail
Conditions:
When AVCR for a PNNI link along the route to the destination becomes zero, the route search for that destination will fail even for UBR calls.
Workaround:
None
|
CSCds22824
|
Conditions:
If an AXSM card gets reset during the FW download.
Symptoms:
The AXSM card fails to download FW image the next time and dspcd shows "Failed" Reason: SHM_CDF_SW_DNLD_FAILED"
Workaround:
None
Problem Occurrence:
Intermittent or occurs once.
|
CSCds22946
|
Symptom:
Some connections are not being routed
Condition:
Master node: swichover the AXSM redundancy on AXSM UNI, switchcc (PXM),
switchover the AXSM redundancy on AXSM NNI Via node: switchover the AXSM NNI ingress side, switchcc (PXM), and switchover AXSM NNI on egress side Do this continuously overnight. Then via node is congested
Work Around:
Reset the via node
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23866
|
Symptoms:
An axsm can get reset intermittently to due to timeout condition.
Conditions:
Under Which the Problem Occurs: Perform a PXM switchover.
Workaround:
Avoid doing a PXM switchover when the AXSMs are busy with connection changes (e.g. connection setup/tear down.)
Problem Occurrence:
Intermittent or occurs once.
|
CSCds24168
|
Symptoms:
This bug reports that the card slot is shown as Empty when it is in fact inserted.
Conditions:
Run the dspcds command.
Workaround:
This may be just a display problem. Resetting the card may correct the problem.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds24320
|
Symptom:
All PNNI links for virtual trunks goes down. No calls routed
Condition:
Have many virtual trunks. Typically around 60 vts and then do switchcc on PXM. This is also very rare problem. In fact this is the only occurrence of problem.
Workaround:
None
Problem Occurrence:
Intermittent or occurs once.
|
CSCds34606
|
Symptom:
switchredcd <from-slot> <to-slot> with large and invalid value for from or to slots would cause PXM to crash then switchover.
Conditions:
switchredcd with invalid slot values.
Workaround:
Don't give invalid slot value. Use only slot number from 1 to 32
|
CSCds34659
|
Symptom:
Shelf Manager task got suspended.
Condition:
Exception in the Shelf Manager task.
Workaround:
Pullout the PXM45 card and re-insert it.
|
S2 BUGS
|
|
CSCdr20887
|
Symptom:
After the trunk card comes back from reset, vsierr 0x5017 messages and [egress ConnID add failure] messages are observed.
Condition:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A few UNI ports (EP1_UNI_PORTS) are present in NODE_EP1.
(3) A few UNI ports (EP2_UNI_PORTS) are present in NODE_EP2.
(4) There are 25K SPVCs between EP1_UNI_PORTS and EP2_UNI_PORTS. All these SPVCs are routed through one trunk (TRK_A_BETWEEN_NODE_EP1_AND_NODE_VIA) while the other trunk (TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA) is downed.
(5) A [uppnport] is executed to TRK_B_BETWEEN_NODE_EP1_AND_NODE_VIA.
(6) Reset this trunk card (hosting TRK_A & TRK_B) while in [down in progress] state.
Workaround:
One of the following:
(1) Do not reset trunk card while rerouting takes place.
(2) If the failure has already occurred, rectify this problem by doing [resetsys] on every PXM45 in the network.
Problem Occurrence:
Intermittent or occurs once.
|
CSCdr89521
|
Symptom:
dspcon shows routing cost = 0
Condition:
This will happen after swithcc on connections that are not rerouted
Workaround:
Do a dncon or rrtcon
|
CSCdr89686
|
Symptom:
Upon deletion of a secondary clock source with the primary clock source already bad, the node tries to lock to the Primary (even though it is bad.)
Conditions:
This symptom occurs on the MGX8850 running release 2.0, 2.0(01) or 2.0(02) software. The use should have both clock sources configured.
Workaround.
Wait for about 300 seconds and do a dspclksrcs command. The node will display the correct status of the clock with the Primary bad and the active being the internal.
|
CSCdr93447
|
Symptom:
PNNI links go up and down.
Conditions:
QE1210 chip which handles SAR traffic on PXM goes into an unrecoverable bad state where it arbitrarily discards cells on the control channels. This translates into invalid CRC and invalid Length errors on the AAL5 frames which belong to PNNI / SSCOP. This condition is very rare, happens due to simultaneous multiple faults in the network having high number of connections. Massive flood of reroutes / status requests on the PNNI links cause this condition.
Workaround:
Reset the PXM card having this problem.
Problem Occurrence:
Intermittent or occurs once.
|
CSCdr94471
|
Symptoms:
Standby PXM45 card gets reset 3 times and stays in Failed state.
Conditions:
Upgrading PXM45 image from previous version to a new version.
Workaround:
Reset the standby PXM45 card
Problem Occurrence:
Intermittent or occurs once.
|
CSCds08941
|
Symptoms:
While performing SPVC deroute (initiated at NODE_VIA, the AXSM card in node NODE_EP1 (AXSM slot 2) showed IPC allocation failure.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on the NNI on NODE_VIA.
(4) On the AXSM on NODE_EP1, IPC allocation failure was observed.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds09512
|
Symptoms:
AIS is not generated when dnport issued on AXSM
Conditions:
a. Issue dnport for a dax conn where both the UNI ports belong to same slave
b. Issue dnport for a routed connection where both UNI port and Trunk port belong to same slave
Workaround:
None.
|
CSCds09604
|
Symptom:
On an initial boot up of two AXSM boards. After both boards are booted, redundancy is added. Then you add APS for the intercard case. With this scenario, the trap generates 60126 when the fiber is already moved prior to adding APS. 60126 implies APS Redundancy Alarm.
Conditions:
Once the APS is deleted and added back on later, it does not generate 60126. This behavior does not correspond to the real behavior and therefore is a bug.
Workaround:
This problem can not be avoided. However, it is not critical to the system not to see this trap. However, it is an error because it is not report an alarm.
|
CSCds09708
|
Symptom:
SNMP GETs on the following variables:
cwspOperMaxSvpcVpi, cwspOperMinSvpcVpi, cwspOperMaxSvccVpi, cwspOperMinSvccVpi, cwspOperMaxSvccVci, and cwspOperMinSvccVci may return incorrect value. And the value mismatches with that shown on CLI command. For instance, 'dsppnport' show MaxSvccVci value is 65535, however SNMP get on 'cwspOperMaxSvccVci' variable shows 255.
Condition:
This occurs when the value of these variables is greater than 255.
Workaround:
None
|
CSCds13444
|
Symptom:
The following message is generated in the event log: 08-06262 08/23/2000-15:06:51 SYS-3-RUNAWAYTASK E:02239 tRootTask 0x80132248 Task 0x3f008c[tTnInTsk01] is running away on CPU - logging task.
Condition:
A telnet client attached to a CLI session with no user input was echoing control characters.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds13760
|
Symptom:
Unplugging and plugging the standby PXM card can cause the card to reset continuously
Conditions:
Remove the standby PXM card and plug it in where it might not be seated correctly.
Workaround:
Remove the standby card and plug it in carefully making sure it is plugged and seated correctly and secured
Problem Occurrence:
Intermittent or occurs once.
|
CSCds13955
|
Symptoms:
The dspcds, dspcd and dspcdalms do not show the same alarm information.
Conditions:
Alarms reported on an AXSM card is not integrated into the dspcd and dspcds command.
Workaround:
Use dspndalms to find out the different alarms reported under the different categories.
Use the dspcdalms command to show alarms reported under "Alarms From Cards" category.
Use the dspcd/dspcds commands to show alarms reported under "Shelf Slot Alarms" category by the dspndalms command.
In this version of the Software, the above dspcdalms/dspcd/dspcds commands do not show the combined alarm state from "Alarms From Cards" and "Shelf Slot Alarms".
|
CSCds14824
|
Symptom:
Incorrect local or remote NSAP address for one or more SPVCs leading to routing failure for such SPVCs.
Conditions:
Has been observed once after a non-graceful upgrade. There are no related specific conditions.
Workaround:
Delete and Add affected SPVC endpoint.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds14832
|
Symptom:
Two nodes (Feeder and another with T3 line, line type PLCP)are interconnected to each other, upon disconnection of T3 RX/TX cable and reconnecting back, AXSM T3 line showed RcvRAI alarm. Feeder side showed communication Failure.
Condition:
False alarm was generated for EM by which RcvRAI was never get cleared.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds15089
|
Symptom:
dsppnports on pxm shows the port down but axsm shows the port as up (operationally and administratively).
Condition:
Pull out a cable in a pnni-link between two nodes.
Workaround:
None
Problem Occurrence:
Intermittent or occurs once.
|
CSCds15159
|
Symptom:
Crossbar errors and alarm are observed using CLI commands dspxbarerrcnt and dspswalm
Condition:
When PXM-HD backcard was removed from standby PXM45. The standby card will be reset. The errors appears transient during PXM45 reset.
Workaround:
None
|
CSCds16742
|
Symptoms:
AXSM card may bet reset or moved to the failed state.
Conditions:
Any activity that triggers a PXM switchover.
Workaround:
If the AXSM is in the failed state, reset the axsm card again to bring it back.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds16776
|
Symptom:
The conn pending congestion counter shows negative values.
Condition:
Calling the free SVC routine again is suspected in case of a particular infrequent error path.
Workaround:
None.
|
CSCds17859
|
Symptom:
CLI can be held up for up to 10 to 15 seconds when CWM FTPs files from the node.
Conditions:
When CWM FTPs files from the node.
Workaround:
None.
|
CSCds17876
|
Symptoms:
The node allows SPVCs with VCI less than 32 to be added.
Conditions:
With the port's minsvccvci set to 32, attempts to add SPVCs with VCI less than 32 are not rejected.
Workaround:
In order to properly use SPVCs with VCI values less than 35 (default), perform the command:
cnfpnportrange <portid> -minsvccvci <desired minimal VCI value> before adding SPVCs with low VCI values.
Since the VCI range below 32 is not recommended by ATM Forum and more control VCs are reserved below VCI=35, a warning message listed below will be displayed when the minSvccVci is changed to be below 35:
** Warning: MinSvccVci HAS BEEN ASSIGNED A VALUE LESS THAN 35
|
CSCds18328
|
Symptom:
The switch has changed the default value of SvccVci from 32 to 35. This has not been reflected in the MIB variable 'cwspMinSvccVci' in "CISCO-WAN-SVC-MIB.my".
Condition: From the MIB, an user would assume the SvccVci value is 32, yet when the user tries to configure SVC or SPVC, the switch only allow configuration for 35 and above.
Workaround:
The user can configure SVC or SPVC with VCI only from 35 or above if the user decides to use the default value. The user can also do an snmp GET of this variable for the interface
|
CSCds18690
|
Symptoms:
PNNI links for virtual trunks are not up and so calls do not route over those virtual links
Condition:
When we reset AXSMs or do resetsys and after that resync takes place between VSIM and VSIS. Now sometimes control vc commits by resync module are rejected by slave and if it happens then resync informs VCM and vcm deletes control vc and tries to establish again but at that time PNNI is already bound to LCN and so proxy slave rejects this request and so nowonwards pnnilink will not come up. This is very rare. Very hard to reproduce.
WorkAround:
None
Problem Occurrence:
Intermittent or occurs once.
|
CSCds19282
|
Symptoms:
Intermittently, some PXMs will fail to boot up.
Conditions:
Perform a resetys multiple times in a row.
Workaround:
Try to bring up the node using only 1 PXM, if that PXM fail to come up.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds19314
|
Symptom:
The dsppnports on pxm will show ilmi state as autoconfig but axsm is in UpandNormal state or on pxm ilmi will be showed as disable when it was really enabled on axsm. Condition:
Happens more when axsm is rebooted or node is reset. Normally resetting card/node will solve the problem. or even dnpnport and uppnport.
Workaround:
Reduce the number of ports on this card. Happens more when we have more than 35 ports(vnni) with ilmi enabled on them
|
CSCds20227
|
Symptoms:
One end of SPVC connections go into E-AISRdi alarm even though the other end does not have any line failure.
Condition:
Under rare circumstances (which is still under investigation), clearing of line alarm condition does not cause clearing of ATM layer AIS in the ingress direction. The exact sequence of events which cause this condition is presently unknown. When this happens the QE48 generates F5/F4 AIS in the ingress direction on all conns. on the affected port. This causes the far end of the connection to enter into alarm.
Workaround:
Induce a line fault on the far end and restore the line to normalcy. This could be done by simply plugging out the cable and putting it back. This would clear all connection alarms in the local end.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds20287
|
Symptom:
Unable to CC to axsm possibly after a switchred.
Conditions:
This is an axsm OC48 with APS.
Workaround:
None
Problem Occurrence:
Intermittent or occurs once.
|
CSCds20318
|
Symptoms:
An AXSM is with a log event indicating FAT_CD_DEAD. This event indicates that the card is not responding to poll messages from the active PXM and is now declared dead and thus is reset to revive the card. If this problem occurs 3 times in a hour, the card will be moved to the failed state with the failed reason to equaled to MAX NUMBER OF RESET reached.
Conditions:
A node operating in steady state.
Workaround:
Reset the failed card.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds20504
|
Symptom
This behavior is seen when the APS operates in bi directional mode. The side which sees a channel mismatch failure will go to the selector released state. The other side remains in the protection line selected state.
Condition:
This could cause loss of data as the other side may not have bridged the appropriate line.
Work around
The only way to get out of this situation is to cause a forced switch to the work line. This is done using switchapsln <bay> <line> 4 <service switch>. Do this on both ends of the line.
|
CSCds21342
|
Symptom:
Node resets intermittently
Condition:
DC supply voltage is abnormally high and derived voltages are fluctuating.
Workaround:
Lower the DC input
Problem Occurrence:
Intermittent or occurs once.
|
CSCds22862
|
Symptom:
Was not able to CC to the axsm after a switchred sometimes.
Condition:
An axsm OC48 card with APS (automatic protection switching) following a switchred sometimes caused excessive axsm cpu usage.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds22868
|
Symptom:
Provision spvcs through an IISP link. On repeated setup and release of spvcs, it was noticed that the user side IISP had some connection data structures which were not getting cleared when the call was released.
Condition:
The problem was been identified as a user state machine error. It will surface in a rare scenario where the sscop link is down while trying to release the active call in the state u10.
Workaround:
The problem will not surface so long as the sscop link is up.
|
CSCds22604
|
Symptom:
There are multiple problem,
1. Ramsync send failure
2. Connection are not in sync between active and standby card
Condition:
Trigger a AXSM card switchover and pull the new active cards back card while the switchover is going on.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23335
|
Symptom:
The AXSM fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.
Condition:
There are more than 4 AXSMs in the shelf and the file descriptor list gets corrupted on the ACTIVE or STANDBY PXM.
Workaround:
1. Reset the PXM card which has the file descriptor list corrupted if redundancy is available.
2. Call the support to rectify the file descriptor list to avoid resetting the card.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23341
|
Symptom:
Vsierr 0xe007,... is displayed on the screen
Condition:
Combination of cnfpnportcac, addcon and dnport can cause the bandwidth to go negative.
Workaround:
Disable ingress cac. Need to verify this
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23518
|
Symptom:
Cell bus connection between PXM and AXSM is lost, AXSM is reset.
Condition:
Problem has occured during trunk switching when there are more than 25K connections.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23525
|
Symptom:
Pnni-link port is in attempt state.
Condition:
Multiple switch overs and reset of slave cards.
Workaround:
Bring the port down and up. The port will be up and pnni-link will be in two-way inside.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23579
|
Symptoms:
Occasionally, when downing a UNI port (dnport) on AXSM after dnpnport and uppnport on the PXM, some VSIErr are displayed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnpnport on the UNI on NODE_EP1.
(4) uppnport on the same UNI on NODE_EP1.
(5) dnport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds23586
|
.Symptoms:
After the switchover is completed, try to cc to the new active card. On the new active card, the user prompt shows an incorrect state momentarily (e.g A2b.14.AXSM.i). It should have shown the prompt as A2b.14.AXSM.a
Conditions:
Perform a switchredcd on a pair of AXSM cards that have APS configured
Workaround:
None.
Problem Occurrence:
Intermittent or occurs once.
|
CSCds24309
|
Symptom
Switchred repeatedly will cause one of the APS sides to have the following
configuration
J1.3.AXSM.a > dspapsln 3.1.5
Working Index : 3.1.5 Protection Index : 4.1.5
Provisioned Arch : 1+1 Provisioned Direction : bi
Operational Arch : 1+1 Operational Direction : bi
Active Line : working WTR(min) : 5
SFBer 10^-n : 3 SDBer 10^-n : 5
Revertive : Yes Last User Switch Req : ForcedW->P
Bridge State : WChan Bridged Selector State : Selector Released
Protection Line Pending Request : SignalFailLowPriority
Working Line Pending Request : None
APS Trouble Mask : ProtectionSwitchingByte,ModeMismatch
Bit Map Req Field Chan Field
Transmit K1 0xc0 Sig Fail Low Null Channel
Receive K1 0x20 Reverse Request Null Channel
Current Request 0xc0 Sig Fail Low Null Channel
Bit Map Chan Field Arch Field Dir Mode Field
Transmit K2 0x5 Null Channel 1+1 BI
Receive K2 0xd Null Channel 1:1 BI
Alarm State Clear
Condition
Repeated switchredcd causes this condition when APS is provisioned.
Effect - This would prevent APS from switching to the protection line in case of any failure on the working line causing loss of traffic.
Work Around.
Executing forced switch from working to protection using switchapsln <bay> <line> 3 <serviceswitch> on both sides should clear it.
|
CSCds24362
|
Symptoms:
Occasionally, when downing a UNI port (dnport) on AXSM followed by upport, some VSIErr are displayed on the AXSM console.
Conditions:
(1) In a three-node (NODE_EP1, NODE_VIA, NODE_EP2) network, nodes are connected linearly (e.g., two trunks connecting NODE_EP1 and NODE_VIA, three trunks connecting NODE_VIA and NODE_EP2).
(2) A connection is established from NODE_EP1 to NODE_EP2.
(3) dnport on the UNI on NODE_EP1.
(4) upport on the UNI on NODE_EP1. At this time, some vsierr might be displayed on the AXSM console.
Workaround:
None.
|
CSCds24399
|
Symptom:
switchredcd following by a switchcc could make the old active service module stuck in boot state _ the old standby service module is OK and in active state.
Conditions:
switchcc shortly after a switchredcd
Workaround:
1. Wait until both service modules come back to active/standby pair before doing switchcc.
2. If old active service module is stuck in boot then reset it from active PXM.
|
CSCds24905
|
Symptom:
Connection commits get rejected for lack of LCN resource / BW resource
Condition: Bw resource get negative, because of a bug in Ingress CAC feature.LCN resource goes negative when a trunk is derouting and a switchredcd is forced on the axsm cards.
Workaround:
None
|
CSCds25413
|
Symptom:
In a node with thousands of SPVC calls, deroute of calls followed by a reroute is very slow.
Condition:
Once the node is in a state of congestion caused by too many calls in the state of being setup or being torn down, we need to process RELEASE messages immediately so as to alleviate the congestion. There was a problem noticed in this path where RELEASE message processing was being deferred.
Workaround:
None
|
CSCds26981
|
Symptom:
The AXSM fails to come up as ACTIVE. After 3 attempts, it is put in FAILED state.
Condition: There are more than 4 AXSMs in the shelf and the file descriptor list gets corrupted on the ACTIVE or STANDBY PXM.
Workaround:
None
Additional Information:
1. Reset the PXM card which has the file descriptor list corrupted if redundancy is available. 2. Call the support to rectify the file descriptor list to avoid resetting the card.
|
CSCds28506
|
Symptom:
Active processor resets due to TLB exception in pnCcb while performing operation on a resync element.
Conditions:
There are no particular conditions which cause this to happen. This problem was seen only in one particular weeks' build/image and has not been seen in subsequent images.
Workaround: None.
|
CSCds28520
|
Symptom:
OC48 Card CLI hangs, and one cannot execute any commands.
Condition:
Some event on the OC48 back card such as APS switchover, card switchover and back card pull.
|
