Table Of Contents
2.0.11 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
About the 2.0.11 Release
Phased Release Strategy:
Software Release 2.0.11 and related hardware:
AXSM Cards
PXM 45 Cards
PNNI
Special Installation/Upgrade Requirements
Upgrade Procedure
Loading the runtime images from 2.0.10 to 2.0.11
Loading the runtime images from 2.0.02 to 2.0.11
New CLI Commands
Changed CLI Commands
Features Not Supported
Committed (but not delivered in this release)
Obsoleted:
Notes & Cautions
Limitations
Recommendations:
Compatibility Notes
Compatibility Matrix
Release 2.0.11 System Content
Switch Software and Boot Codes
Hardware Products
Known Anomalies
Problems Fixed in Release 2.0.11
Known Anomalies from Previous Releases
Problems Fixed in Release 2.0.10
Problems Fixed in Release 2.0.02
Additional Deliverables
SNMP MIB
Obtaining Service and Support
Cisco Connection On-line
2.0.11 Version Software Release Notes
Cisco WAN MGX 8850 Software
About These Release Notes
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
About the 2.0.11 Release
Phased Release Strategy:
This is the fifth release of PXM45 and AXSM. Follow on releases are planned to add new feature contents and can be found in Marketing Road Map
Software Release 2.0.11 and related hardware:
AXSM Cards
The AXSM is a double height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX. The AXSM uses the serial line traces on MGX chassis to access the 45Gbp crosspoint fabric of the PXM45 and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM provides ATM switching and line functionality, and is compatible with the feature set of the BXM card of the BPX, the UXM on the IGX, and AUSM of the release 1 MGX8850. Other Cisco ATM platforms, and other ATM manufacturers equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
•
T3/E3
8 ports per back card, 2 back cards per dual height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 ports optical per back card, 2 back cards per dual height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 Ports per back card, 2 back cards per dual height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single port back card, one back card per slot
SMF Short, long and extra-long reach
ATM Layer Information
•Usage policing supported on all interfaces except OC48c/STM16
•T3 interfaces support both PLCP and direct cell mapping
•64 Logical interfaces -- ports, trunks, or virtual trunks (future)
•16 Class of Service queues for each class of service
•Supports independent queues for each ATM class of service
Network Management Features
•OAM functionality per ITU-T I.610
•Fault management - AIS/RDI at F4 and F5 flow
•User selectable continuity checking at connection endpoints
•Loopback diagnostics
•Automatic alarm generation and propagation for interface failures
The AXSM offers a complete ATM feature set and allows the MGX8850 to scale to the core of service provider networks from the T3/E3 edge to the OC48c core. Full line rate is achieved through the use of the serial line traces on the MGX8850 platform. The entirely standards based design and connection protocols enables the installation into any existing network, as well as building new ATM infrastructures.
PXM 45 Cards
The PXM-45 is a 45Gbps processor switch module. The architecture of the PXM-45 contains the CellBus fabric that is used in the current PXM-1, but adds the functionality of a 45Gbps cross point switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX8850. The PXM-45 provides a Stratum3 central clocking circuit conforming to GR-1244 and G.813 specifications. This is an improvement over the Stratum4 based PXM-1 design.
Reliability, Availability and Serviceability (RAS) Features
The PXM-45 is designed to be fully redundant, there are two dedicated slots in the 8850 (dual height slots 7 and 8) that will house the PXM-45. Highlight of the RAS features are listed below:
•Switchover from active to standby is designed to result in no cell loss with the exception of cells that are physically on the fabric at the time of the swap.
•In-band arbitration/grant mechanism ensures that service module failure does not stop traffic flow
•Hardware design to ensure that if one or both hard disk fails, the cards will still pass traffic with no interruption, although provisioning could be suspended.
•MTBF Goal is calculated using a 99.9999% availability model which assumes two PXMs in a system. This was calculated at greater than 100,000 hours.
PNNI
The PXM-45 will support PNNI software. There are two other components that make the complete card set these are:
•PXM-UI-S3
The PXM-UI-S3 supports the following interfaces:
•One RJ45 10Mbps 802.3 Ethernet port
•Two RJ45 RS232 Data Termination Equipment (DTE) ports that can be Y cabled. Pinouts are as follows:
Pin
|
Signal
|
Direction
|
Description
|
1
|
RTS
|
OUTPUT
|
Request to Send
|
2
|
DTR
|
OUTPUT
|
Data Terminal Ready
|
3
|
TX
|
OUTPUT
|
Transmit Data
|
4
|
SG
|
|
Signal Ground
|
5
|
SG
|
|
Signal Ground
|
6
|
RX
|
Input
|
Receive Data
|
7
|
DSR
|
Input
|
Data Set Ready
|
8
|
CTS
|
Input
|
Clear to Send
|
•Two DB9 T1/E1 BITS input, with converted cables that can be Y cabled. The following connections are supported:
–RJ48. Pin Out conforms to Accunet1.5 Specification
–Wire Wrap
–BNC
–DB15
•One DB15 Alarm interface. Contacts are normally open. This interface can be Y cabled.
–PXM-HD
This contains the hard disk for the processor.
PNNI
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and will scale to very large networks.
PNNI includes two categories of protocols. PNNI defines a protocol for distributing topology information between switches and clusters of switches. This information is used to compute paths through the network. PNNI topology and routing are based on the well-known link-state routing technique.
PNNI also defines a second protocol for signaling, that is, message flows used to establish point-to-point connections across the ATM network. This protocol is based on the ATM Forum UNI 4.0 signaling, with mechanisms added to support source routing, crankback, and alternate routing of call setup requests in case of connection setup failure. Whereas the UNI signaling protocol distinguishes between the user and network sides of a connection, PNNI is a symmetrical protocol.
PNNI provides dynamic ATM routing with QoS support as defined by the ATM Forum. PNNI uses link-state and source state route technology, supports aggregation for private ATM addresses and links between switches, and has the ability to scale the network and its performance by means of configuring PNNI peer groups and hierarchical levels. A key feature of the PNNI mechanism is its ability to automatically configure itself in networks in which the address structure reflects the topology.
The functions of the PNNI routing protocol include the following:
•Hello protocol (allows adjacent switches to exchange topology information)
•PTSE (PNNI Topology State Elements) database synchronization and management
•PTSE flooding
•Address summarization and advertisement
•Link and nodal aggregation
•Pre-computation of routing tables
•Quality of Service (QoS) based routing
•Multiple Routing Metrics
•Discovery of neighbors and link status
•Synchronization of topology databases
•Load balancing on equal cost paths
•Load balancing on parallel links
•Load balancing with redundant addresses
•Alternate paths
The following PNNI features are supported in Release 2.0 of the MGX.
•UNI 3.0/3.1
•PNNI 1.0 Single Peer Group
•ILMI 4.0
•Point to point ATM SVCC and SVPC
•Support for ABR, CBR, VBR, rt-VBR, and UBR
•Alternate call routing (See separate feature description)
•On demand call routing (See separate feature description)
•Native E.164 and AESA (E.164, ICD, DCC) - formerly NSAP - address format
•Enhanced CAC with per service class policy parameter (See separate feature description)
•Per Class of service overbooking
•Congestion control (See separate feature description)
•PNNI connection and path trace
•OAM fault management
•Address Filtering (see separate feature description)
•Intelligent CAC (see separate feature description)
•Call Processor Redundancy
PNNI networks are highly resilient due to their ability to quickly reroute connections around failed network elements, and to update routes and network topology based upon availability of network resources. Connections will generally route quickly using pre-computed routing tables, but in the case of congestion or during a network failure, on-demand routes will be calculated for connections.
Special Installation/Upgrade Requirements
Upgrade Procedure
There are new SCT files that are being released with this version.
Note: When upgrading your node, upgrade in the following order
pxm45 backup boot
pxm45 runtime image
axsm runtime image
Loading the runtime images from 2.0.10 to 2.0.11
For Redundant Systems
Upgrade the standby PXM45 boot code by using the following steps:
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "sysBackupBoot" command
Step 3 - hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove()
Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "LOADREV" command to load the 2.0.11 release on the standby card:
loadrev <slot number> <version>
For example: loadrev 7 2.0(11.3)
Step 8 After the standby card comes back up with the new image in the ready state, use the "RUNREV command to load the 2.0.11 release on the active card. This command will bring your original standby card to active state.
runrev <slot number> <version>
For example: runrev 8 2.0(11.3)
Step 9 After the redundant card comes up in standby ready, issue the command "COMMITREV" to commit your node to the current release.
commitrev <slot number> <version>
For example: commitrev 8 2.0(11.3)
Step 10 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 11 To upgrade non-redundant AXSM cards with the new runtime image, issue the "LOADREV, RUNREV and COMMITREV" command for each AXSM card.
For example:
loadrev <axsm slot> 2.0(11.3)
runrev <axsm slot> 2.0(11.3)
commitrev <axsm slot> 2.0(11.3)
Repeat these steps for all non-redundant AXSM cards.
Step 12 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.
loadrev <slot number> <version>
For example: loadrev <axsm slot> 2.0(11.3)
Step 13 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.
runrev <slot number> <version>
For example: runrev <axsm slot> 2.0(11.3)
Step 14 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <axsm slot> 2.0(11.3)
Repeat this step 12-14 for all redundant AXSM cards.
For non-redundant (PXM45) systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
d. - enter "y" to confirm
Step 2 Use the "LOADREV, RUNREV, COMMITREV" commands to load the 2.0.11 release:
Step 3 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 4 To upgrade non-redundant AXSM cards with the new runtime image, issue the "LOADREV" command for each AXSM card.
For example:
loadrev <axsm slot> 2.0(11.3)
runrev <axsm slot> 2.0(11.3)
commitrev <axsm slot> 2.0(11.3)
Repeat these steps for all non-redundant AXSM cards.
Step 5 To upgrade redundant AXSM cards with the new runtime image, issue the "LOADREV" command on for the standby card.
loadrev <slot number> <primary version>
For example: loadrev <axsm slot> 2.0(11.3)
Step 6 After the standby AXSM card comes backup in standby mode, issue the "RUNREV" command for the active card.
runrev <slot number> <primary version>
For example: runrev <axsm slot> 2.0(11.3)
Step 7 After the AXSM card comes backup in standby mode, issue the "COMMITREV" command for the AXSM cards.
commitrev <slot number> <version>
For example: commitrev <axsm slot> 2.0(11.3)
Repeat steps 6-7 for all redundant AXSM cards.
Loading the runtime images from 2.0.02 to 2.0.11
For Redundant Systems
Upgrade the standby PXM45 boot code by using the following steps:
Step 1 - type "sh" to go to the shellconn
Step 2 - issue "sysBackupBoot" command
Step 3 - hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove()
Step 4 - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
Step 5 Reset the standby card by issuing "reboot" command. Wait until the standby card goes to "ready" state.
Step 6 Perform a switchcc. When the former active comes up standby, upgrade its boot code by following steps 1-5 above.
Step 7 Use the "SETREV" command to load the 2.0.11 release:
setrev <slot number> <primary version>
For example: setrev 7 2.0(11.3)
Step 8 Replace SCT.2 and SCT.3 with new SCT on Disk.
Step 9 To upgrade the AXSM runtime, issue the "setrev" command for the AXSM.
For example: setrev <axsm slot> 2.0(11.3)
For non-redundant systems, please follow these steps
Step 1 Upgrade the PXM45 boot code. - type "sh" to go to the shellconn
a. - issue "sysBackupBoot" command
b. - hit return when prompted to do so to stop auto-boot
c. - issue the sysFlashBootBurn <"filename"> command where the filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.011.001_bt.fw"
d. - enter "y" to confirm
Step 2 Use the "SETREV" command to load the 2.0.11 release:
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.
</ |
