Table Of Contents
Release Notes for Cisco MGX 8850 Software Release 2.0.16
Contents
Introduction
PNNI Features in Release 2.0.16
System Requirements
Hardware Supported
AXSM Cards
PXM45 Cards
Compatibility Matrix
Release 2.0.16 System Content
Additional Deliverables for Release 2.0.16
Upgrading to a New Software Release
Upgrading PXM45 Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15
Upgrading AXSM Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15
New and Changed Information
New CLI Commands
Changed CLI Commands
addcon
clrxbaralms
dspalm
dspalms
dspapsln
dspapslns
dspln
dsplns
dspxbaralms
saveallcnf
New Features in Release 2.0.16
Obsoleted Features in Release 2.0.16
Installation Notes and Cautions
Limitations and Restrictions
Important Notes
BITS Clock Source Configuration
APS Management Information
Recommendations
Documentation Correction — Feeder Configuration
Known Anomalies in This Release
Problems Fixed in Release 2.0.16
Problems Fixed in Release 2.0.15
Known Anomalies found In Previous Releases
Problems Fixed in Release 2.0.14
Problems Fixed in Release 2.0.13
Problems Fixed in Release 2.0.12
Problems Fixed in Release 2.0.11
Problems Fixed in Release 2.0.10
Problems Fixed in Release 2.0.02
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Contacting TAC by Using the Cisco TAC Website
Contacting TAC by Telephone
Service and Support
Release Notes for Cisco MGX 8850 Software Release 2.0.16
Contents
Introduction
These release notes describe the PNNI features, system requirements, upgrade procedures, command Line Interface (CLI) changes, and limitations that apply to Release 2.0.16. These notes also contain Cisco support information. Follow-on releases are planned to add new features, and can be found in the Marketing Road Map.
PNNI Features in Release 2.0.16
Defined by the ATM Forum for ATM networks, PNNI provides a dynamic routing protocol, is responsive to changes in network resource availability, and scales 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 a 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 quality of service (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 can 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:
•
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
These 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.
System Requirements
This section describes the hardware supported in this release and the software compatibility requirements.
Hardware Supported
The following table lists supported hardware for Release 2.0.16:
Model
|
800 Part Number
|
Revision
|
PXM45
|
800-06147-07
|
A0
|
PXM45/B
|
800-09266-03
|
A0
|
PXM-UI-S3
|
800-05787-02
|
A0
|
PXM-HD
|
800-05052-03
|
A0
|
AXSM-1-2488
|
800-05795-05
|
A0
|
SMFSR-1-2488
|
800-05490-05
|
A0
|
SMFXLR-1-2488
|
800-05793-05
|
A0
|
SMFLR-1-2488
|
800-06635-04
|
A0
|
AXSM-16-155
|
800-05776-06
|
A0
|
AXSM-4-622
|
800-05774-09
|
A0
|
AXSM-16-T3/E3
|
800-05778-08
|
A0
|
SMFIR-2-622
|
800-05383-01
|
A0
|
SMFLR-2-622
|
800-05385-01
|
A0
|
SMB-8-T3
|
800-05029-02
|
A0
|
SMB-8-E3
|
800-04093-02
|
A0
|
MMF-8-155
|
800-04819-01
|
A0
|
SMFIR-8-155
|
800-05342-01
|
A0
|
SMFLR-8-155
|
800-05343-01
|
A0
|
APS RDNT CON
|
800-05307-01
|
A0
|
AXSM Cards
The AXSM card is a double-height ATM service module that is compatible with release 2.0 and later PXM45 based versions of the MGX switch. The AXSM card uses the serial line traces on the MGX chassis to access the 45Gbps crosspoint fabric of the PXM45 card and the STRATM48 ASIC technology to accommodate a full duplex throughput of OC48c/STM16.
The AXSM card provides ATM switching and line functionality, and is compatible with the feature set of the BXM card on the BPX, the UXM card on the IGX, and the AUSM card of the MGX 8850 Release 1. Other Cisco ATM platforms and other ATM manufacturers' equipment have proven to be compatible.
Line Interfaces for the AXSM Cards
The AXSM cards supported in this release can provide the following types of line interfaces:
•T3/E3
8 ports per back card, 2 back cards per double height slot
G.703/Accunet Conformance
•OC3c/STM1
G.703/GR-253 Conformance
8 optical ports per back card, 2 back cards per double height slot
MMF, SMF intermediate and long reach
4 port Electrical back card
•OC12c/STM4
G.703/GR-253 Conformance
2 optical ports per back card, 2 back cards per double height slot
SMF intermediate and long reach
•OC48c/STM16
G.703/GR-253 Conformance
Single optical port back card, one back card per double height slot
SMF Short, long and extra-long reach
ATM Layer Information
The AXSM cards supported in this release provide the following ATM features:
•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
The AXSM cards supported in this release provide the following 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 card offers a complete ATM feature set and allows the MGX 8850 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 MGX 8850 platform. The entirely standards-based design and connection protocols enable installation into any existing network, as well as building new ATM infrastructures.
PXM45 Cards
The PXM45 card is a 45-Gbps processor switch module. The architecture of the PXM45 card contains the CellBus fabric that is used in the current PXM-1 card, but adds the functionality of a 45-Gbps crosspoint switching capacity. This allows for the use of the serial line broadband cards (AXSM) in the MGX 8850. The PXM45 card 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 Features
The PXM45 card is designed to operate with another PXM45 card in a redundant configuration. There are two dedicated slots in the MGX 8850 (double height slots 7 and 8) that house the PXM45 card. Highlights of the reliability, availability and serviceability (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 ensures that if one or both hard disks fail, 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 PXM45 cards in a system. This was calculated at greater than 100,000 hours.
Compatibility Matrix
The following compatibility matrix lists the software that is compatible for use in a switch running Release 2.0.16 software.
Board Pair
|
Boot Software
|
Minimum
Boot Software
|
Runtime Software
|
Latest
Software
Version
|
Minimum
Software
Version
|
PXM45, PXM45/B
|
pxm45_002.000.016.000_bt.fw
|
2.0.16
|
pxm45_002.000.016.000_mgx.fw
|
2.0.16
|
2.0.16
|
AXSM-1-2488
|
axsm_002.000.016.000_bt.fw
|
2.0.16
|
axsm_002.000.016.000.fw
|
2.0.16
|
2.0.16
|
AXSM-16-155
|
AXSM-4-622
|
AXSM-16-T3/E3
|
Cisco MGX 8850 Release 2.0.16 interoperates with CWM 10.4.01.
Cisco MGX 8850 Release 2.0.16 supports feeder connections from Cisco MGX 8850 Release 1.1.34. Please see the 1.1.34 Release Notes for feeder feature issues.
Cisco MGX 8850 Release 2.0.16 operates with CiscoView 5.2 (package 3.44).
Release 2.0.16 System Content
The following software files are supplied with the 2.0.16 release:
•Boot software
–axsm_002.000.016.002_bt.fw
–pxm45_002.000.016.002_bt.fw
•Runtime software
–axsm_002.000.016.002.fw
–pxm45_002.000.016.002_mgx.fw
Additional Deliverables for Release 2.0.16
The SNMP MIB for this release is mibs2014.
Upgrading to a New Software Release
This section contains installation and upgrade instructions. For complete details, refer to the MGX 8850 Switch Software Configuration Guide, part 78-12629-01, which describes the installation of software Release 2.0.12 and higher.
Tips Before upgrading, turn off PXM45 online diagnostics. There was a problem (CSCdt46582) where the AXSM card reset during a switchcc. This problem has been fixed with Release 2.0.15.
Note Note, after upgrading from 2.0.14, customers may notice channel alarms (mismatch of the connections for a few connections up to about 200 connections. Also, the customers may see a traffic drop on the same connections. This may last for 15 to 30 minutes depending upon the number of channel alarms. This problem has been fixed with the 2.0.15 release.
Note In this release, you can upgrade the boot or runtime software on only one AXSM card at a time. (See CSCdt51884) For example, you cannot start a burnboot command on one AXSM card if the burnboot command is still operating on another AXSM card.
When upgrading your node, upgrade the software in the following order:
Step 1 PXM45 boot software
Step 2 PXM45 runtime software
Step 3 AXSM boot software
Step 4 AXSM runtime software
The following sections describe how to upgrade PXM45 and AXSM cards.
Upgrading PXM45 Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15
The following procedure is for redundant PXM45 cards.
Step 1 Copy files to the switch.
Step 2 On the standby card, type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command. This will reboot the standby card
Step 4 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().
Step 5 Issue the sysFlashBootBurn <"filename"> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.015.002_bt.fw"
Step 6 Reset the standby card by issuing the reboot command. Wait until the standby card goes to the Standby/Active state.
Step 7 Enter the switchcc command. When the former active card comes up standby, upgrade its boot code by following steps 2 - 6 above.
Step 8 Use the loadrev command to load the Release 2.0.15 software on the standby card (this command is executed on the active PXM45 card):
loadrev <slot number> <version>
For example: loadrev 7 2.0(15.2)
Step 9 After the standby card comes back up with the new image in the Standby/Active state, use the runrev command to load the Release 2.0.15 software 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(15.2)
Step 10 After the redundant card comes up in the Standby/Active state, issue the command commitrev to commit your node to the current release. Once commitrev is issued, abortrev is no longer valid. Note, you should issue the commitrev before provisioning any more connections.
commitrev <slot number> <version>
For example: commitrev 8 2.0(15.2)
The following procedure is for non-redundant PXM45 cards.
Step 1 Copy files to the switch.
Step 2 On the PXM45 card, type sh to go to the shellconn.
Step 3 Issue the sysBackupBoot command. This will reboot the standby card
Step 4 Hit return when prompted to do so to stop auto-boot, then issue the command sysPxmRemove().
Step 5 Issue the sysFlashBootBurn <"filename"> command, where filename includes the full path.
sysFlashBootBurn "C:FW/pxm45_002.000.015.002_bt.fw"
Step 6 Reset the card by issuing the reboot command. Wait until the card goes to the Active state.
Step 7 Use the loadrev, runrev, and commitrev commands to load the Release 2.0.15 software on the card. Once commitrev is issued, abortrev is no longer valid. Note, you should issue the commitrev before provisioning any more connections
Upgrading AXSM Boot and Runtime Images from 2.0.13/2.0.14 to 2.0.15
The following procedure is for redundant AXSM cards.
Step 1 Copy files to the switch.
Step 2 To upgrade the AXSM boot code, issue the burnboot command on the standby AXSM. For example:
burnboot <AXSM slot> 2.0(15)
Step 3 Issue switchredcd command.
Step 4 Upgrade the AXSM boot code on the new STANDBY card.
burnboot <AXSM slot> 2.0(15)
Step 5 To upgrade redundant AXSM cards with the new runtime image, issue the loadrev command for the standby card.
loadrev <slot number> <version>
For example: loadrev <AXSM slot> 2.0(15.2)
Step 6 After the standby AXSM card comes back up in standby mode, issue the runrev command for the active card
runrev <slot number> <version>
For example: runrev <AXSM slot> 2.0(15.2)
Step 7 After the AXSM card comes back up in standby mode, issue the commitrev command for the AXSM cards.
For example: commitrev <AXSM slot> 2.0(15.2)
Repeat these steps for all redundant AXSM cards.
The following procedure is for non-redundant AXSM cards.
Step 1 Copy files to the switch.
Step 2 To upgrade the AXSM boot code, issue the burnboot command. For example:
burnboot <AXSM slot> 2.0(15)
Step 3 To upgrade non-redundant AXSM cards with the new runtime image, issue the loadrev, runrev and commitrev commands for each AXSM card.
For example:
loadrev <AXSM slot> 2.0(15.2)
runrev <AXSM slot> 2.0(15.2)
commitrev <AXSM slot> 2.0(15.2)
Repeat these steps for all non-redundant AXSM cards.
New and Changed Information
This section describes new and changed commands since the 2.0.12 release.
New CLI Commands
The following new CLI commands have been added since the 2.0.12 release:
•dsppathtracenode, which displays the configuration created with pathtracenode
•dsppathtraceport, which displays the configuration created with pathtraceport
•dsppathtraceie, which displays the configuration created with pathtraceie
Changed CLI Commands
The following sections describe CLI commands that have changed in this release.
addcon
The addcon error message that appears when provisioning an SPVC to use a previously configured (duplicate) vpi and vci has been changed from "ERROR: No Such Connection endpoint present" to "ERROR: Specified vpi/vci not available."
clrxbaralms
The clrxbaralms command has been removed. It is a duplicate of clrxbaralm.
dspalm
The dspalm command has been modified to display an additional row of alarm information. For example:
The Alarm State will be same as that shown for dsplns. For non-APS lines, the alarm state is "N/A" The rest of the Alarm values shown apply to the 'Active Line'.
dspalms
The display for the dspalms commands is similar dspalm.
dspapsln
The dspapsln command needs to be entered with both the WLineID and the PLineId. The 'Alarm' shown is not an integrated alarm but is for the LineId that was entered. The 'Alarm' will now show the following are the alarm levels:
•SF-L: signal fail low
•SF-H: Signal fail High
•SD-L: signal degrade low
•SD-H: signal degrade High
•PSBF: Protection Switch Byte Failure
•MIS: Directional mismatch, architecture mismatch, or Channel mismatch (Note that although this is configuration mismatch. APS should still function properly)
•OK: No Alarm
The Alarm states shown are independent of the APS line 'cross.'
Note During an AXSM card switch over, there might be a brief period during which MIS is reported. This means the APS operation has gone to 1+1 unidirection mode temporarily.
dspapslns
The dspapslns command previously reported two alarm states: OK and ALM. This command now shows the same alarm levels as the updated dspapsln command. The alarms shown are independent of the APS line 'cross.'
dspln
The dspln command displays an 'Alarm' column that shows the integrated alarm status for the APS line pair. It only shows line level alarms. The possible levels are:
•Critical -- If Active line is in Alarm
•Major -- If non-active line is in Alarm
•None -- If both lines are free of line level alarms
•N/A -- If there is no APS configuration on this line
dsplns
The dsplns command displays the same alarm status as dspln.
dspxbaralms
The dspxbaralms command has been removed. It is a duplicate of dspxbaralm.
saveallcnf
The saveallcnf command response has changed to the following:
Unknown.7.PXM.a > saveallcnf -v
The 'saveallcnf' command can be time-consuming. The shelf
must not provision new circuits while this command is running.
Do not run this command unless the shelf configuration is stable
or you risk corrupting the saved configuration file.
The save command will only store the
2 most recent saved files in C:/CNF directory.
If you have 2 or more files already saved in C:/CNF,
the older ones will be deleted by the current save,
keeping the 2 most recent.
saveallcnf: Do you want to proceed (Yes/No)? y
New Features in Release 2.0.16
There are no new features in this release.
Obsoleted Features in Release 2.0.16
No features are obsoleted in this release.
Installation Notes and Cautions
•If any AXSM cards remain in INIT state and the PXM45 standby card is reset, the PXM45 standby card will not transit back to standby. This is a DB server limitation.
•(CSCdt05425) If the active AXSM has some non-default interface policy configured, then the standby card might not be in sync with the active card. This will also affect the upgrade of the cards to the new version. The user will have to follow the procedure for a non-graceful upgrade for the new version.
If the default interface policy is being used, then the redundancy/graceful upgrade is possible.
The redundancy/upgrade will also work if the interface policy is configured for 3 or fewer ports (as the interface policy for 4 or more ports does not get synced to standby).
Note that AXSM Redundancy works after the customer has upgraded to 2.0.12. The AXSM Redundancy problem only exists in versions 2.010 and 2.0.11.
•When removing AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.
•On feeder trunks, tstdelay works only when the OAM cells are disabled on the segment endpoints. To disable OAM cells, use the following procedure:
Step 1 dpnport <portid>
Step 2 cnfpnportsig <portid> -cntlvc ip
Step 3 cnfoamsegep <portid> no
Step 4 uppnport <portid>
•(CSCdt09949) Currently the CLI command addchanloop does not store the connection loop state as persistent data. As a result, this loop (ingress and egress) state of a connection will be lost after the following operations:
–resetcd
–resetsys
–dncon followed by upcon
–controller resync (dnport followed by upport)
–switchredcd
–reroute (dnport)
•PNNI default minimum VCI is 35 unless changed explicitly. The reason for the default is to reserve VCI=32-34 for other control purposes such as MPLS and NCDP. For users who would like to add an MPLS controller in future releases of the Cisco MGX 8850 switch, it is highly recommend to set the minimum 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 signaling VC for MPLS will be established automatically on 0/32.
•By default, 900 cps and 543 cps will be reserved for the SSCOP and PNNI signalling VCs, respectively, even when you disable SSCOP and PNNI. These values are configurable through the cnfpnctlvc command.
•The database stores the backplane serial number and back card serial numbers. Therefore if cards are moved from one node to another, and the card tries to become ACTIVE, the console will display "SHM Alert!! Alert!!." In this situation follow these steps:
Step 1 Enter shmFailDisplay. A display table will show that BRAM is not native.
Step 2 Enter shmFailRecoveryHelp. This will indicate that to "Ignore Nativity and Rebuild from Disk" the command to use is shmRecoverIgRblDisk.
Step 3 Enter shmRecoverIgRbldDisk.
•Do not execute delcontroller when connections or ports still exist. If you do enter delcontroller and later want to recover the connections, you must re-added the controller using addcontroller and reset the AXSM cards or the entire node (otherwise ports remain in provisioning state). There is now a warning about the impact of the command when there are existing connections or ports.
•(CSCds70478) Currently, Humvee error reporting is turned off for the AXSM cards. They are however logged.
•Analysis of the code has identified a situation which has a low probability of occurring and in fact 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 reduce the usage of that link.
•To replace one type of AXSM front card with another type, all connections, partitions, and ports must be deleted, and all lines must be brought down. If an AXSM card fails, the same type of AXSM card must be installed in that slot so that communications can be resumed or so that the configuration can be changed to prepare for a new card type.
Limitations and Restrictions
The following are known limitations or restrictions for this release:
•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in Release 2.0 baseline (2.0.10-2.0.16) with PXM45 and PXM45/B is 99.
The maximum number of signalling interfaces in Release 2.0 of MGX 8850 is 99. Signalling interfaces are those running a protocol such as PNNI, IISP, AINI or supporting SVC/SVP.
Interfaces on standby or redundant cards are not counted.
•APS working line must be 1 line lower than the protection line. For example, 1 is the working link and 2 is the protection line. Having 1 as the protection and 2 as the working line is not allowed.
•If the destination address is reachable through both IISP and PNNI links on 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.
•A port or card SCT can be changed while connections are present in this release. However, if the SCT change affects active connections, those connections will be rerouted.
•(CSCds41609) 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.
•When CWM is use to manage the network, the IP address 10.0.x.x cannot be used as the LAN address (lnPci) for the switch.
•If you would like to add an MPLS partition on a port where other partitions have already been added and the minimum vci value is 32, you have two options:
–After the MPLS controller is added, explicitly add the TDP sig vc using a vpi/vci pair within its partition's resource range.
–Do a dnport and cnfpart to move the minimum vci to 35 for all partitions on the port.
•(CSCdr15911) Changing or reseating an AXSM OC48 back card several times may sometimes cause the front card to reset and interrupt service. The PhyTask also gets suspended. To avoid this problem, try not to reseat the back card too often. If the front card does not start when the switch power is turned on, try to reseat the front and back card to bring up the system.
Important Notes
The following sections provide additional information on BITS clock source configuration, APS operation in this release, and recommendations for setting the control VC parameters.
BITS Clock Source Configuration
The Cisco MGX 8850 Software Configuration Guide incorrectly lists four port numbers for the two BITS clock ports on the back of the PXM-UI-S3 card. During configuration (using the cnfclksrc command), the correct port number to use for the upper clock port is 35. The correct port number for the lower clock port is 36.
APS Management Information
The following tips apply to the use of the dspapsbkplane command and the APS connector which is sometimes call a back plane. The APS connector must be installed to enable intercard APS.
•The dspapsbkplane command shows whether the APS connector is plugged in properly. It should be used only when the standby card is in Ready state. When the standby card is booting or fails, intercard APS cannot work properly and this command displays "NOT ENGAGED."
•APS must be configured on a line pair before the dspapsbkplane command can display the APS connector status. If APS is not configured on a line, the dspapsbkplane command displays the message "Aps Line Pair does not exist."
•The dspapsbkplane command needs to be executed on both the active & standby cards to ensure that APS connector is engaged properly. This command can show different values for each of the two cards, which indicates the APS connector is seated properly on one card but not on the other.
•The APS connector status is the same for all lines in a single bay. This is because the APS connector interconnects two back cards within the same bay. To check the APS status for an AXSM card that hosts ports in the upper and lower bays, you must enter the dspapsbkplane command twice, once for a line in each bay.
Caution When using intercard APS, ensure the APS connector is correctly installed. Refer to the "APS Backplane" section in Chapter 4 of the "Cisco MGX 8850 Hardware Installation Guide." This guide is part number 78-10351-04, and can be ordered from Cisco Marketplace or downloaded from
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/20x/hig/index.htm. After you install the assembly, verify that the APS connector is properly installed by using the new CLI command
dspapsbkplane.
Note (CSCdu19732) If there are APS configurations on a card and some lines are disconnected, avoid performing switchredcd, front card removal, or back card removal. Before removing an active front card or back card, which results in a card switch over, switch cards with the switchredcd command.
Recommendations
Cisco Systems recommends you 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 that you must use the SCT files released with 2.0.11and above (number 2 and 3, which are included in the 2.0.16 release) for the control VC feature.
Documentation Correction — Feeder Configuration
In the Cisco MGX 8850 Software Configuration Guide, Chapter 4, Step 2 in the Feeder Configuration Quickstart incorrectly states that an IP address must be entered with the cnfpnportsig command to support CWM management. The correct syntax for the command is:
pop20two.7.PXM.a > cnfpnportsig <portid> -cntlvc ip
The ip component of the command should be entered as shown above. Do not replace this component with an IP address.
Known Anomalies in This Release
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
|
|
CSCdt54958
|
Symptom: OC12 p-p jitter amplitude exceeded the 0.10 UI pp.
Condition: Unknown
Workaround: None
|
CSCdt76379
|
Symptom: Connections went into conditioning state after a switchcc was executed.
Condition: switchcc was executed after PXM45s were replaced.
Workaround: UNKNOWN
|
CSCdu12856
|
Symptom: 1000+ SPVCs failed during a 2.0.12-2.1.00 upgrade.
Condition: burnboot procedure was executed on standby PXM45 and switchcc was then executed.
Workaround: UNKNOWN
|
CSCdu15569
|
Symptom: APS working lines and protection lines in alarm.
Condition: Removing the front card.
Workaround: None
|
CSCdu16640
|
Symptom: Traffic loss, PNNI links resetting.
Condition: Problem is caused by hardware failure.
Workaround: switchcc may help if load sharing is not enabled.
|
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.
|
CSCdr91301
|
Symptom: Upon AXSM reset, ILMI on some ports on the said AXSM may go into "disabled" state.
Condition: This is a very rare situation and has been observed twice in the past six months of testing.
Workaround: Bring down the port and then bring it back up.
|
CSCds24362
|
Symptom: Occasionally, when bringing down a UNI port (dnport) on AXSM followed by upport, some VSIErr are displayed on the AXSM console.
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 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.
|
CSCds74270
|
Symptom: When performing Bulk Sync (when standby AXSM first arrives), some VsiErrs were observed on the active AXSM and the standby AXSM might not have all the connections.
Condition: This happens when intraslave connections (between two ports) were added on the AXSM. If one of the ports was admin downed followed by inserting or resetting the standby AXSM.
Workaround: Initiate another Bulk Sync (by resetting the standby AXSM) after the port is upped.
|
CSCdt05371
|
Symptom: Traps were not generated for hard disk failure during fault insertion testing.
Condition: Hard disk failure was simulated on modified PXM45s.
Workaround: UNKNOWN
|
CSCdt05378
|
Symptom: Switchover to faulty standby PXM45 allowed during fault insertion testing.
Condition: Hard disk failure was simulated on the standby PXM45.
Workaround: UNKNOWN
|
CSCdt05383
|
Symptom: PXM45 switchover did not occur when hard disk failure simulated on active PXM45 during fault insertion testing.
Condition: Hard disk failure was simulated on active PXM45.
Workaround: UNKNOWN
|
CSCdt05385
|
Symptom: No alarms reported when hard disk failure on active PXM45.
Condition: Hard disk failure was simulated on active PXM45.
Workaround: UNKNOWN
|
CSCdt05387
|
Symptom: Hexadecimal characters appeared on telnet session and access to system via telnet and console port access was then lost.
Condition: Hard disk failure was simulated on active PXM45.
Workaround: UNKNOWN
|
CSCdt06427
|
Symptom: OC12 AXSM card does not declare receiving incoming RDI-P alarm.
Condition: When OC12 line is receiving RDI-P.
Workaround: No workaround.
|
CSCdt09949
|
Symptom: Channel loops are randomly being knocked down.
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdt13133
|
Symptom: Device driver core dumps recorded on PXM45.
Condition: Nodes had experienced power outages the previous day, and had to have their PXM45s reseated as part of the recovery process.
Workaround: UNKNOWN
|
CSCdt21157
|
Symptom: SPVC did not connect even when crankback occurred.
Condition: Crankback occurred after a connect was issued by the destination node, and a VPI mismatch condition was detected by the originating node.
Workaround: UNKNOWN
|
CSCdt25070
|
Symptom: Node alarms and traps are not generated on High Speed serial link errors.
Condition: High Speed serial link error injected during Fault Insertion Testing.
Workaround: UNKNOWN
|
CSCdt29629
|
Symptom: APS switching is blocked for 1+ minute after alarm cleared.
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdt30131
|
Symptom: Incoming RDI-L, RDI-P not declared and cleared within 100usec.
Condition: Incoming AIS-L.
Workaround: UNKNOWN
|
CSCdt30132
|
Symptom: RDI-L and RDI-P clear times are greater than 100usec.
Condition: LOS is cleared.
Workaround: UNKNOWN
|
CSCdt30133
|
Symptom: RDI-L and RDI-P clear times are greater than 100usec.
Condition: LOF is present and then cleared.
Workaround: UNKNOWN
|
CSCdt30134
|
Symptom: LOS alarm condition is displayed during LOF.
Condition: dspalms and dspalmcnt show LOS condition.
Workaround: UNKNOWN
|
CSCdt30135
|
Symptom: OC12 line code violations do not increment.
Condition: Incoming B2 errors.
Workaround: UNKNOWN
|
CSCdt30137
|
Symptom: OC12 incorrectly generates RDI-L and RDI-P.
Condition: B2 errors are received.
Workaround: UNKNOWN
|
CSCdt30140
|
Symptom: RDI-L and RDI-P clear times after LOF cleared greater than 100usec.
Condition: LOF condition has been cleared.
Workaround: UNKNOWN
|
CSCdt30142
|
Symptom: OS reports Line AIS, Section LOS, LOF and Path RDI.
Condition: Incoming LOF condition.
Workaround: UNKNOWN
|
CSCdt44635
|
Symptom: Watchdog timeout reset core dump observed on PXM45.
Condition: Customer was executing Fault Insertion testing.
Workaround: UNKNOWN
|
CSCdt45669
|
Symptom: PNNI neighbor PTSE database synchronization and other problems after flash failure test during Fault Insertion testing.
Condition: Flash failure test was being conducted.
Workaround: UNKNOWN
|
CSCdt49664
|
Symptom: Device driver error core dumps.
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdt53631
|
Symptom: LOF criteria is not met per R5-225, for AXSM OC12 interface.
Condition: OOF condition is cleared at the presence of three consecutive error free patterns rather than two.
Workaround: UNKNOWN
|
CSCdt53844
|
Symptom: PXM45 did not switchover and all cards went into a continuous reset, during Fault Insertion testing.
Condition: QE0 failure test was being conducted.
Workaround: UNKNOWN
|
CSCdt53886
|
Symptom: Reset type and reset reason observed by user did not match Cisco report.
Condition: PCI bus error Fault Insertion tests were being conducted.
Workaround: UNKNOWN
|
CSCdt53888
|
Symptom: No indication for PCI bus error on active PXM45.
Condition: PCI bus error fault insertion testing was being conducted.
Workaround: UNKNOWN
|
CSCdt53893
|
Symptom: Alarm reporting different for PCI bus errors on standby vs. active PXM45.
Condition: PCI bus error Fault Insertion Testing was being conducted.
Workaround: UNKNOWN
|
CSCdt56749
|
Symptom: Master end of routed connections shows OK, but slave end shows Condn.
Condition: N/A
Workaround: None
|
CSCdt58810
|
Symptom: EPD/PPD value defaulted to disable in SCTs.
Condition: None
Workaround: Create new SCT via CWM with EPD/PDD enabled.
|
CSCdt60594
|
Symptom: QE48 SAR error messages and memory block assignment messages observed in error and event log files.
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdt60669
|
Symptom: Node rebuild occurred when switchcc was executed during Fault Insertion testing.
Condition: QE1 failure test was being conducted.
Workaround: UNKNOWN
|
CSCdt60672
|
Symptom: QE1 failure not recorded during Fault Insertion Testing.
Condition: QE1 failure testing was being done.
Workaround: UNKNOWN
|
CSCdt60673
|
Symptom: Faulty card did not go into continuous reset during QE1 failure.
Condition: QE1 failure testing was being undertaken.
Workaround: UNKNOWN
|
CSCdt60675
|
Symptom: PXM45 did not switchover on LAN port failure.
Condition: Fault Insertion Testing was being conducted.
Workaround: UNKNOWN
|
CSCdt60679
|
Symptom: No indications presented to user when LAN port failure on standby PXM45.
Condition: Fault Insertion Testing was being conducted.
Workaround: UNKNOWN
|
CSCdt60681
|
Symptom: No access to node via LAN.
Condition: LAN port has hardware failure. Driver does not detect and request processor switch over.
Workaround: None. Could use IP Connectivity interface for management as the primary. If not, a manual switchover or rebuild is required.
|
CSCdt60692
|
Symptom: No indication provided via event log or alarm reporting for crossbar failure.
Condition: Crossbar Failure Insertion tests were being conducted.
Workaround: UNKNOWN
|
CSCdt60693
|
Symptom: Serial Link Path failure (Severity 7) is not logged into the event log.
Condition: Serial Link Path Failure Insertion tests were being conducted.
Workaround: UNKNOWN
|
CSCdt60694
|
Symptom: Inconsistent alarm reporting in case of Serial Link Path Failure (should be Major).
Condition: Serial Link Path Failure Insertion tests were being conducted.
Workaround: UNKNOWN
|
CSCdt60696
|
Symptom: Faulty card did not go into continuous reset when encountering parity error on internal Utopia bus on the Active PXM45.
Condition: Utopia bus failure testing was being undertaken on the PXM45.
Workaround: UNKNOWN
|
CSCdt61546
|
Symptom: Faulty card did not go into continuous reset when encountering parity error on internal Utopia bus on the active PXM45.
Condition: Utopia bus failure testing was being undertaken on the PXM45.
Workaround: UNKNOWN
|
CSCdt61581
|
Symptom: Faulty card did not go into continuous reset during Utopia bus parity error failure.
Condition: Utopia bus parity error fault insertion was being undertaken.
Workaround: UNKNOWN
|
CSCdt88532
|
Symptom: APS line went to protect after clearing it under a scenario.
Condition: Change mode when active line is protection line.
Workaround: Execute a clear instruction after the cnfapsln command.
|
CSCdt94483
|
Symptom: dsppnports shows 3 more DAX connections after switchredcd.
Condition: This could happen if there are some failed connections before switchredcd.
Workaround: None
|
CSCdu07255
|
Symptom: APS protection line temporarily going into alarm.
Condition: Issue the switchredcd command.
Workaround: Unknown
|
CSCdu09353
|
Symptom: APS Service Switch request propagates to all bays in APS pair.
Condition: switchapsln command supplied with service switch set to 1.
Workaround: Apply switchapsln command per port instead of service switch.
|
CSCdu09724
|
Symptom: Connection commit failure reported on the standby AXSM.
Condition: During bulkSync, if controller performs massive deroute or reroute activity on the active AXSM, the connection request forwarded to standby may fail.
Workaround: None.
|
CSCdu10677
|
Symptom: dspln shows critical alarm, but dspapsln shows OK.
Condition: None.
Workaround: switchredcd will recover it.
|
CSCdu10731
|
Symptom: switchredcd results in line alarm.
Condition: switchredcd causes both lines to go into alarm.
Workaround: NONE
|
CSCdu11686
|
Symptom: APS lines: disconnected the cable on working line, then switchredcd, most of the time, when the standby card came up, both the working and protect lines were in alarm, and pnport/PNNI link were down.
Condition: This is the double fault APS issue, and it interrupts traffic.
Workaround: None
|
CSCdu13529
|
Symptom: APS switched protection line to working line.
Condition: Issue the switchredcd command or remove and reinstall the back card.
Workaround: Unknown
|
CSCdu14779
|
Symptom: Standby PXM45 card keeps giving the qcPurgeVc fail error message.
Condition: Not Known. Login to standby PXM45 card and message keeps popping out.
Workaround: Not Known
|
CSCdu15972
|
Symptom: Critical alarm seen on the other end after reinsertion of backcard.
Condition: Removal and reinsertion causes critical alarm on the other side.
Workaround: None
|
CSCdu19732
|
Symptom: switchredcd results in line switching. In the case of APS, with the working line removed, a switchredcd would cause the far end to switch back to the working line.
Condition: Data loss as a result of switchredcd.
Workaround: Do not remove the lines when switching cards.
|
CSCdu68756
|
Symptom: AXSM-2/B Off-Line Diagnostics fails.
Condition: This failure occurs whenever the Off-Line Diagnostics is invoked. (The Off-Line Diagnostics is invoked via the cnfdiag command).
Workaround: None
|
CSCdu87251
|
Symptom: 1) For spvc, the fail cause for master ABR spvc (using dspcon) shows Unsupported combination of traffic parameters but the service type and all the traffic parameters match between master and slave.
2) For svc, the release cause is #73 (Unsupported combination of traffic parameters).
Condition: For an ABR connection, if local PCR is greater than remote MCR OR remote PCR is greater than local MCR this problem occurs.
Workaround: Set (localPCR > localMCR) AND (localPCR > remoteMCR)
Set (remotePCR > remoteMCR) AND (remotePCR > localMCR) in ABR connections.
|
CSCdu87850
|
Symptom: DAX connection did go to Fail state
Condition: When removing the card that has the master side of the connection
Workaround: Unknown
|
S3 BUGS
|
|
CSCds17719
|
Symptom: No access to node via LAN.
Condition: 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.
|
CSCds27446
|
Symptom: When performing SPVC reroute and switchover on 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.
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 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 or derouting connections.
|
CSCds42201
|
Symptom: Standby PXM45 card is in continuous reset loop, and all AXSM cards 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
|
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
|
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
|
CSCds4356 |
