Table Of Contents
Release Notes for Cisco MGX 8850 Software Version 2.1.10
Contents
Introduction
System Requirements
Hardware Supported
Hardware Compatibility Matrix
Software Compatibility
Upgrade Path
Additional Deliverables
New and Changed Information
New Hardware Support in Release 2.1.10
AXSM/B Front Cards
MMF-8-155-MT/B
SMB-4-155
SMFIR-8-155-LC/B
SMFLR-8-155-LC/B
New Software Features in Release 2.1.10
Automatic Response to Nativity Check
Stage 1 Command Line Interface
MPLS Interface Policy
Changed Commands
dspalm
dspalms
dspapsbkplane
dspapsln
dspapslns
dspln
dsplns
Removed Commands
Upgrading to a New Software Release
Changes to the Upgrade Procedure
RPM-PR Upgrades
Upgrading with 1:N Redundancy
Upgrading Without Redundancy
Limitations and Restrictions
General Limitations and Restrictions
RPM-PR and MPLS Limitations and Restrictions
APS Management Information
Open APS Issues
APS Events to Avoid
Clearing the Configuration on Redundant PXM45s
Recommendations
Important Notes
General Notes
RPM-PR and MPLS Notes
RPM-PR auto_config File Management
Using tstdelay on Feeder Trunks
Manually Responding to Nativity Checks
Documentation Correction—PNNI Feeder Configuration Quickstart
Caveats
Open Anomalies for Release 2.1.10
Problems Fixed in Release 2.1.10
Open Anomalies from Release 2.1.00
Open Anomalies for MPLS
Problems Fixed in Release 2.1.00
Related Documentation
Obtaining Documentation
Ordering Documentation
World Wide Web
Documentation CD-ROM
Documentation Feedback
Technical Assistance
Cisco.com
Technical Assistance Center
Contacting TAC by Using the Cisco TAC Website
Contacting TAC by Telephone
Release Notes for Cisco MGX 8850 Software Version 2.1.10
Contents
This document contains the following sections:
Introduction
These release notes describe the system requirements, new and changed procedures, upgrade procedures, and limitations that apply to Release 2.1.10. These notes also contain Cisco support information.
System Requirements
This section describes the hardware supported in this release and the software compatibility requirements.
Hardware Supported
Table 1 lists the hardware supported in Release 2.1.10.
Table 1 Hardware Supported in Release 2.1.10
Model
|
800 Part Number
|
Minimum Revision
|
APS RDNT CON
|
800-05307-01
|
A0
|
AXSM-1-2488
|
800-05795-05
|
A0
|
AXSM-4-622
|
800-05774-09
|
B0
|
AXSM-4-622/B
|
800-07910-01
|
A0
|
AXSM-16-155
|
800-05776-06
|
A0
|
AXSM-16-155/B
|
800-07909-01
|
A0
|
AXSM-16-T3E3
|
800-05778-08
|
A0
|
AXSM-16-T3E3/B
|
800-07911-02
|
A0
|
MGX-MMF-FE
|
800-03202-02
|
A0
|
MGX-RJ45-4E/B
|
800-12134-01
|
A0
|
MGX-RJ45-FE
|
800-02735-02
|
A0
|
MMF-8-155-MT
|
800-04819-01
|
A1
|
MMF-8-155-MT/B
|
800-07120-01
|
A0
|
PXM45
|
800-06147-07
|
B0
|
PXM45/B
|
800-09266-03
|
A0
|
PXM-HD
|
800-05052-03
|
A0
|
PXM-UI-S3
|
800-05787-02
|
A0
|
RPM-PR-256
|
800-07178-02
|
A0
|
RPM-PR-512
|
800-07656-02
|
A0
|
SMB-8-E3
|
800-04093-02
|
A0
|
SMB-8-T3
|
800-05029-02
|
A0
|
SMFIR-2-622
|
800-05383-01
|
A1
|
SMFIR-8-155-LC
|
800-05342-01
|
B0
|
SMFLR-1-2488
|
800-06635-04
|
A0
|
SMFLR-2-622
|
800-05385-01
|
A1
|
SMFLR-8-155-LC
|
800-05343-01
|
A1
|
SMFSR-1-2488
|
800-05490-05
|
A0
|
SMFXLR-1-2488
|
800-05793-05
|
A0
|
SMB-4-155
|
800-07425-01
|
A0
|
SMFIR-8-155-LC/B
|
800-07864-01
|
A0
|
SMFLR-8-155-LC/B
|
800-07864-01
|
A0
|
SMFIR-2-622/B
|
800-07412-01
|
A0
|
SMFLR-2-622/B
|
800-07413-01
|
A0
|
Hardware Compatibility Matrix
Table 2 shows which back cards can be used with each front card in Release 2.1.10.
Table 2 Back Cards and Connectors Supported by Front Cards
Front Card Type
|
Back Card Types
|
Supports APS Connector (APS RDNT CON)
|
AXSM-1-2488
|
SMFSR-1-2488 SMFLR-1-2488 SMFXLR-1-2488
|
Yes
|
AXSM-4-622
|
SMFIR-2-622 SMFLR-2-622
|
Yes
|
AXSM-4-622/B
|
SMFIR-2-622/B SMFLR-2-622/B
|
Yes
|
AXSM-16-155
|
MMF-8-155-MT MMF-8-155-MT/B SMFIR-8-155-LC SMFIR-8-155-LC/B SMFLR-8-155-LC SMFLR-8-155-LC/B
|
Yes
|
AXSM-16-155/B
|
SMB-4-155 MMF-8-155-MT/B SMFIR-8-155-LC/B SMFLR-8-155-LC/B
|
Yes
|
AXSM-16-T3E3
|
SMB-8-T3 SMB-8-E3
|
|
AXSM-16-T3E3/B
|
SMB-8-T3 SMB-8-E3
|
|
PXM45
|
PXM-UI-S3
|
|
PXM-HD
|
|
PXM45/B
|
PXM-UI-S3
|
|
PXM-HD
|
|
RPM-PR-256 RPM-PR-512
|
MGX-MMF-FE MGX-RJ45-4E/B MGX-RJ45-FE
|
|
Software Compatibility
Table 3 lists the software that is compatible for use in a switch running Release 2.1.10 software.
Table 3 Software Compatibility Matrix
Board Pair
|
Boot Software
|
Minimum
Boot Code
Version
|
Runtime Software
|
Latest
Firmware
Version
|
Minimum
Firmware
Version
|
PXM45
|
pxm45_002.001.010.003_bt.fw
|
2.1.10.3
|
pxm45_002.001.010.003_mgx.fw
|
2.1.10.3
|
2.1.10.3
|
AXSM-1-2488
|
axsm_002.001.010.003_bt.fw
|
2.1.10.3
|
axsm_002.001.010.003.fw
|
2.1.10.3
|
2.1.10.3
|
AXSM-16-155
|
AXSM-4-622
|
AXSM-16-T3/E3
|
RPM-PR
|
rpm-boot-mz.121-5.2.XT03
|
12.1-5.2.XT03
|
rpm-js-mz.121-5.2.XT03
|
12.1-5.2.XT03
|
12.1-5.2.XT03
|
The following notes provide additional compatibility information for this release:
•MGX 2.1.10 interoperates with SES PNNI 1.0.12 plus BPX Switch Software (SWSW) 9.3.11 plus BXM MFL.
•This release supports feeder connections from Cisco MGX 8850 Releases 1.1.31 and 1.1.32. Please see the 1.1.31 and 1.1.32 Release Notes for feeder feature issues. As of this printing, these release notes are posted at http://www.cisco.com/univercd/cc/td/doc/product/w1anbu/mgx8850/1_1_31/relnote/index.htm.
•You must use CWM 10.4.01 to manage networks that contain MGX 8850 switches running release 2.1.10.
•The RPM-PR software in this release is based on IOS Release 12.1(5.2)XT03.
•The RPM-PR software is different from the RPM software used in Releases 1.1.31/1.1.32 and 2.1.10.
Upgrade Path
This release supports the following graceful upgrades:
•Release 2.0.13 to 2.1.10
•Release 2.0.14 to 2.1.10
•Release 2.1.00 to 2.1.10
Additional Deliverables
The SNMP MIB release for 2.1.10 is mibs2012.
New and Changed Information
This section describes new and changed features and commands in Release 2.1.10.
New Hardware Support in Release 2.1.10
The following new cards are supported by the Release 2.1.10 software:
•AXSM-4-622/B
•AXSM-16-155/B
•AXSM-16-T3E3/B
•MMF-8-155-MT/B
•SMB-4-155
•SMFIR-8-155-LC/B
•SMFLR-8-155-LC/B
Note The AXSM/B cards will be released in a separate release after the Release 2.1.10 software.
The following sections provide additional information on this hardware.
AXSM/B Front Cards
The AXSM/B front cards are double-height ATM service modules that use serial line traces to access the crossbar switching fabric. The AXSM/B optical modules support 1:1 module redundancy and APS. The AXSM/B provides ATM switching and line functions.
The AXSM/B cards support the following features:
•UPC policing on all interfaces except OC48c/STM16
•64 logical interfaces including ports, trunks or virtual trunks on same interface
•16 class-of-service queues with independent queues for each ATM class of service
•PNNI, MPLS, IISP, ILMI 4.0, UNI 3.x, SVC, and SPVC/SPVP
•1M cells of buffering
The following describe each of the new AXSM/B front cards.
Note AXSM/B OC48c/STM16 cards will be supported in a future release.
AXSM-4-622/B
The AXSM-4-622/B is a four-port, OC12c/STM4 front card. The optical back cards for the AXSM-4-622/B provide 2 ports per bay for a total of 4 ports per slot. This card supports the back cards listed in Table 2.
AXSM-16-155/B
The AXSM-16-155/B is an OC3c/STM1 front card that supports both optical and electrical interfaces. The optical back cards for the AXSM-16-155/B provide 8 ports per bay for a total of 16 ports per slot. The electrical interface back card provides 4 ports per bay for a total of 8 ports per slot. The AXSM-16-155/B card supports the back cards listed in Table 2.
AXSM-16-T3E3/B
The AXSM-16-T3E3/B is a 16-port front card that supports T3 and E3 interfaces. The back cards for the AXSM-16-T3E3/B provide 8 ports per bay for a total of 16 ports per slot. This card supports the back cards listed in Table 2.
MMF-8-155-MT/B
The MMF-8-155-MT/B is an 8-port back card for the AXSM-16-155/B front card. Each port on this card uses a Multimode Fiber (MMF) optical interface and an MT connector.
SMB-4-155
The SMB-4-155 is a new back card for the new AXSM-16-155/B front card. The SMB-4-155 provides four STM1 electrical ports per bay, for a total of eight STM1 electrical ports per front card. This card is an electrical version of the OC3 SONET interface and therefore supports intracard and intercard APS.
SMFIR-8-155-LC/B
The SMFIR-8-155-LC/B is an 8-port back card for the AXSM-16-155/B front card. Each port on this card uses a Single Mode Fiber (SMF) Intermediate Reach (IR) optical interface and an LC connector.
SMFLR-8-155-LC/B
The SMFLR-8-155-LC/B is an 8-port back card for the AXSM-16-155/B front card. Each port on this card uses a Single Mode Fiber (SMF) Long Reach (LR) optical interface and an LC connector.
New Software Features in Release 2.1.10
This release supports all the features provided in Release 2.0.x, such as PXM45, AXSM, AXSM redundancy, APS, and PXM1 to PXM45 feeder, and it supports all features provided in 2.1.00. The following sections describe new software features in Release 2.1.10.
Automatic Response to Nativity Check
The nativity check feature is used during PXM45 card insertion and card resets to determine if any PXM45 cards in the chassis have been changed. If a PXM45 has been configured in an MGX 8850 switch, the backplane serial number is stored on the PXM45 front card and on the PXM45 hard disk card. If a PXM45 card is inserted into a chassis or the card is reset with a command such as resetsys, the nativity check is run to determine if the PXM45 cards are native to the chassis. If the chassis serial numbers configured on all PXM45 cards match the switch chassis serial number, the cards are all native and no special action is required.
The purpose of the nativity check is to resolve configuration differences between PXM45 cards. Some configuration is stored on the PXM45 front card, and some information is stored on the PXM45 hard disk card. If one or more cards are replaced, the nativity check identifies which cards are new to the switch chassis. In previous releases, the nativity check feature identified configuration mismatches, but it could not automatically resolve them. The new automatic response feature uses the nativity check results to determine which cards hold the valid configuration so that the switch can properly configure the new cards. This feature can automatically respond to most configuration mismatches, but some mismatches still require a manual response.
The following sections describe how the automatic response feature works for standalone and redundant PXM45 installations, and how to respond when the system cannot automatically resolve conflicts.
Automatic Response for Standalone PXM45 Installations
For standalone installations, the nativity check feature detects and responds to PXM45 cards as shown in Table 4.
Table 4 Automatic Response to Nativity Checks in Standalone Installations
Event
|
Nativity Check Results
|
Response
|
PXM45 front card and hard disk card have not changed.
|
Both PXM45 cards are configured with the correct chassis serial number.
|
No action is required.
|
PXM45 front card has been replaced with an unconfigured card.
|
PXM45 front card is not configured and the hard disk card is configured with correct chassis serial number.
|
The switch builds the PXM45 front card configuration from the configuration on the hard disk.
|
PXM45 front card has been replaced with a previously configured front card.
|
PXM45 front card is not configured with the correct chassis serial number. The hard disk card is configured with correct chassis serial number.
|
The switch rebuilds the PXM45 front card configuration from the configuration on the hard disk.
|
The hard disk card has been replaced with an unconfigured card.
|
PXM45 front card is configured with the correct chassis serial number, but the hard disk card is not configured.
|
The hard disk configuration cannot be completely built from the configuration on the front card. You must manually resolve the configuration conflict as described in "Manually Responding to Nativity Checks," which appears later in these Release Notes.
|
The hard disk card has been replaced with a previously configured hard disk card.
|
PXM45 front card is configured with the correct chassis serial number, but the hard disk card is not configured with correct chassis serial number.
|
The hard disk configuration cannot be completely rebuilt from the configuration on the front card. You must manually resolve the configuration conflict as described in "Manually Responding to Nativity Checks," which appears later in these Release Notes.
|
PXM45 front card and hard disk card are replaced with unconfigured cards.
|
No configuration exists on either card.
|
There is no existing configuration to use. You must configure the switch or restore a saved configuration.
|
PXM45 front card and hard disk card are replaced with a set that was configured in another switch.
|
PXM45 front card and hard disk card are configured with matching chassis serial numbers, but the configured serial number does not match the chassis serial number.
|
The switch uses the configuration on the matched set.
|
Both PXM45 front card and hard disk card are replaced with cards that were configured in different switches.
|
The PXM45 front and hard disk cards are configured with chassis serial numbers that do not match each other or the backplane serial number for the switch in which they are installed.
|
In this scenario, you can clear the configuration stored on the PXM45 cards, restore a configuration from a saved file, or you can use the configuration stored on the hard disk. You must manually resolve the configuration conflict as described in "Manually Responding to Nativity Checks," which appears later in these Release Notes.
|
Automatic Response for Redundant PXM45 Installations
For redundant PXM45 installations, the nativity check is performed only on the active PXM45 card set. If an active PXM45 card set is operating correctly, you can replace any card in the standby or non-active card set, and the active card set will attempt to configure the replacement card and bring it up in standby mode.
When the entire switch is reset, the nativity check is used to determine which card set gains mastership. The card set that gains mastership will attempt to go active and will resolve nativity conflicts as described in Table 4. Table 5 shows how the nativity check is used to assign mastership to a PXM45 card set.
Table 5 Mastership Assignment to PXM45 Card Sets after Nativity Check
Slot 7
|
Slot 8
|
Nativity Status
|
Both cards non-native
|
Front card non-native
|
Both cards non-native, matched serial numbers
|
Hard disk card non-native
|
Both cards non-native, mismatched serial numbers
|
Both cards non-native
|
Slot 7
|
Slot 7
|
Slot 7
|
Slot 7
|
Slot 7
|
Front card non-native
|
Slot 8
|
Slot 7
|
Slot 7
|
Slot 7
|
Slot 7
|
Both cards non-native, matched serial numbers
|
Slot 8
|
Slot 8
|
Slot 7
|
Slot 7
|
Slot 7
|
Hard disk card non-native
|
Slot 8
|
Slot 8
|
Slot 8
|
No active card set.
|
No active card set.
|
Both cards non-native, mismatched serial numbers
|
Slot 8
|
Slot 8
|
Slot 8
|
No active card set.
|
No active card set.
|
Stage 1 Command Line Interface
This release provides a stage 1 Command Line Interface (CLI) feature that replaces the shellcon prompt (pxm45>) used in previous releases. In previous releases, the shellcon prompt appeared during switch startup, and if a PXM45 could not complete startup, it would stop at the shellcon prompt, where the available commands used a different structure from those used in the active state.
The new stage 1 CLI feature provides a limited set of commands that are identical to those used in the active state. This makes it easier to troubleshoot problems because there are fewer commands to learn.
The prompt for the stage 1 CLI is:
The i character in the prompt indicates that the card is in the initialized state. In this state, the only valid username is user cisco, and the password is ciscoinc. The configured usernames and passwords are not supported until the switch reaches the active state, which is indicated with an a in the prompt.
If you log in during stage 1 and the card progresses to the active or standby state, the card will log out the stage 1 user and prompt you to log in again. At this point, you must log in as a configured user with the corresponding password. The stage 1 username and password are not supported on active and standby cards.
MPLS Interface Policy
The MPLS interface feature allows you to configure the following parameters for MPLS & PNNI partitions on RPM-PR on a per service category basis:
•Minimum bandwidth; default value is 0%
•Maximum bandwidth; default value is 100% of partition maximum
•Minimum number of connections; default value is 0%
•Maximum number of connections; default value is 100% of partition maximum
•Booking factor; default value is 100%
For example, you can configure the UBR service category on a PNNI partition to have a guaranteed bandwidth of 50% of the partition's maximum bandwidth.
Unknown.8.PXM.a > dsppnports
Summary of total connections
(p2p=point to point,p2mp=point to multipoint,SpvcD=DAX spvc,SpvcR=Routed spvc)
Type #Svcc: #Svpc: #SpvcD: #SpvpD: #SpvcR: #SpvpR: #Total:
p2p: 0 0 0 0 0 0 0
p2mp: 0 0 0 0 0 0 0
Total= 0/50000
Summary of total configured SPVC endpoints
Type #SpvcR #SpvpR #SpvcD #SpvpD Total
p2p: 0 0 0 0 0
p2mp: 0 0 0 0 0
Total=0
Summary of total active SVC/SPVC intermediate endpoints
Type #Svcc #Svpc #SpvcR #SpvpR Total
p2p: 0 0 0 0 0
p2mp: 0 0 0 0 0
Total=0
EndPoint Grand Total = 0/100000
Per-port status summary
Type <CR> to continue, Q<CR> to stop:
PortId LogicalId IF status Admin status ILMI state #Conns
1.1 17238785 up up Undefined 0
1.2 17238786 up up Undefined 0
2.1 17240833 up up Undefined 0
7.35 17251107 up up Undefined 0
7.36 17251108 up up Undefined 0
7.37 17251109 up up Undefined 0
7.38 17251110 up up Undefined 0
Unknown.8.PXM.a > dsppnportrsrc 1.2
cbr: rt-vbr: nrt-vbr: ubr: abr: sig:
Maximum Tx Cell Rate (cells/sec): 176604 176604 176604 176604 176604 176604
Maximum Rx Cell Rate (cells/sec): 176604 176604 176604 176604 176604 176604
Min Guarant Tx Cell Rate (cells/sec): 0 0 0 0 0 0
Min Guarant Rx Cell Rate (cells/sec): 0 0 0 0 0 0
Minimum Cell Loss Ratio Tx : 8 8 8 8 8 8
Minimum Cell Loss Ratio Rx : 8 8 8 8 8 8
Available Tx Cell Rate (cells/sec): 176604 176604 176604 176604 176604 176604
Available Rx Cell Rate (cells/sec): 176604 176604 176604 176604 176604 176604
# of Available Tx Channels: 253 253 253 253 253 255
# of Available Rx Channels: 253 253 253 253 253 255
Unknown.8.PXM.a > cnfpnportcac
Err:Mandatory IP Type argument required.
Syntax:cnfpnportcac <portid> <service_catogory>
[-bookfactor <utilization-factor>]
[-maxbw <max-bw-percent>]
[-minbw <min-bw-percent>]
[-maxvc <max-vc-percent>]
[-minvc <min-vc-percent>]
[-maxvcbw <max-vc-bw>]
shelf.slot:subslot.port:subport -- [shelf.]slot[:subslot].port[:subport] (default=Mandatory Parameter); shelf -- valid value = 0
service_category -- service_category {cbr|rtvbr|nrtvbr|abr|ubr}
bookfactor -- bookfactor (default=100)
maxbw -- maxbw (default=100)
minbw -- minbw (default=0)
maxvc -- maxvc (default=100)
minvc -- minvc (default=0)
Type <CR> to continue, Q<CR> to stop:q
Unknown.8.PXM.a > cnfpnportcac 1.2 ubr -minbw 50
WARNING:New CAC parameters apply to existing connections also
Unknown.8.PXM.a > dsppnportrsrc 1.2
cbr: rt-vbr: nrt-vbr: ubr: abr: sig:
Maximum Tx Cell Rate (cells/sec): 158944 158944 158944 176604 158944 158944
Maximum Rx Cell Rate (cells/sec): 158944 158944 158944 176604 158944 158944
Min Guarant Tx Cell Rate (cells/sec): 0 0 0 17660 0 0
Min Guarant Rx Cell Rate (cells/sec): 0 0 0 17660 0 0
Minimum Cell Loss Ratio Tx : 8 8 8 8 8 8
Minimum Cell Loss Ratio Rx : 8 8 8 8 8 8
Available Tx Cell Rate (cells/sec): 158944 158944 158944 176604 158944 158944
Available Rx Cell Rate (cells/sec): 158944 158944 158944 176604 158944 158944
# of Available Tx Channels: 253 253 253 253 253 255
# of Available Rx Channels: 253 253 253 253 253 255
Unknown.8.PXM.a > dsppnportcac 1.2
cbr: rt-vbr: nrt-vbr: ubr: abr: sig:
bookFactor: 100% 100% 100% 100% 100% 100%
maxBw: 100.0000% 100.0000% 100.0000% 100.0000% 100.0000% 100.0000%
minBw: 0.0000% 0.0000% 0.0000% 50.0000% 0.0000% 0.0000%
maxVc: 100% 100% 100% 100% 100% 100%
minVc: 0% 0% 0% 0% 0% 1%
maxVcBw: 0 0 0 0 0 0
Changed Commands
The following sections describe AXSM CLI commands that have changed in this release.
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.
dspapsbkplane
This command shows whether the APS connector, which is also called the mini backplane, is plugged in properly. It should be used only when the standby card is in Ready state and APS has been configured for the card pair. When the standby card is re-booting or failed, for example, intercard APS cannot work properly and hence this command will show 'NOT ENGAGED'.
The APS connector status is for the bay specified with the dspapsbkplane command and applies to all lines in that bay. This is because an APS connector is installed in a single bay and enables APS for all lines in that bay. To provide APS to all lines for a slot, APS connectors must be installed in the upper and lower bays.
dspapsln
The dspapsln command needs to be entered with both the working line ID and the protection line ID. The 'Alarm' shown is not an integrated alarm; it is for the LineId that was entered. The 'Alarm' can show the following 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 a configuration mismatch, APS should still function properly)
•OK -- No alarm
The Alarm states shown are independent of the APS line cross status.'
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.
Removed Commands
There are no commands removed from version 2.1.10.
Upgrading to a New Software Release
This section contains installation and upgrade instructions. For complete details, refer to the MGX 8850 Routing Switch Software Configuration Guide that shipped with your system. Also see the "Related Documentation" section of these notes for a list of the new documentation that supports Release 2.1.10.
Changes to the Upgrade Procedure
Before upgrading PXM45, AXSM, or RPM-PR software, disable online diagnostics if they are running (CSCdu27378). After you upgrade the software as described in the MGX 8850 Routing Switch Software Configuration Guide and in the next section, you can turn on the diagnostics.
RPM-PR Upgrades
The section provides instructions on upgrading the following RPM-PR configurations:
•1:N redundant configurations
•Non-redundant configurations
The procedure for upgrading 1:N redundant configurations is not included in the Cisco MGX 8850 Routing Switch Configuration Guide, Release 2.1.00 and will be added to a future revision. The procedure for upgrading non-redundant RPM-PR cards is in the Cisco MGX 8850 Routing Switch Configuration Guide, Release 2.1.00, but Cisco Systems recommends that you modify this procedure. The following sections describe these recommended procedures.
Upgrading with 1:N Redundancy
The following procedure describes how to upgrade redundant RPM-PR cards.
Note Redundancy must be established before you use this procedure. If redundancy has not been configured between two RPM-PR cards, upgrade each RPM-PR card using the procedure in the next section, "Upgrading Without Redundancy."
Step 1 On the primary RPM-PR card, upgrade the software as described in Appendix A of the Cisco MGX 8850 Routing Switch Configuration Guide, Release 2.1.00.
Tips Be sure to use the copy run start command to save the configuration change.
Step 2 Switch to the secondary card using the softswitch as follows:
mgx8850a.7.PXM.a > softswitch <fromSlot> <toSlot>
This step makes the secondary card active and resets the primary RPM-PR card. When the primary card resets, it loads the upgraded software defined in Step 1.
Step 3 Switch back to the primary card using the softswitch command.
This step makes the upgraded primary card active and resets the secondary card. When the reset is complete, the secondary card is ready to run the upgraded software.
Step 4 If there are other primary cards with redundant (secondary) cards, repeat this procedure for each primary card.
Upgrading Without Redundancy
The upgrade procedure in the Cisco MGX 8850 Routing Switch Configuration Guide, Release 2.1.00 is missing one step, which is the step that configures the RPM-PR card to save the configuration on the PXM45 hard drive as well as in bootflash and NVRAM. While this step is optional, Cisco Systems recommends that you use the following procedure when upgrading non-redundant RPM-PR cards.
Step 1 Configure the RPM-PR card to store its configuration on the PXM45 hard disk by entering the following command:
boot config e:auto_config_slot#
Step 2 Upgrade the RPM-PR software as described in Appendix A of the Cisco MGX 8850 Routing Switch Configuration Guide, Release 2.1.00.
Tips Be sure to use the copy run start command to save the configuration change before you reset the card.
Limitations and Restrictions
The following sections describe the following issues for this release:
•General Limitations and Restrictions
•APS Management Information
•Clearing the Configuration on Redundant PXM45s
•Open APS Issues
•APS Events to Avoid
•Recommendations
General Limitations and Restrictions
The following list describes limitations and restrictions that apply to this release:
•The dsperr command currently provides proper information only when it is executed on a PXM45 card. When it is executed on an AXSM card, the displayed information is incorrect.
•Controller ID 2 is reserved for a PNNI controller; IDs 3-20 are available for LSC controllers.
•Support for 3 controllers only (1 for PNNI and 2 for LSC).
•Partition ID 1 is reserved for PNNI.
•The maximum number of logical interfaces (physical trunks, virtual trunks, logical ports) supported in this release with PXM45 or PXM45/B cards is 99.
•If any AXSM cards remain in the initialized state and the PXM45 standby card is reset, the PXM45 standby card will not transit back to the standby state. This is a DB server limitation.
•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.
•In this release, a Service Class Template (SCT) can be changed with connections present. However, if the change affects services in use, the connections will be rerouted.
•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.
RPM-PR and MPLS Limitations and Restrictions
The following list describes RPM-PR and MPLS limitations and restrictions that apply to this release:
•A single RPM-PR can only be function as either an Edge LSR or as an LSC, but not as both.
•Total of (OC12 minus T3) Mbps intrashelf traffic for Cell bus based modules are supported.
•The addred command is not allowed when it specifies an RPM/B card and an RPM-PR card.
•To configure redundancy, the primary and secondary RPM-PR cards need to be in the active state and secondary card should not have any configured connections.
•Removal of the primary RPM-PR back card does not cause switch over to the secondary RPM-PR.
•After establishing redundancy between two RPM-PR cards with the addred command, you must enter the copy run start command on the primary RPM-PR card to save the configuration change.
•If a secondary RPM-PR card is redundant to primary cards x and y, you cannot delete redundancy for only card x.
•If you need to enter the softswitch and switchcc commands, Cisco Systems recommends that you wait at least 5 seconds after issuing the softswitch command and then enter the switchcc command.
•IOS software images on primary and secondary RPM-PR cards do not have to be compatible, but the IOS software on a secondary card should be at the same level as the primary card or higher.
•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.
APS Management Information
The following tips apply to the use of the dspapsbkplane command and the APS connector, which is sometimes called a backplane. 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/8850r21/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.
Open APS Issues
Note The issues in this section are seen only in Operational mode 1+1, bi-directional, Rev/non-Rev. If at least one side is configured as 1+1 unidirectional, these problems do not occur.
The following are some open APS issues in this release:
•AXSM switch over when the working line is disconnected (both Tx and Rx) may cause data loss on the lines that have APS configured. Recovery Procedure: If the other end reports alarms on both lines and has Channel Mismatch or PSBF, perform Lock-out of Protection Line and clear on the local end.
•AXSM switch over may cause an erroneous APS alarm on one or both lines which may not clear by itself. Recovery Procedure: Perform Lockout of Protection and clear on the far end (the side that does not have the alarm).
•If multiple working-lines are removed at the same time, one line may not switch over. Recovery Procedure: Perform Lockout of Protection and clear from the far end.
APS Events to Avoid
When using APS, try to avoid the following:
•Removal of front card or back card when there is APS configured.
•AXSM switch over when APS is configured and one side of the APS line-pair is disconnected.
If it is impossible to avoid the above, check to see if there are erroneous alarms that will not clear. If there, do the following
1. Perform Lockout of Protection line and clear.
2. 2. If Step 1 does not work, perform delete APS for the line and then add it back.
Clearing the Configuration on Redundant PXM45s
When the nativity check discovers conflicts that cannot be automatically corrected, one option is to issue a clrallcnf command to establish the PXM45 card sets as new, unconfigured cards in the chassis. Unfortunately, there is a bug (CSCdt92422) that prevents this procedure from working on redundant PXM45s. The work around is to remove one set of PXM45 cards, clear the configuration on the installed set, and then install the redundant card set so that the cards are brought up in standby mode.
Recommendations
Cisco Systems provides the following information and recommendations for switch configuration:
•The RPM-PR subinterface ID range is 1 - 32767.
•We recommend applying the default values for PCR, SCR, and so on to the Control VC. If the values are decreased to a low value, there is a chance that the protocol on the interface (SSCOP or PNNI) will not come up.
Important Notes
This section provides general notes that apply to this release and covers some procedures that are not in the shipping versions of the manuals.
General Notes
The following list provides general notes on using the switch.
•You must use the SCT files released with 2.1.00 (number 2 and 3, which are included in version 2.0.13) for the Control VC feature. If you are using the MPLS feature, then you will need to change to SCT 3 or 4, which are released with version 2.1.00.
•To remove AXSM redundancy (delred), you must remove the Y-red cables before issuing the delred command.
•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.
•Do not execute the delcontroller command when connections/ports still exists. The impact of executing delcontroller with connections is that the connections cannot be recovered until the controller is re-added using addcontroller and the AXSM cards or the entire node has to be reset (otherwise ports remain in the provisioning state). There is now a warning to the user of the impact of the command when there are existing connections/ports.
•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 avoid that link from being used.
•To replace one type of AXSM front card with another type, you must delete all connections, partitions, ports and down lines. If an AXSM card fails, the same type of AXSM card must be installed in its slot.
•When the switch cannot automatically resolve nativity check conflicts as described earlier in "Automatic Response to Nativity Check," you can force a configuration rebuild from a specific hard disk by establishing a console port session through the corresponding PXM-UI-S3 card and issuing the shmRecoverIgRbldDisk command. This command ignores the nativity check and configures the entire switch according to the configuration on the hard disk.
•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 future releases of MGX 8850, 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. MiniVDI is not negotiated by ILMI, so the user should set this parameter same on both nodes.
RPM-PR and MPLS Notes
The following list provides notes on using RPM-PR cards and MPLS in this release:
•(CSCdt55154) RPM-PR back card status may be incorrect.
•For RPM-PR SPVC dax connections, the slave end must be deleted before the master endpoint.
•The following table lists RPM commands that are different in Releases 1.x and 2.x of the Cisco MGX 8850 switch.
Release 1.x (PXM1)
|
Release 2.x (PXM45)
|
addcon
|
switch connection
|
rpmrscprtn
|
switch partition
|
atm pvc
|
pvc
|
RPM-PR auto_config File Management
The RPM-PR auto_config_slot# file stores the configuration for the RPM-PR card. The slot# portion of the name is automatically set to the slot number that corresponds to the RPM-PR card. This file can be stored in bootflash and in the E:RPM directory on the PXM45 hard disk. The configuration is also stored in NVRAM using the name startup-config.
When the RPM-PR card starts or reboots, it searches for the configuration file in the following sequence:
•If there is an auto_config file only on the PXM45 hard disk, the RPM-PR card uses the configuration stored on the hard disk.
•If there is no auto_config file on the hard disk, then the NVRAM version is used.
•If configuration files exist on both the hard drive and bootflash, the switch examines a timestamp tag in each file. If the timestamp tag is the same in both files, the RPM-PR card uses the configuration file stored in bootflash. If the timestamp tag is different, the RPM-PR card uses the configuration file stored on the hard drive.
Note You must configure the RPM-PR card to store the configuration on the hard disk when using 1:N redundancy. If the configuration is not stored on the hard disk, the secondary card cannot load the configuration during switch over.
To configure the RPM-PR card to store its configuration on the PXM45 hard disk, enter a command sequence similar to the following:
RPM-PR_LA_9#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
RPM-PR_LA_9(config)#boot config e:auto_config_9
RPM-PR_LA_9#copy run start
Destination filename [startup-config]?
Building configuration...
Be sure to use the correct slot number for your RPM-PR card in the boot command, and remember to save the configuration change with the copy run start command.
Using tstdelay on Feeder Trunks
On feeder trunks, cnfoamsegep is required for tstdelay to work. The steps are as follows on PNNI:
Step 1 dpnport <portid>
Step 2 cnfpnportsig <portid> -cntlvc ip
Step 3 cnfoamsegep <portid> no
Step 4 uppnport <portid>
Manually Responding to Nativity Checks
When the nativity check discovers conflicts that cannot be automatically corrected, you can resolve the conflict by doing one of the following:
•If you have saved a configuration with the saveallcnf command, you can restore the configuration with the restoreallcnf command.
•If there is no configuration available, you can issue a clrallcnf command to establish the PXM45 card sets as new, unconfigured cards in the chassis.
•If a configuration exists on a hard drive, you can use that configuration to configure the front card and establish nativity for the card set.
If the switch cannot resolve a nativity check conflict and all the cards are operating properly, the PXM45 cards enter stage 1 CLI mode, which offers a reduced set of commands that you can use to resolve the conflict.
When operating in stage 1 CLI mode, you can FTP files to the switch in preparation for a new configuration or a configuration restore. The procedure for transferring files is that same procedure described in the Cisco MGX 8850 Routing Switch Software Configuration Guide.
To rebuild the configuration from a configured hard disk in the switch, do the following:
•Clear the configuration (clrallcnf) on the PXM45 front card using a PXM45 hard disk card for which the configuration can be erased. (Do not use the PXM45 hard disk that hosts the configuration you want to use.)
•Install the unconfigured PXM45 front card and the configured PXM45 hard disk card in a chassis without a redundant card set.
Note There is a bug (CSCdt902422) that prevents this procedure from working on redundant PXM45s. For more information and a work around, see "Clearing the Configuration on Redundant PXM45s," which appears earlier in these Release Notes.
The switch will build the PXM45 front card configuration from the configuration on the hard disk.
Documentation Correction—PNNI Feeder Configuration Quickstart
The following quickstart procedure was accidentally omitted from the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links." This quickstart procedure provides a summary of the tasks required to configure a connection from an MGX 8850 Release 1 feeder through one or more MGX 8850 Release 2 switches, and to a remote feeder or CPE. This procedure is provided as an overview and as a quick reference for those who have previously configured these types of connections.
Note The trunk configuration is not complete until the MGX 8850 Release 1 feeder is also configured.
|
Command
|
Purpose
|
Step 1
|
username
<password>
|
Start a configuration session on the MGX 8850 Release 2 switch. This will be the local routing switch that connects to the feeder.
Note: To perform all the procedures in this quickstart procedure, you must log in as a user with GROUP1 privileges or higher.
|
Step 2
|
|
Prepare AXSM cards and lines as described in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 3, "Preparing AXSM Cards and Lines for Communication."
Remember to select the appropriate card SCT for the controller or controllers you are using.
|
Step 3
|
addport <options>
Related commands:
dspports
|
Configure the local routing switch port that leads to the feeder. When configuring the line, select either interface type 1 (UNI) or 2 (NNI). Use the same interface type when defining the port on the feeder.
See "Adding ATM Ports" in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links."
|
Step 4
|
addpart <options>
Related commands:
dspparts
dsppart
cnfpart
|
Assign trunk resources to the PNNI controller ID, which is 2.
See "Partitioning Port Resources Between Controllers" in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links."
|
Step 5
|
dnpnport <portid>
cnfpnportsig <options>
uppnport <portid>
Related commands:
dsppnports
dsppnport <portid>
dsppnportsig <portid>
|
Define the signaling protocol used on the trunk. If CWM will be used to manage the feeder, use the cnfpnportsig command to enable IP communications between the switch and the feeder:
pop20two.7.PXM.a > cnfpnportsig <portid> -cntlvc ip
See "Selecting the Port Signaling Protocol" in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links."
|
Step 6
|
addfdr <ifnum>
Related commands:
dspfdr <ifnum>
|
Define the local routing switch port as a feeder port.
See "Defining a PNNI Feeder Port" in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links."
|
Step 7
|
See the MGX 8850 Release 1 documentation.
|
At the MGX 8850 Release 1 feeder, use the addcon command to add a connection on the link to the MGX 8850 Release 2 switch.
|
Step 8
|
|
Configure the port on the remote routing switch that terminates calls in the core network. If the remote routing switch port connects to a feeder, repeat Steps 2 and 3 to configure the remote feeder trunk. If the remote routing switch port connects to CPE, configure the port for UNI communications.
|
Step 9
|
cnfoamsegep <portid> no
|
Define the local routing switch feeder port as a non-OAM segment endpoint. This is required to enable testing with the tstdelay command.
|
Step 10
|
addcon <options>
Related commands:
dspcons
|
Create an SPVC from the local routing switch feeder port to the remote routing switch termination port.
See "Configuring SPVCs and SPVPs" in the Cisco MGX 8850 Routing Switch Software Configuration Guide, Chapter 5, "Provisioning AXSM Communication Links."
|
Caveats
This section provides the following information:
•Open Anomalies for Release 2.1.10
•Problems Fixed in Release 2.1.10
•Open Anomalies from Release 2.1.00
•Open Anomalies for MPLS
•Problems Fixed in Release 2.1.00
Open Anomalies for Release 2.1.10
Table 6lists known anomalies in this release. Included with each is a brief discussion of the problem. For additional information, use Bug Navigator to view the release note enclosure associated with the Bug ID listed in the table.
Table 6 Open Anomalies for Release 2.1.10
Bug ID
|
Description
|
S1Bugs
|
CSCdt29648
|
Symptom: BPX reported no ingress data from MGX.
Condition: APS switch had been performed on BPX.
Workaround: UNKNOWN
|
CSCdt87174
|
Symptom: Db of data transfer connection did not get remove properly.
Condition: Some abnormal shutdown and establish of a data transfer connection.
Workaround: None.
|
CSCdu08846
|
Symptom: Data transfer interrupted when switchredcd executed.
Condition: switchcc and switchredcd executed with an LOS condition on one APS line.
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: Working lines and protection lines in alarm.
Condition: Removing the front card.
Workaround: None
|
CSCdu17812
|
Symptom:
Calls are routed to a via node that is not able route calls out to the destination because outbound interface is in auto-config.
Condition: Node was a via node, with only two PNNI trunks available, one of which was in auto-config (because other end was in down in progress).
Workaround:
UNKNOWN
|
CSCdu18494
|
Symptom: switchredcd caused the node to reset.
Condition: Whenever a switchredcd is done, the shelf gets reset.
Workaround: None.
|
CSCdu39060
|
Symptom: Active PXM resets during a loadrev to upgrade Standby.
Condition: DbSvrIO Tlb Load Exception on Active PXM.
Workaround: None.
|
CSCdu42067
|
Symptom: Port remains in building VC state.
Conditions: LCN count goes negative.
Workaround: Reset the card.
|
CSCdu42756
|
Symptom: Both AXSM cards in an AXSM pair reset when switchredcd executed
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdu43302
|
Symptom: 20k connections get derouted
Condition: New boot burned on the pxm
Workaround:UNKNOWN
|
CSCdu46759
|
Symptom: Both AXSMs in an AXSM pair reset when switchredcd executed
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdu50573
|
Symptom: AXSM/B hardware reported Full coverage failure for offline diagnostic tests
Condition: Offline diagnostic coverage was executed
Workaround: UNKNOWN
|
|
|
S2 Bugs
|
CSCds60439
|
Symptom: PXM45 goes to Active-F state when Humvee HMM errors are detected.
Condition: The Humvee HMM error thresholds must be set properly and need some amount of soaking. Until then, HMM reporting to SHM has been turned off.
Workaround: UNKNOWN
|
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 port was administrator downed followed by inserting/resetting the standby AXSM.
Workaround: Initiate another Bulk Sync (by resetting the standby AXSM) after the port is upped.
|
CSCdt05371
|
Symptom: Tr2 were not generated for hard disk failure during fault insertion testing.
Condition: Hard disk failure was simulated on modified PXM45s.
Workaround: None.
|
CSCdt05378
|
Symptom: Switch over to faulty standby PXM45 allowed during fault insertion testing.
Condition: Hard disk failure was simulated on the standby PXM.
Workaround: None
|
CSCdt05383
|
Symptom: PXM45 switch over 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: None
|
CSCdt05385
|
Symptom: No alarms reported when hard disk failure on active PXM45.
Condition: Hard disk failure was simulated on active PXM45.
Workaround: None
|
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: None
|
CSCdt19949
|
Symptom: switchapsln from protection line to working line is blocked.
Condition: Last user request was a working line to protection line switch.
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: None
|
CSCdt29629
|
Symptom:
APS switching is blocked for 1+ minute after alarm is cleared.
Condition: None
Workaround: None
|
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
|
CSCdt61620
|
Symptom: For RPM-PR card, the MIB objects in entPhysicalTable do not contain the versions of hardware, software, and firmware.
entPhysicalHardwareRev[59] = " "
entPhysicalFirmwareRev[59] = "0.0(0)" <---- for RPM-B card
entPhysica lSoftwareRev[59] = "0.0(0)"
Condition: Not implemented for RPM-PR cards.
Workaround: UNKNOWN
|
CSCdt63973
|
Symptom: After a switch from working line to protection line because of bit errors introduced, the protection line bit error count shows a large number. (The bit error counts were cleared before starting the test.)
Condition: Still investigating. This is not a service impacting bug.
Workaround: None
|
CSCdt64502
|
Symptom: Signal failure and signal degrade conditions might persist longer than the time mentioned/specified by the specifications.
Condition: When a line goes into SF or SD condition or the line actually clears from this condition, the SF or SD might just take a couple of seconds longer. This can be verified when a bit error rate tester is used and verified for the same.
Workaround: None.
|
CSCdt65669
|
Symptom: Cannot configure the IOS set command within the policy-map command.
Condition: None
Workaround: None
|
CSCdt69485
|
Symptom: The working line shows a signal degrade even after the BER tester has stopped. Also, the working line did not seem to clear and so did not switch from protection to working even after the WTR timer.
Condition: None.
Workaround: None.
|
CSCdt75251
|
Symptom: AXSM2 OC48 went to "Empty Res State", maxreset = 3. resFcFailed and resBcMissing.
Condition: This problem occurs after 20 switchcc commands overnight.
Workaround: resetcd for AXSM or remove and insert AXSM.
|
CSCdt75728
|
Symptom: dspbecnt command on AXSM/B card with APS redundancy configured causes node to hang indefinitely. This problem occurred on the master side of the connections. On the slave side, dspbecnt command worked as expected.
Condition: APS redundancy was configured on AXSM/B card.
Workaround: Cntrl-C will get you back to the prompt.
|
CSCdt79626
|
Symptom: One will see following line repeatedly:
5.1.2 not W nor P-Line for 0x81918a88
Condition: switchredcd was executed.
Workaround: Logout from the session and login again.
|
CSCdt80060
|
Symptom: Connection remains in temporary failure after pulling out and plugging in the cables of PNNI link and PNNI link recovered.
Conditions: UNKNOWN
Workaround: UNKNOWN
|
CSCdt81984
|
Symptom When you do clrallcnf, RPM-PR does not go to active.
Condition When you have both active and standby PXM, and when you do clrallcnf, the RPM-PR does not go to active. Workaround 1: We have to do resetcd after RPM-PR comes up in boot/empty state. Workaround 2: Do clrallcnf only with active PXM45 and no standby PXM45. Workaround 3: Load the RPM-PR image from bootflash instead of getting it from the PXM45 hard drive.
|
CSCdt82991
|
Symptom: Active card show in Active-F state.
Condition: Task tLogD declares Non Fatal Major error to SHM.
Workaround: None. Insert a standby PXM45 and the card will take over or reset the active card. Card is still operational in Active-F state.
|
CSCdt84036
|
Symptom: None
Condition: The redundancy got deleted and reappeared on RPM-PR cards.
Workaround: None
|
CSCdt88532
|
Symptom: APS line went to protect after clearing it under a scenario.
Conditions: Change mode when active line is protection line.
Workaround: Execute a clear instruction after the cnfapsln command.
|
CSCdt89899
|
Symptom When you do clrallcnf, RPM-PR does not go to Active.
Condition When you have both active and standby PXM45, and when you do clrallcnf, the RPM-PR does not go to active.
Workaround 1: We have to do resetcd after RPM-PR comes up in boot/empty state. Workaround 2: Do clrallcnf only with active PXM45 and no standby PXM45. Workaround 3: Load the RPM-PR image from bootflash instead of getting it from PXM45 hard drive.
|
CSCdt96142
|
Symptom: dsplog shows that SSI has logged some SSI header errors in some 3 tasks. Card seems to be okay or unaffected.
Condition: Unknown
Workaround: None
|
CSCdu05489
|
Symptoms: sub-interface operations status cannot be ascertained by CWM application as this information is not made available on PXM45 MIB tables.
Conditions: If a sub-interface changes its operational status, CWM cannot find the new state value unless this MIB object is made available on PXM45 MIB tables. Currently this information is only available on RPM-PR ifTable.
Workaround: None
|
CSCdu09724
|
Symptom: Connection commit failure reported on the standby AXSM.
Condition: During bulkSync, if controller performs massive deroute/reroute activity on the active AXSM, the connection request forwarded to Standby may fail.
Workaround: None.
|
CSCdu11536
|
Symptom: APS active line gets "Loss of Frm (RED)" message.
Condition: Switch over both BXM and AXSM/B at the same time.
Workaround 1: Switch over BXM first. Wait for previously active card to come to standby state. (Let the switch over complete and wait until both cards are running as a redundant pair, then do AXSM/B switch over.) Workaround 2: Switch over AXSM first, and wait for previously active card to transition to standby state. (Let the switch over complete and wait until both cards are running as a redundant pair, then do the BXM switchover.)
|
CSCdu14207
|
Symptom: Major alarm shown in dspcds for standby PXM45 card after card was fixed.
Condition: Card with major alarm was fixed.
Workaround: None
|
CSCdu15972
|
Symptom: Critical alarm seen on the other end after reinsertion of back card.
Condition: Removal and reinsertion causes Critical alarm on the other side.
Workaround: None
|
CSCdu16674
|
Symptom: After OC48/B back card is removed and inserted, port stays in down state.
Condition: Line and port are upped, local loopback is turned on, back card is physically removed, back card is reinserted. Line is up, local loopback is up, port is operationally down.
Workaround: Delete and re-add local loopback.
|
CSCdu17696
|
Symptom: pnport was stuck in 'down in progress' state.
Condition: dnpnport or uppnport was executed on port terminating the other end of the PNNI trunk.
Workaround: switchcc or resetsys may be required to clear this condition, which is that dnpnport or uppnport did not work.
|
CSCdu18017
|
Symptom: PXM45 indicates not enough memory in the dynamic pool.
Condition: When loading new images to AXSM.
Workaround: UNKNOWN
|
CSCdu19301
|
Symptom: Connection failing after rerouting.
Condition: Ingress CAC failure.
Workaround: None
|
CSCdu19732
|
Symptom: switchredcd results in lines switching. In the case of APS, with the working line removed, a switchredcd would cause a 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.
|
CSCdu19989
|
Support for sub-interface operational status traps is missing.
|
CSCdu20851
|
Symptom: Events of type SSI-4-NEXTCHUNKCORR are logged.
Condition: These events are logged when there is a memory corruption. These events indicate the corruption of one or more message buffers. This condition may lead to more severe conditions resulting in a shortage of message buffers or further memory corruption.
Workaround: There is no workaround except resetting the card on which these events are logged against.
|
CSCdu21738
|
Symptom: The dspapslns command shows that the active line changes from working to protection constantly.
Condition: This is caused by back card removal done in the fashion explained in this bug. There is, however, no data loss. The display is due to the APS issue although the mux is set correctly
Workaround: Reinsert back card.
|
CSCdu21778
|
Symptom:- switchredcd with primary card active or standby and in selector released position causes alarms on all lines.
Condition: Alarms on all lines prevents switchapsln.
Workaround: Lock out of protection on the far end followed by clear command or configuring in 1+1 uni directional mode.
|
CSCdu22855
|
Symptom: Back card removal causes both working and protection lines to be stuck in alarms.
Condition: Alarms prevent switchapsln.
Workaround: Lockout of protection followed by clear. Or reinsertion of back card. Also, provisioning one side in 1+1 uni directional should not cause this problem.
|
CSCdu22880
|
Symptom: Standby card came up in stable condition and no alarm, but APS kept flagging signal fail on protection channel for 1-2minutes.
Condition: switchredcd from primary to secondary card or reset primary card.
Workaround: Unknown
|
CSCdu23302
|
Symptom: When port signalling is ANNI and ILMI autoconf is disabled, dspnilmi (on PXM45) will not show topology information and link status.
Condition: NONE.
Workaround: To get topology information do: dnpnport <port id>, cnfpnportsig <port id>...., and uppnport <port id>. Now, dsppnilmi will show topology information.
|
CSCdu23840
|
Symptom: When CLI is configured via cnfcmdabbr to disallow command abbreviation, command abbreviations are still allowed on the AXSM.
Condition: When cnfcmdabbr off is issued, forcing the user to enter the exact CLI command name.
Workaround: None
|
CSCdu34832
|
Symptom: Crossbar alarms are not integrated with card alarms.
Condition: Always.
Workaround: None.
|
CSCdu36152
|
Symptom: ILMI enabled VT take long time to come up after resetsys.
Condition: The time taken for these ILMI links to come up really depends upon the path VT takes in the ATM cloud.
Workaround: Check if all SVPC connections that make the VTs are in good state end-to-end.
|
CSCdu45344
|
Symptom: vsiError 0xc001 and 0x5011 is logged by AXSM.
Condition: resetting the axsm card having pnni port carrying 20K connection is reset.
Workaround: None
|
CSCdu46065
|
Symptom: Offline diagnostics failed on an AXSM
Condition: Reset reason was reported to be due to Software Error Reset
Workaround: UNKNOWN
|
CSCdu46109
|
Symptom: Offline diag failed on PXM
Condition: Diag indicates real-time clock test failed
Workaround: UNKNOWN
|
CSCdu50846
|
Symptom: NILE4 Memory attempt to protected area
Conditions: 40k conns established between two nodes a4b and a4a ; reset 3 axsm card on node A4b, then switchcc
Workaround: None
|
CSCdu51485
|
Symptom: Invalid K1 byte received
Condition: APS between two POP2 nodes directly connected via two PNNI trunks, each of which consists of an aps pair
Workaround: None
|
CSCdu51488
|
Symptom: Not visibly obvious until user monitors the debug stats on each routed connection. In some cases where the AXSM hosts a large number of persistent endpoints, the stats indicate an increase in the cell discards during periods of deroute and reroutes.
Condition: Usually happens when all the connections are derouted due to trunk failure or some such event.
Workaround: None.
|
S3 Bugs
|
CSCds14722
|
Symptom: There is no way to display Hmm Error counters from the CLI.
Condition: No command available.
Workaround: None
|
CSCds42187
|
Symptom: During build of axsmsim-rt, the build displays error related to the APS files.
Condition: This problem happens only for build in the simulation target.
Workaround: None.
|
CSCds42201
|
Symptom: Standby PXM45 card is in continuous reset loop, 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
|
CSCds43560
|
Symptom: PXM45 card status LED is green when the card is continuous reset loop.
Condition: Injecting a hardware failure on BRAM component of active PXM45 card manually.
Workaround: None
|
CSCds66375
|
Symptom: dspcd, dspcds, dspbkpl, readid bkpl, recordid bkpl show inaccurate headings.
Condition: Always.
Workaround: None.
|
CSCds66602
|
Symptom: Dax VCC connection fails.
Condition: An unrelated VPC partition is deleted.
WorkAround: None
|
CSCds67426
|
Symptom: There are two PXM45 nodes configured with AXSM redundancy. The first node has primary and secondary clocks configured. The other node has clocking sources. Both nodes are reset. The first node is up before the second node. The PXM45 resync clocks will get NAK from AXSM card. This will make the clock configuration status display as not configurable:
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
Condition: Anomaly has only occurred when performing resetsys on two nodes at the same time.
Workaround: Reconfigure the clocks with cnfclksrc commands.
|
CSCds70494
|
Symptom: No mechanism to filter flood of HMM error log.
Condition: Too many errors reported to HMM. The only way to stop this is to disable HMM reporting.
Workaround: None
|
CSCds73435
|
Symptom: Residual database information causes AXSM card state to be interpreted incorrectly. An AXSM card inserted into this slot with the residual database may not successfully come up.
Condition: Residual database on the disk can be introduced if the active PXM45 card or disk is replaced with an older card or disk that has old data on it.
Workaround: Before replacing an active PXM45 front card or disk, make sure that there is a saved configuration for that node. After replacing the active PXM45 front card or disk, restored the saved configuration. Or to verify if there are residual data on the disk, after the node comes up, perform a list file command (e.g. ll) on the D:/DB2 directory. For every slot that is reserved, there should be a corresponding subdirectory for that reserved slot (e.g. SL7), if there are extra subdirectories for non-reserved slots, these are residual old databases.
|
CSCds86986
|
Symptoms: AXSM switchover cause all PNNI links on this AXSM go to attempt status.
Condition: This problem occurred after resetting an AXSM non-redundant card and followed by several (some times up to 10) consecutive AXSM switchovers on redundant AXSM pairs on other slots in the same node.
Workaround: Do not do consecutive AXSM switchovers. If the problem occurs, the periodic resync between PNNI controller and AXSM will recover the failure.
|
CSCds88784
|
Symptom: The dspcdalms and dspcds commands show minor and major alarms for AXSM cards. These alarms are for HUMVEE errors that were reported to the CAM, but can not be cleared.
Condition: In versions 2.0(X) and 2.1(X), there is no way to clear individual card alarms. These alarms are maintained as a summary of all minor and major alarms in the system.
Workaround Use the resetcd -f command, in order to clear the alarm summary counters. Note: This command will NOT physically reset the card; only the alarm summary counters will be cleared.
|
CSCdt04197
|
Symptom: Service switch does not switch all APS lines.
Condition: APS service switch.
Workaround: Multiple service switches.
|
CSCdt05372
|
Symptom: Pop-up messages appeared on CLI.
Condition: Hard disk failure was simulated during fault insertion testing.
Workaround: None
|
CSCdt13184
|
Symptom: In bidirectional APS, if the remote end has done a Lockout of Protection, a working line to protection line switch at the local end will fail with "Unknown" reason.
Condition: See above.
Workaround: None.
|
CSCdt14348
|
Symptom: Should not have a hard-coded enable password on the standby RPM.
Condition: Only on standby RPM.
Workaround: None.
|
CSCdt23235
|
Symptom: Pushing the 2 buttons on the front of the PXM45/B board does not generate a CORE dump when the card resets.
Condition: None.
Workaround: None.
|
CSCdt28752
|
Symptom: One SPVC went down.
Condition: When PXM45 switch over took place.
Work Around: resetsys will bring back the SPVC.
|
CSCdt31059
|
Symptom: Sub-interface addition without specifying link-type results in anomalies.
Condition: Sub-interface should be added without specifying link-type.
Workaround: While adding sub-interface always specify sub-interface link-type.
|
CSCdt42337
|
Symptoms: After issuing switchredcd, debug output appears as follows: "Error in emUpdateLineAlarmState() call for tca alarms, errCode=-1"
Conditions: APS 1+1, AXSM/B.
Workaround: None.
|
CSCdt48287
|
Symptom: Traffic loss, since switch plane was enabled while the AXSM humvee port was disabled.
Condition: Use xbarAlarmSet() to manually generate an alarm.
Workaround: None.
|
CSCdt55955
|
Symptom: Currently all the Xtag are interfaces are displayed in the format of RPM-PR Slot.Port.
Condition: None
Workaround: None
|
CSCdt61868
|
Symptom: RPM in PXM1 is connected as LER to AXSM UNI port. On UNI port whole vpi range 0-255 is assigned for the MPLS partition and a Xtagint is created on LSC which is internal to PXM45. TDP and OSPF comes up fine, LER can see LSC, but ping to each other fails as on LSC headend VC shows in bindwait state.
Condition: None
Workaround: Configure the port as VNNI instead of UNI in AXSM. This is actually the recommended port type when connecting multiple RPM cards in PXM1 to AXSM.
|
CSCdt63012
|
Symptom: On switching back from protection line to working line.
Condition: When forced switching from protection line to working line after forced switching from working line to protection line.
Workaround: None
|
CSCdt69463
|
Symptom: Card alarm display is inconsistent.
Condition: dspcds shows a major alarm for an AXSM, while dspcdalm executed on the PXM45 and on the AXSM does not show an alarm.
Workaround: None
|
CSCdt70323
|
Symptom: Need non-shellconn method of burning PXM45 boot code which also does not require console access to each PXM45.
Condition: 2.0 and 2.1 code.
Workaround: Unknown.
|
CSCdt72072
|
Symptom: dspcd on AXSM shows incorrect information intermittently.
Condition: Card was in active-F state.
Workaround: Issue the command again.
|
CSCdt73278
|
Symptom: dsplns shows the line as clear but dspalms shows alarms on it.
Condition: Back card is removed, and line is in administrator down state.
Workaround: Doesn't need any. Since the line is down, the errors on the line do not matter.
|
CSCdt74252
|
Symptom: None.
Condition: Display of error message on the PXM45 after a switchcc of PXM45 and softswitch on RPM-PR.
Workaround: None
|
CSCdt74681
|
Symptom: SPVC master end points were not in proper state.
Condition: After non graceful upgrade.
Work Around: Unknown.
|
CSCdt75737
|
Symptom: PXM45 logged a lot of error messages as: ssiSynchTimerCreate: Watchdog already created, watchdog Id = 82e2c770. ctc_msg_evt_handler: App evt hdlr failed, evt 22, app 1000b, evtLen 20, Switch Driver Error: spiConnAdd() line no 188: connRef=32598.
Condition: After multiple switchcc overnight.
Workaround: None.
|
CSCdt76508
|
Symptom: AXSM does not have any commands display port, feeder, and channel alarms.
Condition: Always true.
Workaround: Use existing commands to debug.
|
CSCdt78030
|
Symptom: An invalid port id is shown in the output of dsppnni-reachable local: aquaman.8.PXM.a > dsppnni-reachable-addr local scope............... 0 port id.............4294967295 <==== Incorrect.
Conditions: Reproducible.
Workaround: None.
|
CSCdt78174
|
Symptom: Requested new command to provide mapping between LIN (=ifIndex) and physical descriptor. 16979970 <=> 3:1.2:2.
Conditions: Reproducible.
Workaround: None
|
CSCdt81645
|
Symptom: The protection line of APS on feeder shows P_D and APS_ST is CH_MIS
Condition: dspln on feeder.
Workaround: Unknown
|
CSCdt82111
|
Symptom: CLI login prompt did not appear after 60K connections rerouted.
Condition: The basic CLI was deleted but the stage 4 CLI was not spawned.
Workaround: No workaround available. The switch was reset.
|
CSCdt82189
|
Symptom: dspapsbkplane is showing inconsistent results when displayed from active and standby card.
Condition: None.
Workaround: None.
|
CSCdt84148
|
Symptoms: Switch fails sometimes when the operating mode is bi-directional.
Conditions: APS switchover fails.
Workaround: To provision 1+1 uni direction on at least one side.
|
CSCdt86445
|
Symptom: addcontroller does not check for all error conditions
Conditions: Adding LSC controller on AXSM card, adding controller on empty card, and adding 2 controllers on the same slot.
Workaround: None
|
CSCdt86631
|
Symptom: Trap Vendor OID is wrong.
Conditions: addcontroller on empty card.
Work Around: Do not addcontroller on empty card.
|
CSCdt91951
|
Symptom: AXSM card resets after 1 minute of lost data after error injection.
Condition: Injected error on the Utopia 3 bus between Humvee and QE48 detected by Online diagnostics causes card switch over.
Workaround: None
|
CSCdt93005
|
Symptom: None
Condition: CTC error in dsplog
Workaround: None
|
CSCdt93508
|
Symptom: RPM-PR card issues port 161 socket error every 60 seconds to console.
Conditions: As soon as SNMP community is configured on the RPM-PR card, this message is emitted on the RPM-PR console window every 60 seconds.
Workaround: None
|
CSCdt95790
|
Symptom: A new standby syncs up all the databases with active card.
Condition: None
Workaround: This mechanism expedites this sync-up process by syncing only the DB2 database, unlike regular CSR that does it for all the databases.
|
CSCdu01259
|
Symptoms: Command sh switch partition shows wrong information regarding PXM45 Slot and ifType.
Conditions:
Router# sh switch partition vcc 1
-------------------------------------------------------
Router# sh switch partition vpc 1
-------------------------------------------------------
Pxm Slot : 0 <--- should this be slot 7
IfType : 0 <--- Does ifType = 0 correct ?
Workaround: Unknown
|
CSCdu02027
|
Symptom: AXSM returns wrong error code in case of LCN allocation failure.
Condition: The resource management was not setting the error code.
Work Around: Resolved for future releases.
|
CSCdu08187
|
Symptom: switchapsln 1 (clear) gives wrong error message by saying switch failed when actually the switching was finished successfully when either the working line or the protection line was in alarm.
Condition: This happens all the time.
Workaround: Unknown
|
CSCdu13862
|
Symptom: Ports/partitions/connection configuration appeared on a previously empty and unconfigured slot when an AXSM card was inserted
Condition: May happen when a slot is unused for a long period of time and hasn't been configured.
Workaround: The customer should issue a clrallcnf on a new shelf before starting to use the shelf.
|
CSCdu15428
|
Symptom: The "Noncompliant cells" counter in dspchancnt display is populated even when using SCT3, which disables policing.
Condition: Use SCT3 on AXSM and pass traffic. The "Noncompliant cells" counter value in dspchancnt command display increases continuously.
Workaround: None.
|
CSCdu15566
|
Symptom: Protection line is in alarm when it is OK on APS line redundancy testing.
Condition: AXSM OC12 secondary front card is active, primary front card is in standby. On back card, upper and lower bay working lines are active.
Workaround: Delete and re-add APS redundancy.
|
CSCdu15997
|
Symptom: dspcons and dspcon on AXSM gave wrong information about the connection after multiple switchredcd commands on AXSM T3/E3 cards.
Conditions: The information AXSM gave were not consistent with it PXM45 gave.
Workaround: Unknown
|
CSCdu21554
|
Symptom: APS priority sets are different between MGX and BPX.
Condition: MGX force switchapsln from W-->P then not allow Force from P-->W BPX force switchaps from W-->P then allow Force back from P-->W.
Workaround: None.
|
CSCdu21566
|
Symptom: switchcc execution is successful, it is not blocked.
Condition: When the old standby PXM45 card degraded switch fabric.
Workaround: Verify the switch fabric health on the standby PXM45 before executing switchcc.
|
CSCdu22924
|
Symptom: Failure of xbarlink is raised as a minor alarm. It should be a major alarm.
Condition: None
Workaround: None
|
CSCdu22932
|
Symptom: When loadsharing and autoshutdown is enabled and the planes shut down due to switch plane errors, standby card needs to show degraded mode.
Condition: Loadsharing and autoshutdown enabled and crossfabric seeing alarms.
Workaround: None.
|
CSCdu26101
|
Symptom: SHM-4-STBY_UPDATE_ERR messages are logged at Sev-4 in the event log
Condition: Both PXM cards were reset concurrently
Workaround: UNKNOWN
|
CSCdu26141
|
Symptom: SHM-4_DB_REQ_FAIL messages are logged at Sev-4 in the event log
Condition: Consecutive resetcd commands were executed on the PXM cards in this system.
Workaround: UNKNOWN
|
CSCdu27030
|
Symptom: OAM CC Activation Cell correlation tag is incorrectly modified.
Condition: User notes that an F4-Seg Active-CC OAM cell with a correlation tag of 0x6A is returned to the sending device with a correlation tag of 0x00.
Workaround: None
|
CSCdu30398
|
Symptom: addcon and delcon doesn't log correctly.
Condition: Always when a addcon and delcon command is executed.
Workaround: None
|
CSCdu33656
|
Symptom: "dspportload" command does not have the option for a time period based utilization.
Condition: Use AXSM CLI command - "dspportload".
Workaround: None.
|
CSCdu34560
|
Symptom: Loss of network clock redundancy alarms are not reported when the Standby UI S3 card is missing at the time of initial bring up or after system reset. (This alarm is reported if a Standby UI is pulled when the node is operating normally.)
Condition: The Active PXM is reset when the Standby PXM does not have a UIS3 plugged in.
Workaround: None.
|
CSCdu40145
|
Symptom: SVC connections get released (lost)
Condition: After switchcc
Workaround: None.
|
CSCdu43253
|
Symptom: VC AIS is reported back to CPE sending LOS into UNI port.
Condition: Customer notes incorrect reception of VC AIS at a test analyzer connected to an AXSM UNI port after introduction of LOS. This behavior is not expected.
Workaround: UNKNOWN
|
CSCdu46186
|
Symptom: Popup message appears on AXSM CLI prompt
Condition: UNKNOWN
Workaround: UNKNOWN
|
CSCdu49122
|
Symptom: Down AXSM interface via snmp-set: returns successful.
Conditions: AXSM interface with active ports/partitions.
Workaround: Use CLI.
|
CSCdu50642
|
Symptom: Inconsistency between line and port counters
Condition: Could cause confusion during troubleshooting
Workaround: UNKNOWN
|
CSCdu51147
|
Symptom: May cause congestion in the network.
Condition: Any single endpoint connection that receives OAM can cause this. When enough connections are in this state, congestion may occur.
Workaround: None
|
Problems Fixed in Release 2.1.10
Table 7 lists problems that have been fixed in this release. Included with each is a brief discussion of the problem. For additional information, use Bug Navigator to view the release note enclosure associated with the Bug ID listed in the table.
Table 7 Problems Fixed in Release 2.1.00
Bug ID
|
Description
|
S1Bugs
|
CSCdr04767
|
PNNI link state stay in OneWayInside/Attempt after AXSM reboot.
|
CSCds48791
|
RPM-PR doesn't always come up.
|
CSCds52336
|
Standby-pxm switch-plane links get shut on AXSM-Reset.
|
CSCds79775
|
PXMB: Tlb load exception on single axsm while reinserting pxm45b card
|
CSCds83769
|
REG: SCM retries; Stby PXM45 and all AXSMs went down; qe overflow.
|
CSCdt01701
|
resetcd of the RPM, caused the active PXM45 reboot.
|
CSCdt05292
|
When did the switchcc, ipc err flooded the screen & PNNI went down.
|
CSCdt29711
|
LCN port group used count goes -ve while upgrading the node.
|
CSCdt38643
|
AXSMB:OC3&OC12 1+1APS; switchaps didn't switch remote line w/Bi-Dir.
|
CSCdt40561
|
DLS: SPVCs failed after upgrade due to cross-commit fail
|
CSCdt47965
|
switchcc Causes RPM-B/RPM-PR to lose cells.
|
CSCdt48247
|
AUTOCARD: DBs should be created on Standby also.
|
CSCdt53443
|
Always get bulkfile create aborted trap 60903 when upload RPM file.
|
CSCdt55555
|
PXM45 card gets stuck in idtmon. Undo the checkin CSCdt33765.
|
CSCdt57525
|
APS OC3 back card remove/insert caused protection chan stuck signal fail.
|
CSCdt62832
|
switchcc with resetsys causes links to go to 1Wayinside.
|
CSCdt62917
|
The SPVC connections not routing because of node upgrade.
|
CSCdt65453
|
The ports stuck in buildingvc/downinprogress after resetsysofpeernod.
|
CSCdt70757
|
The SPVC connections not routing because of node upgrade.
|
CSCdt72750
|
Standby card went to Init state after AXSM upgrade
|
CSCdt72786
|
Pnports went to building VC state after upgrading bootcode for AXSM
|
CSCdt74499
|
CLI commands were rejected because of time outs
|
CSCdt75070
|
Standby card went to Init state after AXSM upgrade.
|
CSCdt79058
|
Application should never send an already freed Iov buffer.
|
CSCdt80570
|
R5K L2 Cache is incorrectly enable.
|
CSCdt80677
|
The current baseline code always skips Nativity checking.
|
CSCdt83293
|
restoreallcnf did not restore cfg on the node.
|
CSCdt86743
|
SNMP fails on the whole shelf leaving it unmanageable.
|
CSCdt87745
|
100K:stat counter not decremented causing cong. and all 100K fail
|
CSCdt87835
|
AXSM/B:1+1APS; 3 PNNI links down, SSCOP in reset, after SW upgrade.
|
CSCdt95005
|
AXSM/B:OC3 1+1APS; working line auto switch failed after working line back card removed.
|
CSCdu01185
|
SLT: OC48 redundancy works only in one way properly.
|
CSCdu16786
|
AXSME-RED: core didn't get dumped.
|
CSCdu17620
|
DLS:PNNI tries to route call using VPI/VCI assigned to active call.
|
CSCdu24141
|
RPM ABR PCR is not enforced during traffic flow.
|
CSCdu30563
|
DB2: Configuration done during Standby coming up is missing
|
CSCdu36048
|
Backout changes for CSCdu05489 and CSCdu19989.
|
S2 Bugs
|
CSCdr15911
|
PhyTask suspended after inserting OC48 back card.
|
CSCdr89521
|
DLS: Routing cost deteriorates to 0 for a routed connection.
|
CSCdr91301
|
AXSM-RED: ILMI disabled in PXM45 automatically *REDT*.
|
CSCds22332
|
AXSM slot remaps are messed up on standby PXM45.
|
CSCds46509
|
REG: inconsistency in displaying s/w versions.
|
CSCds52863
|
100K: SPVC dax connections disappear after PXM45 software upgrade from 2.0 to 2.1.
|
CSCds64705
|
Load-Sharing enabled, Hv err on act-Pxm45 during standby PXM45 bring up.
|
CSCds78391
|
Online diag was ran on standby AXSM card, it went to fail state.
|
CSCds78530
|
MPLS VSI Interface Policy not programmed in PXM45.
|
CSCds84581
|
REG: problem with APS lines that has ILMI enabled
|
CSCdt07644
|
DLS: Minor clock alarm for primary clock is never cleared
|
CSCdt07730
|
DLS: dspclkalms shows minor alarm for secondary instead of primary
|
CSCdt09616
|
Connections do not clear IF FAIL if added when port is down.
|
CSCdt09931
|
DLS: Node goes onto internal oscillator after switchcc.
|
CSCdt09949
|
DLS: Channel loops are lost randomly without doing anything.
|
CSCdt11342
|
REG: SHM show RPM in BOOT although RPMs are active after switchcc.
|
CSCdt11521
|
vsiProcessVxlCommitRsp:no legs, but has Pep error message keep pop up
|
CSCdt16262
|
AXSM/B: 1+1 APS failed switchaps W->P, after protection line Lockout and Clear.
|
CSCdt16458
|
AXSM/B:1+1 APS disapsln showed differ results after switchapsln failed.
|
CSCdt19936
|
Ports stuck in building vc after node reset
|
CSCdt25937
|
cnfpnportsig value for aini is accepted but not working.
|
CSCdt37525
|
syncRam allows application to send to standby while standby failed
|
CSCdt38272
|
AIS are not detected on the routing node when dnpnport is issued.
|
CSCdt38628
|
DLS: dspbecnt shows wrong info for an aps line
|
CSCdt38632
|
Command routeNedAdd failed
|
CSCdt41415
|
AXSM ports stuck in autoconfig after power cycling mgx8850
|
CSCdt42037
|
Control Characters Cause CLI Monitor Change Without Warning.
|
CSCdt42953
|
cc enable should be allowed if oam is set for enni.
|
CSCdt43001
|
AXSM/B:OC3 1+1APS; over 75% VCCs in alarm after switchredcd.
|
CSCdt43448
|
3 spvc connections of 100k failed after reset sys
|
CSCdt43629
|
DLS: Nodal data in disk mismatch with RAM data msg appears in event l
|
CSCdt44343
|
Event log files are not ordered chronologically.
|
CSCdt45544
|
DSL: <scmproccardinsertremovemsg> unknown slot 23 on switchcc
|
CSCdt45643
|
DLS: Route Op Start/STop messages are dropped incorrectly
|
CSCdt47978
|
dbgcon command should be removed from cli
|
CSCdt48282
|
Core dump functionality for AXSM
|
CSCdt48479
|
ABR CDVT policing does not work on AXSM
|
CSCdt51273
|
softswitch causes failure to open virtual port on new active card.
|
CSCdt52132
|
SHM: event filter should free event before return
|
CSCdt52608
|
REG: setrev on active PXM45 made the pnports to go autoconfig.
|
CSCdt53257
|
tstdelay on a SPVC connection is not consistent
|
CSCdt53354
|
vsiSync task crashed after an upgrade was aborted.
|
CSCdt54457
|
NNI links went into vc failure.
|
CSCdt55245
|
Dynamic scaling: MPLS COSs need to have different scaling classes.
|
CSCdt55938
|
CWM cannot resync on AXSM card.
|
CSCdt56272
|
BKT1-SLT: Node rebuilt on its own after a double failure.
|
CSCdt56312
|
APS intermittently fails to switching on OC48/OC3 (BI&NREV).
|
CSCdt57738
|
IPCONN SVC not up (VcTbl Full)
|
CSCdt57775
|
DLS: warning regarding cnfpnportcac applying to existing calls
|
CSCdt59596
|
Trap 60078 slot/index varbinds are switched in trap output
|
CSCdt60239
|
REG: Active line shows ALM when switchredcd on the other side of 1+1APS.
|
CSCdt60315
|
Dspalmcnt does not work for RcvRAI alarm on AXSM T3 card
|
CSCdt62251
|
Active Trap Received When down then up on AXSM->RPM connection.
|
CSCdt62497
|
No Up Trap is Received when down then up on RPM->RPM connection.
|
CSCdt63170
|
DLS:resource allocation after AXSM pair reset.
|
CSCdt64155
|
Update cwm with line state after switchover.
|
CSCdt65181
|
Redundancy switch over trap has incorrect data.
|
CSCdt66184
|
Access level for addcon... should be GROUP1
|
CSCdt67969
|
REG: Standby PXM45A reset from init state.
|
CSCdt68712
|
Virtual trunks were not coming up even spvp conns were out of alarm
|
CSCdt70494
|
dspred shows slot as empty even though standby.
|
CSCdt70708
|
Connection cannot cnfcon on connection at feeder endpoint.
|
CSCdt70864
|
SRM slots should not alarm when empty in 2.1(0).
|
CSCdt74986
|
DAX conns generating E-AisRdi alarm
|
CSCdt75047
|
IPCONN: PXM switchover can leave ATM SVC in wrong state
|
CSCdt75586
|
SBC: dsppnni-link displayed attempt-onewayinside
|
CSCdt76291
|
MPG: Timer was overwritten when more than 5 outgoing resource inform.
|
CSCdt76575
|
Software exception caused by task PhyTask missing for OC12 card.
|
CSCdt79166
|
UPG-dt: Runrev blocked due diskupdate without any provisioning.
|
CSCdt80226
|
REG: Uni port went into vc failure after adding 5k SPVC slave ends.
|
CSCdt80433
|
Connections and port on SM non active in the chassis are OK and UP.
|
CSCdt81775
|
AXSM does not report mismatch even if the other end point got delete.
|
CSCdt82559
|
REG: Some master end points had AIS/RDI after resetsys at both ends.
|
CSCdt82767
|
VSICORE: connections are not deleted properly in VcoBulkDel (dnport).
|
CSCdt83005
|
COREDUMP: Enable AXSM coredump feature by default
|
CSCdt84185
|
Dangling / Disappearing leg in CM.
|
CSCdt84299
|
Node rebuilt itself after restoreallcnf and cmLmi exception found.
|
CSCdt85241
|
Standby RPM doesn't take over primary slot after resetsys.
|
CSCdt86437
|
RPM uses hard-coded SNMP community string of POPEYE.
|
CSCdt86522
|
RPM ports in down state after a resetsys on node.
|
CSCdt86827
|
Inconsistencies with sub interface.
|
CSCdt86961
|
Sub interface down does not get reflected in connection status.
|
CSCdt89684
|
The PXM45 active card failed after inserting the RPM/PR.
|
CSCdt91205
|
MIB version shows up as 0 in gFwMibSlotInfo Table.
|
CSCdt91237
|
AXSB:1+1APS; dsplns had Critical/Major alm, but dspalm was Clear.
|
CSCdt94279
|
IPC event declaration and usage mismatch.
|
CSCdt96477
|
CSMI task needs to free up the pipc buffer on getting pipc send err.
|
CSCdt97193
|
Core mask data corrupted.
|
CSCdt97225
|
During pcpro audit out of sync connections should be flagged not deleted.
|
CSCdu00244
|
VSICORE/RM: Delete Ingress connection ID failed on standby.
|
CSCdu04807
|
CRC mismatch between RVT & PXM45 dbs.
|
CSCdu04832
|
Need to check partitions lcn range while adding a new partition.
|
CSCdu05612
|
RM/DAL: del egr connection ID failed due to the implicit egr connection ID delete.
|
CSCdu06158
|
VSICORE: add egress connection ID failure.
|
CSCdu07155
|
VC merge does not work on AXSM 1&2 cards.
|
CSCdu09353
|
Service switch causes all APS lines on both bays to switch.
|
CSCdu10842
|
Connection Trace MIB tree contains incorrect value.
|
CSCdu10851
|
AXSM: IFC State transitions to FAILED_INT after switchcc
|
CSCdu11128
|
SyncRam/DataXfer did not detects register from wrong slot.
|
CSCdu12506
|
All interrupt are disabled while adding intra-card APS lines.
|
CSCdu13182
|
AXSM DS3 interface fails after 6130 reloading.
|
CSCdu17872
|
Ports can be provisioned to a corrupt SCT file, no warning generated.
|
CSCdu20368
|
DLS: Evt. log: switchcc results in watchdog already created msg.
|
CSCdu20402
|
Wrong value returned for cwspOperIlmiEnable MIB object.
|
CSCdu20428
|
CBR.3: VSIM setting scr equal to PCR0 instead of PCR0+1.
|
CSCdu20588
|
DLS: Evt.Log: switchcc results in SSIF bad timer message in log.
|
CSCdu20591
|
DLS: Evt. log: switchcc results in ILMI error messages in log.
|
CSCdu20596
|
DLS: Evt.Log: switchcc results in Error in rebuilding in spvcStandbyUp.
|
CSCdu20858
|
DLS:CLI commands to be included in the Evt. log Severe Cmd. category.
|
CSCdu21004
|
DLS: Evt. log: switchcc resulted in PXMC-4-RAMSYNC error messages.
|
CSCdu21576
|
Connections not in MISMATCH state.
|
CSCdu23901
|
Connection Trace MIB requires new variable.
|
CSCdu30471
|
Trunk would not route VPCs even though resources were available.
|
CSCdu38087
|
Partitions intf policy is synched up after connections on standby
|
CSCdu38123
|
Junk ABR parameters are sent in the commit during call release
|
CSCdu43684
|
Event logs flood the PXM45 disk due to CAC errors
|
S3 Bugs
|
CSCds02957
|
dspvsiparts should display the number of conns in each partition
|
CSCds44434
|
Found a diagnostic error in dsplog when online diags run on PXM45.
|
CSCds50108
|
dspcon show the incorrect RIF/RDF values in ABR connection.
|
CSCds50591
|
Trace back error when OSPF running on 255 SPVP connection.
|
CSCds52306
|
dspxbaralms doesn't show any alarms even though xbar err & alms exist.
|
CSCds52595
|
trapClTask keeps logging Invalid Ptr Messages
|
CSCds68651
|
AXSM2 card takes 10 minutes to reset when QE-48 chip is reset.
|
CSCds69414
|
PNNI event is misleading about service module card role
|
CSCds73580
|
upport should be blocked by the cema if the Port is in the UP state.
|
CSCds77014
|
dspapsln and dspapslns display different alarm states.
|
CSCds79149
|
REG: incorrect err generated when addpart with no port.
|
CSCds80214
|
dspcd display is inconsistent for full and half-height card.
|
CSCds87038
|
DLS: dspdiagcnf, dspdiagerr, dspdiagstatus commands do not break
|
CSCds89750
|
Trap 60301 cwChanAdd received w/ invalid varbind cwaChanVpcFlag.
|
CSCdt04929
|
Only allow copychan to copy up to 20 conns
|
CSCdt05929
|
tstdelay for feeder end should be rejected
|
CSCdt08776
|
REG: calling of API ctcAppActiveRdyconfirm fails when switchred
|
CSCdt10751
|
Alarm information needs to be broadcast to AXSMs.
|
CSCdt14240
|
ssiIpcEpWait(0) handling need enhancement
|
CSCdt16719
|
Upg: need remove pop up message on newly active PXM45 card.
|
CSCdt23408
|
DLS: Popup messages on all telnet sessions when dspsscops executed
|
CSCdt23729
|
Xbar fencing command needed.
|
CSCdt24006
|
Event Log Cleanup: ShelfMgr event logged Sev 2
|
CSCdt25266
|
SSI-EXCEPTION in tDbgTrc for OC48 card.
|
CSCdt32558
|
switchcc causes lots of cmStdbySetVpiVciBitmap events (7000+)
|
CSCdt33765
|
BackupBoot: PXM45A/B, AXSM cache not flushed correctly
|
CSCdt36274
|
addapsln should not allow for annex B option in command line.
|
CSCdt39878
|
Error messages on APS CLI commands gives unnecessary messages.
|
CSCdt41012
|
SHM: addred/delred commands are not logged by CLI.
|
CSCdt42037
|
Control Characters Cause CLI Monitor Change Without Warning.
|
CSCdt42209
|
DLS: CUT: (cuts) failed to schedule timer in cutsProcessAckRecv even
|
CSCdt43383
|
UPG-dt: Setrev on a redundant pair with Primary card missing fails.
|
CSCdt43625
|
REG: Allowed to configure redundancy between upper bay and lower bay.
|
CSCdt44241
|
Display Alarms Commands Not Corresponding
|
CSCdt46363
|
SHM: clrallcnf doesn't delete SHM DBs.
|
CSCdt48901
|
DLS:ILMI disabled messages printed in event log after switchcc
|
CSCdt51884
|
SHM: Doesn't prevent multiple upgrades simultaneously.
|
CSCdt52092
|
DLS: Call failure due to max crankbacks msg in event log
|
CSCdt52357
|
All printfs need to be changed to ssiDbgPrintfs.
|
CSCdt53956
|
DLS: dsprevs command randomly displays garbage for non-existent card
|
CSCdt55215
|
REG: Vsi_avl_tree_add failed, node exist- message got generated.
|
CSCdt58380
|
CoreDump: request for setting default value for 2.0
|
CSCdt60607
|
switchredcd command should prompt user with warning to continue
|
CSCdt60635
|
dsppnport output does not show univer self signalling correctly.
|
CSCdt61754
|
clrportcnt doesn't check for the port.
|
CSCdt74560
|
Replace eventlog for invalid number of varbinds/bad linked list.
|
CSCdt76387
|
pcpro connection audit is not started sometimes.
|
CSCdt76635
|
Rev up of files done inaccurately.
|
CSCdt77534
|
DLS:CLKMGR STBY EPID INVALID/IPC CHAN. FLR. evt. msg on switchcc/reb.
|
CSCdt78111
|
Green LED remains on after cnfln to plcp and dnln on AXSM-16T3E3.
|
CSCdt78905
|
Congestion Manager logs errors when VSIM sends interfaces
|
CSCdt80847
|
Redundancy: a user command to check the active/standby consistency.
|
CSCdt81674
|
SLT: Software should not correct HecErr, should discard HecErr Cells.
|
CSCdt83286
|
AXSMB: Garbage Req. displayed on OC12 APS AXSM/B console.
|
CSCdt85723
|
DAL: dalConnIdShowByVpci doesn't return proper slot/port info.
|
CSCdt85953
|
Provide a solution to card nativity issues.
|
CSCdt86853
|
Invalid values in rpm_connection.
|
CSCdt89348
|
Need to display more granular level for the Alarm in dspapslns.
|
CSCdt89848
|
Popup after adding APS line.
|
CSCdt91656
|
Add ipcHelp routine on popeye21T.
|
CSCdt97747
|
ivty_destroy_existing_session() in LOGIN error msg in log.
|
CSCdt98355
|
Verify functionality of cavi Stats.
|
CSCdu01995
|
No module option for dbgcon.
|
CSCdu03068
|
The command prompt doesn't show the correct VCI range.
|
CSCdu03444
|
RamSync code clean-up.
|
CSCdu03454
|
Line shows alarm even though it is DOWN.
|
CSCdu07942
|
clrallcnf doesn't clear RPM NVRAM Sometime...
|
CSCdu09570
|
ssi trace core dumps when more than 4 args are passed to it.
|
CSCdu16101
|
TCA threshold not defaulted after dnln.
|
CSCdu18994
|
DLS: saveallcnf popup after running clrcnf after upgrade to 2.1.01.
|
CSCdu23970
|
dspapsbkplane displays err msg when executed from standby card.
|
Open Anomalies from Release 2.1.00
Table 8 lists open anomalies from Release 2.1.00. Included with each is a brief discussion of the problem. For additional information, use Bug Navigator to view the release note enclosure associated with the Bug ID listed in the table.
Table 8 Open Anomalies from Release 2.1.00
Bug ID
|
Description
|
CSCdt17735
|
Duplicate of CSCdt57525
Symptoms: AXSM/B APS; removed the active Backcard; would cause the active Frontcard to reset.
Some case the active line did not switch properly.
Conditions: AXSM/B OC3 and OC12; 1+1 APS; Bi-Dir; Revert/NonRev. Removal of the active Backcard.
Workaround: None.
|
CSCdt45715
|
Duplicate of CSCdt56312
Symptoms: The APS switches will fail in OC12 caused by spurious interrupts
Workaround: None.
|
CSCdt59098
|
Duplicate of CSCdt57970
Symptom: PXM45A and PXM45B firmware directory syncup times out.
Condition: Occurs when the standby PXM card does not have a copy of the runtime
software and tries to download the software from the Active PXM.
Workaround: None
|
CSCdt61113
|
Duplicate of CSCdt53900
Symptom: Data Cell loss when PXM45B becomes active.
Condition: Switchcc to make PXM45B active
Workaround: None
|
CSCdt61175
|
Closed, not a problem
Symptom: PXM45B unable to come up in Standby state. SAR errors reported. Condition: Replace a PXM45A standby with PXM45B to bring it up in standby ready state.
Workaround: None
|
CSCdt63620
|
Closed
Symptom: pxm was dropping 83% of cells when pumped oc12 - T3
Condition: pxm was dropping 83% of cells when pumped oc12 - T3
Workaround: None
|
CSCds74565
|
Verified on 2.0.10
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: None
|
CSCdt06424
|
Unreproducible
Symptom: OC12 AXSM card does not implement REI-L (M1) byte for generation of near-end error counts to far-end system.
Condition: None
Workaround: None.
|
CSCdt16733
|
Duplicate of CSCdt57525
Symptom: 1. Failed to switchapsln W->P on OC12 AXSM/A and AXSM/B. 2. Error "ApsDisable()" displayed repetitively. 3. Same failure occurred on OC3 also, but no "ApsDisable()" error.
Condition: 1. Start with AXSM/A and AXSM/A as APS 1+1. 2. Replace the Standby AXSM/A with AXSM/B. (Both FC and BC) 3. Switchred; then replace the 2nd Standby AXSM/A with AXSM/B.
Workaround: Perform delapsln and addapsln to clear the error condition.
|
CSCdt19936
|
Duplicate of CSCdt60260
Symptom: Port stuck in building vc
Condition: Power off/on or reset node
Workaround: Issue dnpnport portID then uppnport portID command
|
CSCdt28752
|
Duplicate of CSCdt31210, OC12 1+1APS
Symptom: One SPVC went down.
Condition: When PXM switch over took place.
Workaround: Resetsys will bring back the SPVC.
|
CSCdt28970
|
Closed, not a problem
Symptom: Allowing addred
Condition: Primary card in mismatch state
Workaround: None.
|
CSCdt33717
|
Closed, not a problem
Symptom: When line is upped with no cable attached, "dspalm" command does not indicate LOS.
Condition: When Model B STM-1 and T3/E3 backcards are used.
Workaround: None.
|
CSCdt38628
|
Verified on 2.0.11
Symptom: dspbecnt shows wrong info.
Condition: Always.
Workaround: None.
|
CSCdt45544
|
Verified on 2.0.12
Symptom: issued a switchcc, display log shows error,scmproccardinsertremovemsg unknown slot 23.
Condition: Customer did a switchcc, dsplog shows this error. 08-00137 02/06/2001-18:09:43 SCM-5-UNKNOWN_VALUE tSCM 0x8022442c <scmProcCardInsertRemoveMsg> unknown slot 23 - 24 dropped
Workaround: None
|
CSCdt46311
|
Unreproducible
Symptom: AXSM-OC12 stopped working.
Condition: Redundancy was there between two axsms. When it has been attempted to fall back to previous version of firmware by using setrev and burnboot commands. One card stoped working and other card came up active.
Workaround: Reset the card which was not working and then reset the active card in the redundant pair.
|
CSCdt48260
|
Duplicate of CSCdt27105
Symptoms: 1. RPM CPU Utilization might go high. 2. "cc" to RPM might take time. 3. Sub-interface will go up/down. 4. console access to RPM will be slow
Condition: If we add more than 300 PVC, with all OAM Managed. Since all the OAM Cells are Process Switched, having more PVCs with OAM-Managed, will increase no. of cells to be handled in process level, which will degrade the performance.
Workaround: If we need more PVC with OAM Managed, then we have to reduce the OAM Loopback freq. and OAM Retry Freq. If we can make the Loopback Freq. as 60 sec and retry freq as 10 sec, this might solve the problem.
|
CSCdt49900
|
Unreproducible
Symptom: Active PXM45 got reset.
Condition: When switchredcd was given between to AXSM-OC48s.
Workaround: None.
|
CSCdt53959
|
Duplicate of CSCdt17735
Symptom: OC3/MMF 1+1 APS; switchapsln w/Clear failed with "Unknown Reason" after the Back Card was replaced.
Condition: OC3/MMF with 1+1APS setup; Active on Secondary card and Protection line. Remove and replace the active Back Card. Then switchapsln function will fail.
Workaround: First, make sure the Back Card is seated properly and screwed in tightly. Delapsln then Addapsln will clear the error condition most of the time.
|
CSCdt56854
|
Duplicate of CSCdt57525
Symptom: OC12 1+1 APS SETUP; switchapsln w/Manual from WLine to PLine failed with "Priority" error. After the Error condition was cleared; switchapsln failed on the local end, but switched from WLine to PLine at the remote end.
Condition: OC12 1+1 APS with Bi-direction configured; Active on Secondary card and WLine. After the WLine Back Card was replaced, and the APS error was cleared.
Workaround: None
|
CSCdt59174
|
Unreproducible
Symptom: AXSM-OC3 went into Active-F state.
Condition: After switchcc was done on the node.
Work Around: None.
|
CSCdt60336
|
Junked(010329)
Symptom: switchaps fail with "priority request"
Condition: 1. AXSM redundancy with the following: primary card (AXSM/A) in slot 4 secondary card (AXSM/B) in slot 5 active card - secondary card (slot 5) active aps line - working line (on back
k card slot 4) 2. Remove standby card (slot 4) 3. Attempt to switchaps line.
Workaround: None
|
CSCdt61077
|
Closed, not a problem.
Symptom: 1. You will see drops in Main Interface. 2. Communication between RPM and PXM will be slow, like cc to card will timeout. 3. Console access will be locked.
Condition: When you send traffic to RPM with smaller PDU size, like 64 byte packets.
Work-around: There is a limitation on RPM with respect to the number of packets it can handle per sec. Please read the below release notes. For RPM/B its 150,000 pps For RPM-PR its 350,000 pps So if your Packet size is small, so it fits into one ATM cell, then RPM needs handle 365,566 pps. So if you want to increase usage of bandwidth you have increase the PDU size. This will prevent drops. 1.1.32 Version Software Release Notes Cisco WAN MGX 8850, 8230, and 8250 Software With MGX Release 1.1.32, two Route Processor Modules (RPMs) are supported; the RPM/B and the RPM-PR. The RPM/B is a NPE-150 based router card capable of sustaining 150,000 pps. The RPM-PR is an NPE-400 based router capable of sustaining over 350,000 pps.
|
CSCdt61925
|
Unreproducible.
Symptom: AXSM-OC3 went into Active-F state.
Condition: When the node was upgraded from one build to another build.
Workaround: None.
|
CSCdt64272
|
Duplicate of CSCdt59098
Symptom: PXM45B did not come up as standby.
Condition: When PXM45B was inserted in standby slot.
Workaround: None.
|
CSCdt64482
|
Duplicate of CSCdt56312
Symptom There is a switch failure at times. This is a known problem
Condition: None
Workaround 1+1 uni directional mode seems to work for inter and intra card APS.
problems are seen in 1+1 bi directional case.
Revertive or non-revertive should not matter.
|
CSCds38696
|
Closed
Symptom: cli dspxbaralm and dspxbaralms redundant. dspxbaralm needs to show more information
Condition: dspxbaralm has been removed. Only dspxbaralms command remains.
Workaround: Use other xbar commands such as dspxbarstatus, dspxbarmgmt to see the status.
|
CSCds49422
|
Unreproducible
Symptom: Contrace will not function
Condition: None.
Workaround: None
|
CSCds68568
|
Unreproducible
Symptom: AXSM does not go Active after initiating burning of new software
Condition: New software is being downloaded to AXSM. Download takes a very long time.
Workaround: None
|
CSCds87859
|
Duplicate of CSCdt62832
Symptom: PNNI links are in attempt, dspsarcnts shows about 50% of PDUs getting CRC and or length errors on any one connection. (can only occur when there is a standby PXM)
Condition: Problem seen after an Upgrade from 2.0 to 2.1 firmware.
Workaround: After the upgrade, use the cnfxbarmgmt command to disable load sharing and then re-enable.
|
CSCdt11986
|
Junked
Symptom: switchapsln allows a user to do a P->W switch option even if the Active line is W (Working)
Condition: Always
Workaround: None.
|
CSCdt19134
|
Unreproducible
Symptom: SPVC connections rerouting fluctuates.
Condition: Execution of resetsys or switchredcd commands on via nodes.
Workaround: None.
|
CSCdt20890
|
Junked
Symptom: APS configuration allowed in a STM backcard in AXSM-OC3 card
Condition: None.
Workaround: None
|
CSCdt26997
|
Duplicate of CSCdt85743
Symptom: PNNI link problems, loss of connections
Condition: resetsys caused one of PNNI link went to attempt state one side and OneWayInside in other. Intermittent failure.
Workaround None
|
CSCdt27229
|
Closed, not reproducible.
Symptom: User tries to delete a virtual port using snmp - wrong error value is seen.
Condition: User tries to delete a virtual port using snmp
Work-around: None
|
CSCdt30141
|
Duplicate of CSCdt63743
Symptom: Logs on console of the standby AXSM card shows "Multi-party conns are not handled.....".
Condition: This was caused by an accidental enabling of trace message level in a devtest software image.
Workaround: None; The problem has been taken care of by fix for bugid CSCdt63743
|
CSCdt34859
|
Held
Symptom: Problems routing connections.
Condition: Problem may be seen after an AXSM switch over.
Workaround: Reset the AXSM card.
|
CSCdt43407
|
Duplicate of CSCdt43383
Symptom: Display of the Error message needs to be modified.
Condition: None.
Workaround: None
|
CSCdt45961
|
Closed, not a problem.
Symptom: APS Active in Pline, after switchapsln w/Clear; Active remains on Pline.
Condition: The APS line is configured as Non-revertible.
Workaround: May configure the APS line as Revertible, then the Clear option will switch Pline to Wline.
|
CSCdt46926
|
Closed, not a problem
Symptom: dspcd on an AXSM/B card does not show lower back card
Condition: when performed from the controller card.
Workaround: None
|
CSCdt53778
|
Duplicate of CSCdt98357
Symptoms: Lockout command on line X will also cause APS switch to Working on lines Y and Z.
Conditions: AXSM/B APS 1+1. All active lines have APS configured for bidirectional mode. All lines have existing user requests -- the X line has a successful request from W->P, while the Y and Z lines have failed requests from P->W. Once the lockout command is initiated on line X, the Working line becomes the active line (which is correct). However, the two other lines are also affected and go to Working (not correct).
Workaround: None.
|
CSCdt59893
|
Unreproducible
Symptom: Sessions on axsm were not being deleted. Type "who" or "users" on the AXSM to see the sessions. Sessions remained even after timeout. Attempt to cc resulted in the error: Err: cliSmEptWrite(): ssiIpcComEpNameResolve("cli.07.0700911B"): failed
Condition: IPC call to lookup an epid was failing, causing code to free sessions to fail.
Workaround: None
|
CSCdt59932
|
Duplicate of CSCds46465
Symptom: Runrev for an SM is not prevented even though there were updates to the primary version after loadrev was completed successfully.
Condition: If a Standby PXM rebuilds when upgrade of an SM is in progress and a loadrev is completed followed by a PXM switchover, the new Active PXM (old Standby PXM) wouldn't have kept track of DB updates to primary version. This results in not blocking the runrev when SM's DBs were updated during the upgrades.
Workaround: Avoid PXM switchovers during upgrade of an SM. If there was a PXM switchover and there is a likely chance of SM's DBs were updated after a loadrev is completed, abort the SM's upgrade and restart.
|
Open Anomalies for MPLS
Table 9 lists open anomalies that apply to MPLS. Included with each is a brief discussion of the problem. For additional information, use Bug Navigator to view the release note enclosure associated with the Bug ID listed in the table.
Table 9 Open Anomalies for MPLS
Bug ID
|
Description
|
S1Bugs
|
None
|
S2 Bugs
|
None
|
S3 Bugs
|
CSCds31381
|
Redistributing external routes from bgp into ospf for a vrf will generate an ospf process. This process will stay active even if redistribution is removed.
|
S4Bugs
|
CSCdt27105
|
Symptom: RPM CPU Utilization Goes High.
Condition: When there more than 1500 connection and There is incoming AIS for all the connection.
Workaround or fix: None
|
CSCdr50215
|
Symptom: When redistributing VPNV4 BGP routes containing OSPF RT extended community attribute into OSPF, the router may display alignment errors.
Condition: This problem is fixed in 12.1(4) and 12.1(4)E releases. This fix is not included in 12.1(3) and 12.1(3)E releases.
Workaround: No workaround is necessary.
|
|
|
Problems Fixed in Release 2.1.00
Table 10 lists problems that were fixed in Release 2.1.00. Included with each is a brief discussion of the problem. For additional information, use Bug Navigator to view the release note enclosure associated with the Bug ID listed in the table.
Table 10 Problems Fixed in 2.1.00
Bug ID
|
Description
|
S1 Bugs
|
CSCdt57525
|
Symptom: APS protection channel stuck in signal fail
Condition: Remove/insert back card caused protection channel stuck in "signal fail"
Workaround: resetcd to active AXSM.
|
CSCdt62832
|
Symptom: Connections fail and links go to oneway inside with switchcc followed by resetsys
Condition: switchcc followed by resetsys without standby transitioning to Standby Ready
WorkAround: None
|
CSCdt65453
|
Symptom: None.
Condition: The ports are stuck in building vc and down in progress after resetsys on peer node.
Workaround: None
|
S2 BUGS
|
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: Down the port and re-up the port.
|
CSCds64781
|
Symptom: After delred of RPM redundant cards, the previous secondary RPM card comes up with the same configuration of the primary card which it was covering. If the auto_config_slot file for the secondary is present, this problem is not seen.
Conditions: One must do a wr mem when the secondary RPM was active. auto_config_slot# for secondary wasn't present on PXM45 before an addred.
Workaround: None.
|
CSCds78530
|
Symptom: Unable to configure the interface policy to any thing other than default values on legacy ports
Condition: Currently there is no support to reprogram the min guaranteed bw, booking factor etc. on legacy ports. As a result the qbins cannot be programmed to give some guaranteed bandwidth to specific service types like UBR, TAG etc.
Workaround: None
|
CSCdt11342
|
Symptom: CLI command (dspcds) in PXM45 will show RPM is in boot state. But in RPM Console we will be able to see RPM is UP and Running.
Condition: This problem happens when you do switchcc for 40 times. So the RPM lifetime is 40 switchovers. After switchcc, RPM cards show up 'Boot/Active' although they are actually 'Active'.
Workaround: Reset the RPM cards when this happen.
|
CSCdt11521
|
Symptom: vsiProcessVxlCommitRsp: no leg, but has Pep error message keep pop up on PXM
Condition: Reset multiple AXSM cards
Workaround: It'll stop generate error message after AXSM comes up
|
CSCdt38260
|
Symptom: pnport went into vc failure state
Condition: setrev was executed on AXSM
Workaround: None
|
CSCdt38628
|
Symptom: dspbecnt shows wrong info.
Condition: Always.
Workaround: None.
|
CSCdt43629
|
Symptom: Sev 4 'Nodal data in disk mismatch with RAM data' message appears in event log
Condition: Clock sources were deleted or re-added and switchcc executed
Workaround: None
|
CSCdt44668
|
Symptom: Loading and running new revision and adding a PXM45B card causes ATMIZER errors.
Condition:
Workaround: Unknown.
|
CSCdt45643
|
Symptom: Route Op Start/Stop messages are dropped incorrectly.
Condition: Unknown
Workaround: None
|
CSCdt51884
|
Symptom: Multiple Upgrades can take place at the same time
Condition: Issue loadrev on a set of cards and then do it on the other set
Workaround: None
|
CSCdt53257
|
Symptom: Executed tstdelay on a connection for multiple times.
Condition: On SPVC connection execute tstdelay multiple times.
Workaround: For successful tstdelay we need to try few times.
|
CSCdt56312
|
Symptom: APS switching fails intermittently. Sometimes APS won't switch back from P-W, sometimes APS switched okay but false alarm message was display "Warning: Switch Unsuccessful on Line: Due To Some Unknown Reason."
Condition: switchapsln manual(W-P) then Force(P-W)
Workaround: None.
|
CSCdt60239
|
Symptom: Switchred on the other side of 1+1 APS produces an ALM on the working line which is presently active line
Condition: Switchred on the far end
Workaround: None.
|
CSCdt67969
|
Symptom: PXM45A resets from init state.
Condition: When resetsys was given on the node.
Workaround: None.
|
CSCdt70494
|
Symptom:
1) Dspred shows secondary RPM slot as empty even though Standby - after a switchcc/resetsys/shelf power up.
2) The secondary RPM slots take a long time to come up when the secondary card is coming up after a switchcc or a resetsys/shelf power up.
Conditions: If for any reason the secondary card is trying to come up (following a reset) after a switchcc/resetsys or a shelf power up.
Workaround: None.
Under such scenario, the RPM card takes a long time to come up. And the calculation is that it waits for 3 minutes X the number of RPM cards present in the node before it comes up as standby/Active.
|
S3 BUGS
|
CSCdr28284
|
Symptoms: The CLI required the user to specify whether the connection is PVC or not. This was removed in the bug fix.
Condition: None
Workaround: None
|
CSCds44434
|
Symptom: An error log is observed in the event log after using the command cnfdiag to attempt to configure online path test diagnostic. This indicates that the attempt to configure the diagnostic was unsuccessful.
Condition: This symptom can occur when an attempt is made to configure the online path test diagnostic on a MGX 8850 switch
Workaround: None.
|
CSCds50108
|
Symptoms: dspcon shows incorrect RIF/RDF values (shifted by +1).
Conditions: When you add or modify ABR connection parameters on RPM.
Workaround: None.
|
CSCds68568
|
Symptom: AXSM does not go Active after initiating burning of new software
Condition: New software is being downloaded to AXSM. Download takes a very long time.
Workaround: None
|
CSCds68651
|
Symptom: It takes 10 minutes to reset AXSM card after QE48 is disabled.
Condition: QE48 is disabled.
Workaround: None.
|
CSCds70494
|
Symptom: No error filtering mechanisms.
Condition: Too many errors reported to HMM. The only way to stop this is to disable HMM reporting.
Workaround: None
|
CSCds87038
|
Symptom: dspdiagcnf, dspdiagerr and dspdiagstatus commands do not break after 24 lines.
Condition: Normal Operation
Workaround: None
|
CSCdt26078
|
Symptom: When executing a cc to a AXSM card, the event log logs a message 'Non-existing CommEp 0xc01b077 has invalid tag 0x????; Expected tag is 0x????.'
Condition: The deletion of an internal communication endpoint is incorrectly issuing the message. It is an annoying but harmless message. There is no other side effect.
Workaround: None
|
CSCdt42209
|
Symptom: CUT: (cuts) failed to schedule time in cutsProcessAckRecv event log message was recorded
Condition: None
Workaround: None
|
CSCdt43383
|
Symptom: The setrev on a redundant service module pair with the Primary card missing fails.
Condition: None
Workaround: None
|
CSCdt43625
|
Symptom: Allowed to configure redundancy between upper bay and lower bay.
Condition: None
Workaround: None.
|
CSCdt46552
|
Symptom: When do "dsppnportsig portId", it shows "aini" as the version. Then do "dsppnport portId", it shows port status is "up" and ILMI status is "UpAndNormal".
Condition: For PNNI port with ILMI enabled, if "cnfpnportsig" to "aini" version, then port is still up and ILMI UpAndNormal.
Workaround: None
|
CSCdt55215
|
Symptom: "Vsi_avl_tree_add did not function" message generated.
Condition: When the node was upgraded using setrev.
Workaround: Unknown.
|
CSCdt58554
|
Symptom: APS Event log is not clear enough to debug
Condition: APS events
Workaround: Look at existing APS event log.
|
CSCdt60635
|
Symptom: UniVersion for self-supporting is displayed as "none" instead of "self".
Condition: When configure the UNI port to self-supporting, the command dsppnport output shows "none".
Workaround: To verify the configuration, dsppnportsig can be used to display the configured signalling version
|
Related Documentation
Table 11 lists the documentation that supports the installation and operation of the MGX 8850 Release 2.1 switch.
Table 11 Related Documentation for the MGX 8850 Switch, Release 2.1
Documentation
|
Description
|
Cisco MGX 8850 Routing Switch Hardware Installation Guide, Release 2.1
DOC-7812561=
|
Provides a detailed description for installing the MGX 8850 switch in a restricted access location.
|
Cisco MGX 8850 Routing Switch Command Reference, Release 2.1
DOC-7812563=
|
Describes and lists the user-accessible command line interface (CLI) for the MGX 8850 switch.
|
Cisco MGX 8850 Routing Switch Software Configuration Guide, Release 2.1
DOC-7812551=
|
Describes how to configure the MGX 8850 switch.
|
Cisco MGX 8850 SNMP Reference, Release 2.1
DOC-7812562=
|
Provides information on all supported Management Information Base (MIB) objects, support restrictions, traps, and alarms for the AXSM, PXM45, PNNI, and RPM Modules.
|
Cisco MGX Route Processor Module Installation and Configuration, Release 2.1
DOC-7812510=
|
Provides information on initial site preparation, installation, and configuration of the Cisco MGX 8850 Route Processor Module (RPM-PR). Troubleshooting, maintenance procedures, and cable specifications are also provided.
|
Obtaining Documentation
The following sections provide sources for obtaining documentation from Cisco Systems.
Ordering Documentation
Cisco documentation is available in the following ways:
•Registered Cisco Direct Customers can order Cisco Product documentation from the Networking Products MarketPlace:
http://www.cisco.com/cgi-bin/order/order_root.pl
•Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:
http://www.cisco.com/go/subscription
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following sites:
•http://www.cisco.com (for example, http://www.cisco.com/univercd/cc/td/doc/product/wanbu/index.htm)
•http://www-china.cisco.com
•http://www-europe.cisco.com
Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Documentation Feedback
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Attn Document Resource Connection
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
http://www.cisco.com
Technical Assistance Center
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
Contacting TAC by Using the Cisco TAC Website
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
http://www.cisco.com/tac
P3 and P4 level problems are defined as follows:
•P3—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://www.cisco.com/register/
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
Contacting TAC by Telephone
If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
•P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.
•P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
AccessPath, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other brands, names, or trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0104R)
Copyright © 2001, Cisco Systems, Inc.
All rights reserved.