Table Of Contents
Release Notes for Cisco WAN MGX 8850 Switch Software Release 2.0.14
Contents
Introduction
PNNI Features in Release 2.0.14
System Requirements
Hardware Supported
AXSM Cards
PXM45 Cards
Software Compatibility
Compatibility Matrix
Release 2.0.14 System Content
Additional Deliverables for Release 2.0.14
Upgrading to a New Software Release
Upgrading PXM45 Boot and Runtime Images from 2.0.12/2.0.13 to 2.0.14
Upgrading AXSM Boot and Runtime Images from 2.0.12/2.0.13 to 2.0.14
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.14
Obsoleted Features in Release 2.0.14:
Installation Notes and Cautions
Limitations and Restrictions
Important Notes
BITS Clock Source Configuration
APS Management Information
Recommendations
Documentation Correction — Feeder Configuration
Known Anomalies in Release 2.0.14
Problems Fixed in Release 2.0.14
Known Anomalies found In Previous Releases
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 WAN MGX 8850 Switch Software Release 2.0.14
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.14. 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.14
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 compatability requirements.
Hardware Supported
The following table lists support hardware for Release 2.0.14:
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 relase 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 relase 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 relase 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.
Software Compatibility
This section describes the software and SNMP MIBs that are provided with Release 2.0.14.
Compatibility Matrix
The following compatibility matrix lists the software that is compatible for use in a switch running Release 2.0.14 software.
Board Pair
|
Boot Software
|
Minimum
Boot Software
|
Runtime Software
|
Latest
Software
Version
|
Minimum
Software
Version
|
PXM45, PXM45/B
|
pxm45_002.000.014.000_bt.fw
|
2.0.14
|
pxm45_002.000.014.004_mgx.fw
|
2.0.14
|
2.0.14
|
AXSM-1-2488
|
axsm_002.000.014.000_bt.fw
|
2.0.14
|
axsm_002.000.014.004.fw
|
2.0.14
|
2.0.14
|
AXSM-16-155
|
AXSM-4-622
|
AXSM-16-T3/E3
|
Cisco MGX 8850 Release 2.0.14 interoperates with CWM 10.4.
Cisco MGX 8850 Release 2.0.14 supports feeder connections from Cisco MGX 8850 Release 1.1.32. Please see the 1.1.32 Release Notes for feeder feature issues.
Cisco MGX 8850 Release 2.0.14 operates with CiscoView 5.2 (package 4.43).
Release 2.0.14 System Content
The following software files are supplied with the 2.0.14 release:
•Boot software
–axsm_002.000.014.000_bt.fw
–pxm45_002.000.014.000_bt.fw
•Runtime software
–axsm_002.000.014.004.fw
–pxm45_002.000.014.004_mgx.fw
Additional Deliverables for Release 2.0.14
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 this release, Release 2.0.14.
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.12/2.0.13 to 2.0.14
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.014.000_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.14 software on the standby card (this command is executed on the active PXM45 card):
loadrev <slot number> <version>
For example: loadrev 7 2.0(14.4)
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.14 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(14.4)
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(14.4)
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.014.000_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.14 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.12/2.0.13 to 2.0.14
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. For example:
burnboot <AXSM slot> 2.0(14)
Step 3 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(14.4)
Step 4 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(14.4)
Step 5 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(14.4)
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(14)
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(14.4)
runrev <AXSM slot> 2.0(14.4)
commitrev <AXSM slot> 2.0(14.4)
Repeat these steps for all non-redundant AXSM cards.
New and Changed Information
This section describes new and changed commands in release 2.0.14.
New CLI Commands
The following new CLI commands have been added to 2.0.14:
•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, Architure 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 ths 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.14
There are no new features in this release.
Obsoleted Features in Release 2.0.14:
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, 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.14) with PXM45 and PXM45/B is 99.
In future releases of MGX 8850 with PXM45/B, the maximum number of logical interfaces supported will be 3199. The PXM45 module will always support a maximum of 99 logical interfaces.
The maximum number of signalling interfaces in Release 2.0 and future releases 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 ccommand 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.11 (number 2 and 3, which are included in the 2.0.14 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 Release 2.0.14
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
|
|
CSCdt27029
|
Symptom:
AXSM switch over and PXM45 switch overs when AXSM cards inserted.
Condition:
AXSM cards were reseated.
Workaround:
UNKNOWN
|
CSCdt28983
|
Symptom:
APS switching does not meet Signal Degrade Threshold requirements for switching.
Condition:
Errors were injected at the threshold levels specified for Signal Degrade conditions to be reported.
Workaround:
UNKNOWN
|
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
|
CSCdt77590
|
Symptom:
Large number of connections went into mismatch due to cross-commit failure.
Condition:
switchredcd was executed.
Workaround:
UNKNOWN
|
CSCdt79310
|
Symptom:
dsppnportrsrc command for the port shows MinTx Cellrate and Min Tx Cell rate same as the Max Tx Cell rate for each service category.
Condition:
When partition minimum bandwidth is configured the same as the partitions maximum bandwidth and when the interface policy is not applied in the service module (AXSM).
Workaround:
cnfpnportcac for the port again will fix it.
|
CSCdt80857
|
Symptom:
Failed to cc to active AXSM card on a redundant AXSM pair.
Condition:
Not known
Workaround:
Reset the card.
|
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
|
Symptoms:
Occasionally, when bringing down 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.
|
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.
Conditions:
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.
|
CSCdt09931
|
Symptom:
After switchcc, newly active PXM45 goes onto internal oscillator.
Condition:
External bits input is used for both primary and secondary clock sources.
Workaround:
UNKNOWN
|
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
|
CSCdt14045
|
Symptom:
After AXSM card reset, data transfer stopped and LCNs could not be accessed via tstdelay and dspvsicons commands.
Condition:
Spontaneous AXSM card reset.
Workaround:
UNKNOWN
|
CSCdt19813
|
Symptom:
Software error reset core dumps observed on PXM45.
Condition:
Cyclic switchcc commands and fault insertion tests were being performed.
Workaround:
UNKNOWN
|
CSCdt20397
|
Symptom:
PXM45 failed its nativity check.
Condition:
Can't give up mastership Fault Insertion test was being conducted.
Workaround:
UNKNOWN
|
CSCdt20435
|
Symptom:
PXM45 failed its nativity check.
Condition: Can't give up mastership Fault Insertion test was being conducted.
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
|
CSCdt33442
|
Symptom:
AXSM OC12 does not report LOCD alarm.
Condition:
When cell delineation is lost on incoming OC12 SONET signal.
Workaround:
No workaround.
|
CSCdt38180
|
Symptom:
Trunk port counters resetting while channel counters overflowing.
Condition:
It seems that the "Arrival of CLP0 Cells" counters of the channel count are saturating at 32-bit level and giving that reading. But the trunk port counters may be resetting at some point which explains why the trunk port numbers are less than the channel counter numbers.
Workaround:
UNKNOWN
|
CSCdt38630
|
Symptom:
Configure an intercard APS with the working line index on the active card and the protection line index on the standby card. Let us have the working line as the active line to begin with. Now perform a switchapsln so that the protection line is active. At this point, the active card is working off the protection line (which is physically connected to the standby's back card) and vice versa. Now, pull out the working line (which is the line going to the back card of the active AXSM). Notice that the standby AXSM's LED goes RED. This is because the standby card is "tuned" to the working line. However, this is confusing to the user because it gives a false impression that the line connected to the standby AXSM has failed.
Condition:
As explained above.
Workaround:
The user needs to be aware that in an intercard APS case where the active AXSM is working off a line which is physically connected to the standby's back card and vice versa, the LED reports may be misleading.
|
CSCdt39409
|
Symptom:
AXSM card is in failed state.
Condition:
Downloading of AXSM image to AXSM card is not successful.
Workaround:
None
|
CSCdt43267
|
Symptom:
Active PXM45 card in slot 7 was not responding and showed a major alarm with red LED. Removed the card and the standby card in slot 8 became active.
Condition:
Unknown
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
|
CSCdt47634
|
Symptom:
Statistics files are being generated on the switch, though statistics collection is disabled on CWM.
Condition:
UNKNOWN
Workaround:
UNKNOWN
|
CSCdt49664
|
Symptom:
Device driver error core dumps.
Condition: UNKNOWN
Workaround:
UNKNOWN
|
CSCdt51104
|
Symptom:
Burning backup boot to PXM45 flash causes the system to hang when the flash device is not working.
Condition:
Bad flash device causes the system to hang while the flash is being programmed.
Workaround:
none
|
CSCdt51174
|
Symptom:
Card stuck in programming due to momentary flash failure.
Condition:
Inserted flash failure by changing the switch 2-8 to ON position.
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
|
CSCdt53957
|
Symptom:
Changing IP address of node caused standby PXM45's ethernet interface to go active.
Condition:
Single IP address scheme is being used.
Workaround:
UNKNOWN
|
CSCdt55216
|
Symptom:
Loss of activity messages are logged in the event log for the Priority 1 clock source when secondary clock source is configured.
Condition:
Secondary clock source is configured; both primary and secondary clock sources are external BITS 1 and 2 inputs.
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:
|
