Table Of Contents
Release Notes for Cisco WAN MGX 8850,
MGX 8230, and MGX 8250 Software Version 1.1.40
Contents
Features Introduced in Release 1.1.40
16,000 Connections
RPM Multi LVC
ITU APS
RPM (RPMB/RPM-PR) 1:N
VISM 2.1(1) on MGX 8250/8850/8230
VISM 2.1(0) on MGX 8250/8850/8230
Features Not Supported in This Release
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
Service Module Redundancy Support
Major Network Management Features
Port/Connection Limits
SNMP MIB
Notes and Cautions
Stratum-3 Clocking
UPC Connection Parameters
ForeSight and Standard ABR Coexistence Guidelines
CLI Modifications in 1.1.40 Baseline
Node Related
Connection Management Related
RPM Related
RPM Front Card Resets on an MGX 8250 Switch
RPM-PR Back Ethernet Card Support
RPM/B Ethernet Back Card Support
Limitations
CWM Recognition of RPM/PR and RPM/B Back Cards
clrsmcnf
Problems Fixed in Release 1.1.40
Known Anomalies for Platform Software Release 1.1.40 and Service Module Firmware
Compatibility Notes
MGX 8230/8250/8850 Software Interoperability with Other Products
Boot File Names and Sizes
VISM and RPM Firmware Compatibility
MGX 8250/8850 Firmware Compatibility
MGX 8230 Firmware Compatibility
Comparison Matrix
RPM Compatibility Matrix
Special Installation and Upgrade Requirements
Special Instructions for Networks Containing FRSM 2 CT3
Executing the Script
Script Functionality
Single PXM Installation Procedure
Installation Procedure for Redundant PXMs
Instructions to Abort PXM Upgrade
Upgrade from Release 1.1.3x
Upgrade from Release 1.1.2x
Service Module Boot/Firmware Download Procedure
Service Module Firmware Download Procedure
Manual Configuration of Chassis Identification
MGX as a Standalone Node
Chassis Identification During a Firmware Upgrade
Interoperability of Service Module on MGX 8220 and MGX 8250 Switches
Service Module Upgrades
Route Processor Module (RPM) Addendum
About the Cisco IOS 12.2(4)T Release
About the Cisco IOS 12.2(2)T2 Release
About the Cisco IOS 12.1(5.3)T_XT Release
Problems Fixed with IOS 12.1(5.3)T_XT
Bypass Feature for RPM in 12.2(4)T IOS Release
Upgrading from an MGX-RPM-128M/B Card to an MGX-RPM-PR Card
Booting the RPM
RPM Bootflash Precautions
Upgrading with 1:N Redundancy
Upgrading Non-redundant MGX-RPM-PR Cards
Historical Information from the 1.1.3x Baseline
Features Introduced in Release 1.1.34
Online Diagnostics
adddiagtest
cnfdiagtest
cnfdiagparams
dspdiagtests
dspdiagresults
clrdiagresults
showdiagtests
deldiagtest
rundiagtest
pausediag/resumediag
clralldiagtests
Diagnostics Failure Reporting
Power On Self Test (POST) on PXM
Enhanced ATM-LMI
Buffer Allocation Priority
Problems Fixed in Release 1.1.34
Known Anomalies for Platform Software Release 1.1.34 and Service Module Firmware
Features Introduced in Release 1.1.32
Feature Descriptions
Support for Multiple RPM Card Types
Support for RPM-PR Module with MGX-PXM1
Support for RPM/B in MGX 8230
Problems Fixed in Release 1.1.32
Known Anomalies for Platform Software Release 1.1.32 and Service Module Firmware
Features Introduced in Release 1.1.3x
CoS Map for FRSM-8
DS3 Loopback on PXM-T3
Stratum-3 Clocking
ForeSight and Standard ABR Coexistence Guidelines
Independent Service Rate on FRSM-HS1/B
Online Diagnostics for PXM
SRM in MGX 8230
Standard ABR on AUSM
Standard ABR on FRSM-8 and FRSM8-C Modules
VBR-rt on AUSM
VISM 2.0.0 on MGX 8230/8250/8850
VISM 1.5.05 on MGX 8250/8850
Problems Fixed in Release 1.1.3x
Related Documentation
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco.com
Technical Assistance Center
Cisco TAC Web Site
Cisco TAC Escalation Center
Release Notes for Cisco WAN MGX 8850,
MGX 8230, and MGX 8250 Software Version 1.1.40
Contents
Features Introduced in Release 1.1.40
Release 1.1.40 is a feature release. The following table contains a short description of the features which are available with Release 1.1.40.
Feature
|
IOS
|
CWM
|
16,000 Connections supported on the MGX 8230 and MGX 8250 Edge Concentrators
|
Not Required
|
10.5
|
ITU APS Annex A Compliance PXM1 (Limited Support)
|
Not Required
|
10.5
|
RPM Multi LVC Enables support for initiation of Multiple label switched paths (LSPs) per destination on the RPM.
|
12.2(4)T
|
N/A
|
RPM (RPMB/RPM-PR) 1:N RPM 1:N redundancy is used to switch configuration and traffic from one RPM module to another module.
|
12.2(4)T
|
10.5 (except for RPM/B; no CWM support for this module)
|
VISM 2.1(0) Support
|
12.1(5.3)T_XT
|
10.4.10 or higher
|
VISM 2.1(1) Support
|
12.2(4)T
|
10.5 or higher
|
16,000 Connections
This feature extends the current capabilities of the MGX8230 and MGX 8250 Edge Concentrators to increase the number of connections (PVC) on the PXM1 based PAR Controller from 12,000 to 16,000 connections.
If the MGX is a feeder to a BPX, only 15729 feeder connections are available. 271 connections are reserved for communication between the BPX and MGX
The following table lists information about this new feature.
Compatibility
|
Limitations
|
Limits
|
CLI/MIB Changes
|
• Switch Software Release 9.2.00 and higher
•CWM 10.5 and higher
|
A downgrade from Release 1.1.40 should not be done after provisioning over 12,000 connections. If a downgrade occurs, connections above 12,000 are lost in the PAR database, and manual identification and deletion of the channels must be done from the service module.
Only after upgrading both the active and standby PXMs to Release 1.1.40 should provisioning for more than 12,000 connections be done.
BPX (with AR) software releases prior to 9.2.00 support only 12,000 connections; therefore, no more than 12,000 connections can be achieved with those releases.
|
Maximum number of PXM UNI connections supported is 4000 (as in prior releases).
|
None.
|
RPM Multi LVC
This IOS feature enables support for initiation of Multiple label switched paths (LSPs) per destination on the RPM. Up to four parallel LVCs are established per destination address and are set up dynamically between ELSR routers.
This feature enables interface level queueing rather than per-VC level on the RPM based on MPLS class of service policy. Different label switched paths are established for different class of services. This feature particularly benefits customers who wish to deploy IP VPN services in conjunction with Class of Service SLAs.
For more information about this feature, refer to the IOS document MPLS QoS Multi-VC Mode for PA-A3 at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/cos1221t.htm
The following table lists information about this new feature.
Compatibility
|
Limitations
|
Limits
|
CLI/MIB Changes
|
•Switch Software Release 9.2.30 and higher
•CWM 10.5 and higher
|
Although the architecture does not particularly limit the number of Multi-LVC connections a line card could support, the hardware of line cards set the limitation.
|
Up to four parallel LVCs are established per destination address.
|
None. All multicast connections are created or deleted by the MPLS signaling control plane through the VSI interface. Furthermore, the hardware configuration for multicast functionality is done in the system startup and requires no configuration parameters.
|
ITU APS
The following table lists information about this new feature.
Compatibility
|
Limitation
|
CLI/MIB Changes
|
•CWM 10.5 and higher
|
Software
There is no support for 1:1. Release 1.1.40 supports only a 1+1 bidirectional non-revertive configuration. Further, Release 1.1.40 supports only the OC3/STM1 (SMFIR) interface. OC12/STM4 (SMFIR and SMFLR), and OC3/STM1 (SMFLR and MMF) will be supported in a future release.
Hardware
There is no support for intracard APS configuration.
Note The CLI command addaplsln may indicate support for the other 1+1 configuration options:
–Unidirectional revertive
–Unidirectional non-revertive
–Bidirectional revertive and
However, these options have not yet been tested, and consequently, we do not support them in Release 1.1.40.
|
addapsln CLI modified
The parameter "archmode" sets the APS architect mode to be used on the working/protection line pairs. The new value "5" is added to specify 5: 1+1 Annex A.
dspapsln CLI modified
|
RPM (RPMB/RPM-PR) 1:N
RPM (RPMB/RPM-PR) 1:N redundancy feature is available on the MGX 8850, MGX 8230 and MGX 8250 switches. RPM 1:N redundancy is used to switch configuration and traffic from one RPM module to another module. The main benefits are:
•If an RPM fails and there is no operator or there is no direct access to the failed RPM to swap the card or fix the problem. The RPM might have some hardware problems and the redundant standby card can take over the functionality while the RPM hardware problems are fixed.
•Ease in Software upgrades without much down time.
The following table lists information about this new feature.
Compatibility
|
Limitations
|
CLI/MIB Changes
|
•CWM 10.5 and higher
•IOS 12.2(4)T
|
Hot Redundancy is not supported.
RPM's of the same card type can only participate in a redundancy group. i.e. RPM-B and RPM-PR cannot be redundant to each other.
Only the configuration of the failed/removed RPM card will be restored on the new card, not the state of the card.
Since the RPM provides layer 3 services and maintains routing tables for different protocols/technologies like BGP/OSPF/IS-IS/MPLS FIB tables etc., these won't be restored but will have to restart the learning process and build their tables after the standby comes up with the new configuration.
When a failed primary is replaced/recovered, the operator or network administrator has to manually switch from the secondary to primary to free up the secondary for future failures.
HSRP can be used for maintaining LAN routing redundancy but the ATM port adapter state or the switch side of the RPM, CLI, or SNMP-related data cannot be handled currently.
Layer 2 information like "inarp" tables that are created dynamically will also be lost.
Any PPP sessions that were terminated or transiting the RPM using L2TP/L2F tunnels will be restarted.
|
N/A
|
VISM 2.1(1) on MGX 8250/8850/8230
The VISM 2.1(1) Release is a maintenance upgrade of the VISM 2.1(0) Release and contains no new features. However, there are several caveat resolutions introduced with VISM 2.1(1), and you may want to refer to the VISM documentation. This release is compatible with the MGX 8850/8250/8230 release 1.1.40 software.
The VISM Release 2.1(1) is supported by Release Notes and the Cisco Voice Interworking Service Module Guide, which is available on the Web at the following locations:
•http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/vism21
•http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/vism21
•http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/vism21
VISM 2.1(0) on MGX 8250/8850/8230
VISM 2.1(0) is supported on MGX 8250, MGX 8230, and MGX 8850 switches for Release 1.1.40. For VISM upgrade instructions see the Release Notes for Cisco Voice Interworking Service Module Release 2.1(0):
•http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/vism21/index.htm
Features Not Supported in This Release
•MPLS inter AS, MPLS TE, and POS port-adapter are not supported features on RPM.
•S3 clocking
•Layer 2 support as an AutoRoute routing node
•SRM T1E1
•Interworking with Cisco 3810
MGX 8220 Hardware That Has Been Superseded by MGX 8850-Specific Hardware
•The MGX-SRM-3T3-C front card replaces the original AX-SRM-3T3-A front card and the MGX-BNC-3T3 back card replaces the original AX-BNC-3T3 back card. Both the AX-SRM-3T3-A/AX-BNC-3T3 card set and the MGX-SRM-3T3-C/MGX-BNC-3T3 card set are supported on the MGX 8220.
•The AX-SCSI2-2HSSI is superseded by the MGX-SCSCI2-2HSSI/B, which works with the MGX-FRSM-HS2 front card.
Service Module Redundancy Support
MGX 8850 provides high-speed native ATM interfaces, which can be configured as ATM UNI ports or trunks. The following table contains redundancy support information for service modules.
Front Card Model #
|
Redundancy Supported
|
MGX-AUSM-8E1/B
|
1:N redundancy
|
MGX-AUSM-8T1/B
|
1:N redundancy
|
AX-CESM-8E1
|
1:N redundancy
|
AX-CESM-8T1
|
1:N redundancy
|
MGX-CESM-2T3E3
|
1:1 redundancy
|
AX-FRSM-8E1
|
1:N redundancy
|
AX-FRSM-8E1-C
|
1:N redundancy
|
AX-FRSM-8T1
|
1:N redundancy
|
AX-FRSM-8T1-C
|
1:N redundancy
|
MGX-FRSM-HS2
|
1:1 redundancy
|
MGX-FRSM-2CT3
|
1:1 redundancy
|
MGX-FRSM-2T3E3
|
1:1 redundancy
|
MGX-FRSM-HS1/B
|
No redundancy
|
MGX-RPM-128M/B
|
1:N redundancy
|
MGX-RPM-PR-256
|
1:N redundancy
|
MGX-RPM-PR-512
|
1:N redundancy
|
MGX-VISM-8T1
|
1:N redundancy
|
MGX-VISM-8E1
|
1:N redundancy
|
Note: Support for 1:N redundancy is provided in conjunction with an MGX-SRM-3T3 card or an MGX-SRM-E card.
|
Bulk Distribution is supported using SRM-3T3-C card for T1 lines only.
Major Network Management Features
Network management features are detailed in the CWM Release 10.5.10 Release Notes at: http://cisco.com/univercd/cc/td/doc/product/wanbu/svplus/index.htm
Port/Connection Limits
Connection limits can vary. The table below shows total connections per card, but also shows the number of connections per port with LMI enabled. For example, the FRSM-HS2 card using a HSSI back card can support a total of 2000 connections on the card. However, if LMI is enabled on both ports, the total number of connections goes down. If StrataLMI is enabled for one ports, that port supports 560 connections. The other port not configured for LMI can support 1000 connections, for a total of 1560 connections.
Overall, there is a limit of 16,000 connections per shelf.
Refer to Table 1 for detailed connection information.
Table 1 Port/Connection Limits
Card Type
|
Back Card(s)
|
Conns./Card
|
Physical Ports
|
Logical Ports
|
Per port with StrataLMI
|
Per port with Annex A/D NNI/UNI
|
MGX-FRSM-HS2
|
HSSI
|
2000
|
2
|
2
|
560
|
898
|
MGX-FRSM-2CT3
|
BNC-2T3
|
4000
|
2
|
256
|
560
|
898
|
MGX-FRSM-2T3E3
|
BNC-2T3
|
2000
|
2
|
2
|
560
|
898
|
| |
BNC-2E3
|
2000
|
2
|
2
|
560
|
898
|
| |
BNC-2E3A
|
2000
|
2
|
2
|
560
|
898
|
MGX-FRSM-HS1/B
|
12IN1-4S
|
200
|
4
|
4
|
200
|
200
|
MGX-AUSM-8E1/B
|
RJ48-8E1
|
1000
|
8
|
8
|
N/A
|
N/A
|
| |
SMB E1
|
1000
|
8
|
8
|
N/A
|
N/A
|
MGX-AUSM-8T1/B
|
RJ48-8T1
|
1000
|
8
|
8
|
N/A
|
N/A
|
AX-CESM-8E1
|
RJ48-8E1
|
248
|
8
|
248
|
N/A
|
N/A
|
| |
SMB-8E1
|
248
|
8
|
248
|
N/A
|
N/A
|
AX-CESM-8T1
|
RJ48-T1
|
192
|
8
|
192
|
N/A
|
N/A
|
MGX-CESM-2T3E3
|
BNC-2T3
|
1
|
1
|
1
|
N/A
|
N/A
|
| |
BNC-2E3
|
1
|
1
|
1
|
N/A
|
N/A
|
AX-FRSM-8E1
|
RJ48-8E1
|
1000
|
8
|
8
|
560
|
898
|
| |
SMB-8E1
|
1000
|
8
|
8
|
560
|
898
|
AX-FRSM-8E1-C
|
RJ48-8E1
|
1000
|
8
|
192
|
560
|
898
|
| |
SMB-8E1
|
1000
|
8
|
192
|
560
|
898
|
AX-FRSM-8T1
|
RJ48-8T1
|
1000
|
8
|
8
|
560
|
898
|
AX-FRSM-8T1-C
|
RJ48-8T1
|
1000
|
8
|
192
|
560
|
898
|
•For the MGX8230 and MGX 8250 Edge Concentrators, 16,000 connections (PVC) on the PXM1 based PAR Controller. If the MGX is a feeder to a BPX, only 15,729 feeder connections are available—271 connections are reserved for communication between the BPX and MGX. The maximum number of PXM UNI connections supported is still 4000 (as in prior releases).
SNMP MIB
The SNMP MGX Release 1 MIB are provided with the delivery of Release 1.1.40. The MIB is in standard ASN.1 format and is located in the same directory within the 1.1.40 bundle on CCO. These files may be compiled with most standards-based MIB compilers. The tar file for MIB contains the file release notes that contains the MIB release notes.
For changes in this MIB from the previous release, please refer to the MIB release notes.
Their are two formats contained in the bundle:
old_mibFormat
new_mibFormat
Notes and Cautions
The following notes and cautions should be reviewed before using this release.
Stratum-3 Clocking
The PXM-UI-S3 back card used in previous releases to support Stratum-3 level clocking, is not supported in Releases 1.1.34 or 1.1.40.
UPC Connection Parameters
In Release 1.1.40 and higher, the default PCR is 50 cps, and the default for policing is "enabled." These settings are insufficient for running RPM ISIS protocol over the connection, and with such settings, the ISIS protocol will fail. The PCR value needs to be increased, depending upon the number of interfaces configured for ISIS on the RPM. CLI modification and changes in this release.
Depending upon your connection type, you can use the following CLIs to modify the PCR parameter.
•cnfupccbr
•cnfupcvbr
•cnfupcabr
•cnfupcubr
ForeSight and Standard ABR Coexistence Guidelines
ForeSight is similar to the rate-based ABR control system in TM 4.0 in that they both use Rate up and Rate down messages sent to the source of the connection to control the rate a connection runs at, based on congestion within the switches along that connections path. Both systems use Resource Management (RM) cells to pass these messages. There are differences between the two systems that need to be considered.
RM Cell Generation
ForeSight is a destination-driven congestion notification mechanism. The destination switch is responsible for generating the RM cells, which defaults to every 100 ms. This means that any rate modifications at the source end happen approximately every 100 ms, and the time delay between the actual congestion at the destination and the source getting to know about it could be 100 ms.
In standard ABR a source generates FRM cells every (nRM) cell intervals, where n is configurable. These are used to pass congestion information along to the destination switch, which then uses this information to generate BRM (Backward RM cells) back to the source A further consideration is that the actual user data flow will be lower for an equivalent rate due to the additional RM cells. Therefore, the more traffic being generated on a connection at any one time, the faster the feedback will be to the source.
There is also a TRM parameter which states that if no RM cells have been generated after this time has passed then one will automatically be sent. Depending upon the speed it is running at, an ABR connection may therefore react faster or slower to congestion than the equivalent ForeSight connection. (for example, if an ABR connection runs at 100 cells per second, and nRM is 32, then approximately three RM cells will be generated per second, or once every 300 msecs. If it runs at 1000 cps then an RM cell would be generated approximately every 30 msecs. In both cases, the equivalent ForeSight connection would generate an RM cell every 100 msec.)
Reaction to Feedback Messages - Rate Up
In ForeSight, in response to a Rate Up cell from the destination, the source increases its rate by a percentage of the MIR for that connection. If we call this percentage the rate increase percentage (RIP), then RIP is configurable at the card level (the default is 10 percent). In the case where MIR is low, the ForeSight rate increase will be slow as it has to increase as a percentage of MIR (rather than CIR).
On a standard ABR connection, in the event of available bandwidth (no congestion) the source increases its rate by a factor of (RIF*PCR). This means the rate increase step sizes are much bigger than for ForeSight for larger values of RIF (RIF has a range of 1/2, 1/4,....,1/32768). If RIF is not configured properly then standard ABR will ramp up its rate much faster and to a higher value. This is aided by the fact that the step sizes are bigger and the step frequency is higher in comparison with ForeSight.
Reaction to feedback messages - Rate Down
In ForeSight on receiving a Rate Down cell from the remote end, the source reduces its current rate (actual cell rate) by 13 percent. The rate decrease percentage (RDP). RDP is configurable at the card level.
In standard ABR, rate decrease is by an amount (RDF*ACR). Currently, the default value of RDF is 1/16 (6.25 percent). This means when this connection co-exists with ForeSight connections, in the event of congestion ForeSight connection reduces its rate by 13 percent whereas standard ABR connection reduces its rate by only 6.25 percent. Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types, then RDF should be changed to 1/8, so that both connections ramp down by the same amount (13 percent).
Fast-Down
In ForeSight if the destination egress port drops any data due to congestion then the destination sends a Fast Rate Down cell. Also, if a frame cannot be reassembled at the egress due to a lost cell somewhere in the network, a Fast-down will be generated. On reception of Fast Rate Down the source reduces its current rate by 50 percent (this is again a card-level configurable parameter).
Standard ABR does not distinguish between drops and the ECN/EFCI threshold being exceeded. This means that, in case of drops in the egress port queue, a standard ABR connection rate reduces by only (RDF*ACR) but the ForeSight connection rate reduces by (ACR*0.5). Therefore, in the case of co-existence, if we need to approximate the same behavior across the two connection types then Fast Down could be effectively disabled by configuring the reaction to be 13 percent rate down instead of 50 percent.
Guidelines
The two systems will work together within the network, but as the above description suggests, if the differences between the two systems are not taken into consideration, then a ForeSight connection and an ABR connection with the same configuration parameters will not behave the same way within the network.
ABR and ForeSight provide a mechanism for distributing excess bandwidth between connections over and above the minimum rate, therefore if these guidelines are not taken into consideration then the allocation of this excess bandwidth may be biased toward connections running one of these algorithms over connections running the other.
If this is a requirement, the following guidelines may be useful, assuming ForeSight is set to defaults except for Fast Rate Down which is set for 13 percent.
1. Nrm: Nrm needs to be set at a value whereby the approximate RM cell generation is
100 milliseconds, to match that of ForeSight. This calculation is based on the expected average, or sustained, cell rate of the connection. However, if the (potential) fast-down messages from ForeSight are left to equate to 50 percent rate down, then an estimate of how often this may occur needs to be made and factored into the equation. If the connection receives Fast-down messages, then this would make the ForeSight connection react faster than the equivalent ABR connection to congestion. To compensate for this, Nrm needs to be set at a value of less than 100 msecs, a suggested value to aim for is between 60-70 msecs (this would be approximate as n is configurable in steps of 2**n). This would mean that, in the event of congestion, the ABR connection would start to react faster.
2. RIF: Rate increase factor is a factor of PCR in ABR and MCR in ForeSight. The default RIF for ForeSight is MCR*.10. Therefore, RIF should be configured so that (PCR*RIF) approximates MCR*0.1. If Fast-Down is still effectively enabled, then PCR*RIF should approximate MCR*0.62 to compensate.
3. RDF: (Rate Decrease Factor) RDF should be 1/8. This approximates to 13 percent that ForeSight uses.
The following worked examples may help explain this further
Assume a network is currently running ForeSight with default parameters, and supports the following four connection type, where CIR = MIR, PIR = port speed, and QIR = PIR:
T1 Port Speed 64K CIR
Example:
CIR = MIR = 64K
PIR = QIR = port speed = 1544
Fastdown = 13%
(The calculation used to convert between frame based parameters (CIR, PIR, and so on.) and their equivalent cell-based parameters is FR_param *3/800. This allows for cell overheads, and so on. based on frame sizes of 100 octets.)
CIR = MIR = (64000*3/800) = 240 cps
PIR = QIR = (1544 *3/800) = 5790 cps
ForeSight ABR
Rate-up equals (240*.1) = 24 cps RIF equals x where (1590/x) = 24 cps
X needs to be approx 200
RIF equals 256 (nearest factor of 2)
RDF equals 13% RDF = 1/8
Nrm equals 100 msecs Nrm equals 32
RM cells will be generated somewhere between 6 (5790 cps approx equal to 32 cells per 6 msecs) and 133 msecs (240 cps approx equal to 32 cells every 133 msecs) depending on ACR.
CLI Modifications in 1.1.40 Baseline
Table 2 lists the new and modified commands in Release 1.1.40 baseline.
Table 2 New/Modified CLI Commands in This Release
CLI
|
Changes
|
For Feature
|
addapsln
|
The parameter "archmode" sets the APS architect mode to be used on the working/protection line pairs. The new value "5" is added to specify 5: 1+1 Annex A.
|
ITU APS Annex-A
|
dspapsln
|
|
ITU APS Annex-A
|
Node Related
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in to the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration publication on the documentation CD.
Step 1 Use ftp to port the Axis 5 common boot image for the service module to a workstation.
Step 2 Plug in the card into the MGX 8220 shelf.
Step 3 Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
tftp <ip address of the MGX 8220 shelf >
put <boot filename> AXIS_SM_1_<slot#>.BOOT
Insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Step 1 Log into the shelf.
Step 2 Verify that the two checksums are the same.
If not, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Caution If the checksums are not the same when you remove the service module, then the service module will not boot when it is plugged in and the service module will have to be returned using the Cisco Returned Material Authorization process.
Whenever an MGX 8850 is added as a feeder to a BPX 8600, SWSW automatically programs a channel with a VPI.VCI of 3.8 for use as the IP Relay channel. IP Relay is used to send IP data between nodes via the network handler, allowing every node in the domain to be directly addressable via IP addressing and CWM workstations to communicate with every node (especially feeders) using TELNET, SNMP and CWM protocols. If the user tries to add a channel with a VPI.VCI of 3.8, the BPX 8600 does not prevent the user channel from being added, but the MGX 8850 rejects it. To delete the added channel on the BPX 8600, and to get IP relay working you need to reset the BXM card.
In addition to clearing the entire configuration, clrallcnf clears the network IP addresses. IP addresses and netmasks stay the same (dspifip). However, it's recommended by engineering to reconfigure them using the cnfifip command. Network IP is gone (dspnwip), and must be re-configured using the cnfifip command. Refer to the entry on cnfifip in the Cisco MGX 8850 Command Reference publication on the documentation CD for syntax.
•The copychan command does not work on the MGX 8850.
A minimum of two and up to four IP addresses are needed to be configured for MGX 8850 (one or more of the following: Ethernet, ATM, SLIP) and the boot IP address. The user should use bootChange to set up IP gateway when the PXM card is just installed. The IP default gateway should be on the same subnet as the PXM board. Use the bootChange command to set correct IP address, netmask, and default gateway.
Do not install a Y-cable on the UIA CP port for PXMs. If you do, both serial ports will be enabled and you will not be able to communicate with the shelf through the console ports. If after switchcc the standby PXM loses the down-level port, it is most likely due to a downlevel Beta version of UIA back card that was shipped during field-trial only. Upgrading the UIA back card to the latest version should fix this problem.
To configure the external clock source, use the interface label 7.35. Do not use 0.33 or 7.33.
There are also routeShow/routeAdd/routeDelete commands for modifying routing tables.
You must reboot your PXM after each modification with "bootChange" for it to take effect.
- Only enter the ethernet IP address, netmask and default gateway.
- Type "." to erase incorrect entries.
tigers.1.7.PXM.a > bootChange
'.' = clear field; '-' = go to previous field; ^D = quit
host name :C <-- Please put "C".
inet on ethernet (e) :172.29.37.40:ffffff00 <-- Ethernet IP Addr/Netmask
gateway inet (g) :172.29.37.1 <-- Default Gateway
ftp password (pw) (blank = use rsh):
- Type in reboot, after this the command "ping" will work:
tigers.1.7.PXM.a > ping 171.71.54.53 1
Service module upgrades error handling is not provided. If the user skips any of the steps during upgrade or if a power failure happens in the middle of the upgrade, results will be unpredictable. See the Special Installation and Upgrade requirements section for service module upgrades. To recover from procedural errors contact your TAC support personnel.
The MGX 8850 supports 15 simultaneous Telnet sessions and 10 TFTP sessions.
You must use the following Y-cables for FRSM-HS2 and FRSM-CT3 redundancy as specified in the Product Orderability Matrix (Straight Cable: 72-0710-01, Crossover Cable: 72-1265-01, Straight Y-cable: FRSM-HS2: CAB-SCSI2-Y, FRSM-CT3: CAB-T3E3-Y). Other cables are not supported.
Y-cable redundancy for FRSM-HS2, FRSM-2CT3, FRSM-2T3, FRSM-2E3 is supported only for adjacent slots.
There is no need to issue the syncdisk and shutdisk commands before removing the PXMs. The system quiesces the disk by detecting the removal of the PXM board and flushes the write buffers to the disk and puts the PXM in sleep mode. This disables any further hard disk access since it locks the actuator. When the card is reinserted the PXM automatically comes out of sleep mode.
Caution Cooling and Power limitations: Customer should be aware of the need for extra power supplies and fans beyond certain limitations. A single fan tray will support all configurations that draw between 1200 and 1400 watts. For power requirements, the MGX 8850 requires a minimum of one power supply per line cord to support the power requirement for five cards.
| |
0-5 Cards
|
6-10 Cards
|
11 and Above
|
Single Line Cord (N+1):
|
2
|
3
|
4
|
Dual Line Cord (2N):
|
2
|
4
|
6
|
This is based on an estimated worst-case power requirement of 190W plus margin per card slot.
Connection Management Related
The name of the node cannot be changed if there are PVCs. The node name must be changed from the default value before adding connections, since it cannot be changed later. Use the cnfname command to change the node name.
Only one feeder trunk can be configured. No BNI trunk to MGX 8850 as a feeder is supported.
The slave end of a connection must be added first.
The slave end cannot be deleted and re-added back by itself. If you delete the slave end, the entire connection must be completely torn down and re-added back. If the slave end of the connection is deleted and re-added back by itself, then unpredictable results will happen.
For user connections, VCI 3 and VCI 4 on every VPI are reserved for VPC OAMs.
The actual number of feeder connections you can provision on the PXM is always two less than you have configured. The dsprscprtns command shows max connections as 32767, but you can only use 32767 - 2 = 32765. One connection is used for LMI and another one for IP relay.
There is no error handling detection while provisioning through the CLI. Invalid endpoints and unsupported connection types (such as connections between FRSM-CESM ports or connections between structured and unstructured connections) are permitted using the CLI. The user should not configure these connections.
The sum of CIR of all channels of a port can be greater than port speed as long as CAC is disabled. However, it is not acceptable for one channel's CIR to be greater then port speed even if CAC is disabled. Two channels added up can exceed port speed. This means you cannot oversubscribe a port if only one channel is configured.
When trying to add a port on DS0 slot 32 of a CESM-8E1 line using an SNMP set or the CiscoView Equipment Manager, the SNMP agent in CESM will time out, without adding the port. The SNMP libraries treat the 32 bit DS0 slotmap (cesPortDs0ConfigBitMap) as an integer. The value for the last DS0 is treated as the sign value. This causes a corruption in the packet coming to the agent. As the agent does not receive a complete SNMP packet, it does not respond and times out. Use the command line interface to add a port on DS0 slot 32 of a CESM-8E1 line.
The cnfport command does not allow VPI ranges to be reduced. The cnfport command only allows the VPI range to expand. The correct sequence is to delete all connections on the partitions, delete the partitions, delete the port, and add the port with new VPI range.
On an FRSM-2CT3, one can add 128 ports on a group of 14 T1 lines as indicated below.
• lines 1 to 14: 128 ports (A)
• lines 15 to 28: 128 ports (B)
• lines 29 to 42: 128 ports (C)
• lines 43 to 56: 128 ports (D)
So, to add 256 ports on one T3: add 128 ports on the first 14 T1 lines and the remaining 128 on the next 14 T1 lines.
Note that (A) and (D) are connected to first FREEDM and (B) and (C) are connected to the second FREEDM. Each FREEDM supports only 128 ports. If 128 ports are added on one T3 as in (A), then there cannot be any more ports as in (D). The 129th port should be on lines 15 to 42 (as in B or C).
If the user adds a connection between an RPM and a PXM and then deletes the connection, the RPM shows no connection but the PXM still has the connection. The MGX was designed and implemented in such a way that only the connections that have the master end show up on PXM (by dspcons command). Consider these three connections:
•c1: has only slave end
•c2: has only master end
•c3: has both master and slave end
When using the dspcons command, c2 and c3 will be displayed, not c1. The connection will not show up once the master end (PXM) is deleted. Recommendation: When adding a connection, if one end of the connection is PXM, always configure the PXM side to be the slave. Thus when deleting the RPM side, which is the master, the connection will not show up on the PXM. However, keep in mind that the slave end (PXM) still exists. This also provides a side benefit. When a connection exists with only the slave side, no bandwidth is occupied. The bandwidth is reserved only if the master end exists (with or without the slave).
The MGX-FRSM-HS1/B is capable of supporting a total throughput (card-level) of 16 Mbps. However, it is possible to configure four lines each supporting up to 8 Mbps, thus oversubscribing the card. This has been raised in bug #CSCdm71476 and a restriction/warning will be added in a future release.
Addlnloop on an FRSM-HS1/B line works only when there is a (valid) cable plugged in to the back card on that line. This is a hardware limitation on the back card and has been mentioned in the Release Notes in bug# CSCdm44993.
RPM Related
The RPM/PR and RPM/B operate under the following IOS and Release 1 software.
MGX SW version
|
1.1.24
|
1.1.3
|
1.1.32
|
1.1.34
|
1.1.40
|
"Bundled" IOS SW version
|
12.1(3)T
|
12.1(3)T
|
12.1(5.3)T_XT
|
12.2(2)T2
|
12.2(4)T
|
IOS Version for RPM-PR
|
not supported
|
not supported
|
12.1(5.3)T_XT*
|
12.2(2)T2
|
12.2(4)T
|
IOS for MGX-RPM-128M/B in MGX 8230
|
not supported
|
not supported
|
12.1(5.3)T_XT
|
12.2(2)T2
|
12.2(4)T
|
CWM
|
9.2.08
|
10.3
|
10.4.01
|
10.4.01 Patch 1
|
10.5
|
Note *Support for MGX-RPM-PR is FCS with Release 1.1.32.
|
With MGX Release 1.1.32, two Route Processor Modules (RPMs) are supported; the MGX-RPM-128M/B and the MGX-RPM-PR.
The MGX-RPM-128M/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. The RPM-PR will only operate with IOS 12.1(5.3)T_XT or later. For the following section "RPM" will refer to both the MGX-RPM-128M/B and the RPM-PR, (unless specifically called out) even though some software versions and limitations are not applicable to the RPM-PR because it doesn't support IOS versions before 12.1(5.3)T_XT.
With MGX-RPM-128M/B versions earlier than 12.O.7T1, some limitations in Inter-Process Communication when the MGX-RPM-128M/B is at high loads can cause the PXM to declare that the MGX-RPM-128M/B has Failed. To avoid this with MGX-RPM-128M/B, software releases earlier than 12.0.7T1, throughput is limited to 62,000 pps, and it is recommended that MPLS configurations are limited to 100 interfaces. With RPM software releases from 12.0.7T1, those limitations are removed. In a separate limitation, the number of directly connected OSPF networks supported by an RPM is currently limited to 27. This means that any or all of the subinterfaces supported by the RPM can run OSPF, but the number of distinct OSPF networks supported is limited to 27. (A work around is available and is discussed below.) The limit of 27 arises because of the overheads of supporting separate link-state databases for separate networks.
In an application where the RPM is a Provider Edge Router in an MPLS Virtual Private Network service, a much better solution in any case is to use a distance-vector routing protocol between the customer routers and the RPM. A distance-vector routing protocol provides exactly the information required for this application: reachability information, and not link-state information. The distance-vector routing protocols supported by the RPM are BGP, RIP v1 and RIP v2, as well as static routing. With RPM software releases from 12.0.7T1, distance-vector routing protocols can be used with as many different networks as subinterfaces.
Note that if the RPM is acting as a Provider Edge Router in an MPLS Virtual Private Network service, and even if OSPF is running in a customer network, it is not necessary to run OSPF between the customer router and the RPM. If the customer edge devices run Cisco IOS, they can redistribute OSPF routing information into RIP using the IOS commands, redistribute RIP in the OSPF configuration, and redistribute OSPF in the RIP configuration. Similar configurations are possible for BGP. (For more information on re advertisement, see the "Configuring IP Routing Protocol-Independent Features" chapter in the Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1). Redistribution is not unique to Cisco CPE, and other vendors' equipment also supports redistribution.
RPM Front Card Resets on an MGX 8250 Switch
The RPM front card may reset on an MGX 8250 switch when the ethernet back card is removed or inserted.
This reset problem can be easily avoided if "shut" interface is executed before the removal of the back card.
RPM-PR Back Ethernet Card Support
For Ethernet connectivity with the MGX-RPM-PR, the model "/B" four-port Ethernet back card is required (order number: MGX-RJ45-4E/B).
RPM/B Ethernet Back Card Support
The model "/B" four-port Ethernet back card can be used with the MGX-RPM-128M/B module only in combination with IOS 12.2(2)T2 or higher. The model "/B" back card will not work on the MGX-RPM-128M/B with earlier versions of the IOS.
The order number is order number: MGX-RJ45-4E/B.
Older back cards can be used with any version of the IOS.
4-port Ethernet back card used with RPM/B
|
Required IOS
|
model "/B" back card
|
12.2(2)T2
|
earlier back card models
|
Min. IOS for MGX-RPM-128M/B on MGX 8250 is 12.0(7)T
|
Limitations
CWM Recognition of RPM/PR and RPM/B Back Cards
CWM does not distinguish between the Ethernet back card versions installed with the MGX-RPM-128M/B or MGX-RPM-PR. There is no functionality difference.
clrsmcnf
As a speedy way to wipe out all configuration on an SM, you can use clrsmcnf. This command works in the following scenarios:
•SM not in slot
•SM in slot and in active (good) state
•SM in slot but in failed state, boot state or another state.
To be able to use an SM of a different type from the current one in a slot you can also use clrsmcnf for example, if there is a FRSM8T1/E1 in the slot with some configuration and the customer wants to use this slot for an AUSM8T1/E1 card.
The following are NOT supported on the MGX 8850:
•Saving a configuration of an SM from one shelf and restoring it to the same slot on another shelf.
•Saving a configuration of an SM in a slot and restoring it to another slot of the same card type.
Problems Fixed in Release 1.1.40
The following is the list of problems fixed in the service module firmware and the Release 1.1.40 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCds10286
|
Symptom:
The PXM displays the incorrect error message when trying to switch APS line using switchapsln CLI. The error message seen is "Manual Switching is blocked by SF or SD on PROT line" which is incorrect when the switch is being attempted from Protection line to working line.
Conditions:
An OC-12/OC3 trunk/line is configured as 1+1 unidirectional mode on the PXM. When the working line is in LOS and a MS APS switching request is made, the PXM incorrectly shows the request is blocked by SF or SD on protection line.
Workaround:
None. It is just erroneous message and it can be ignored.
|
CSCds20689
|
Symptom:
When the received traffic of the working line PXM connected to the BPX in APS 1+1 mode is restored, the BPX switches back immediately.
Conditions:
The restoration of the receive flow of the working line of the PXM.
Workaround:
None.
|
CSCds47676
|
Symptom:
When the clock level is configured to be STRATUM-3, the PXM trunk card does not receive the STRATUM-3 clock signal. The trunk card still gets the STRATUM-4 clock.
Conditions:
When the clock level is set as STRATUM-3, the STRATUM-3 clock signal does not output to the PXM trunk card. The PXM trunk card still gets the STRATUM-4 clock. However, the service modules do receive the STRATUM-3 clock.
Workaround:
No workaround currently.
|
CSCds48471
|
Symptom:
When an IMA port and ATM port are added in a AUSM card and ILMI is enabled on both, after ILMI failure clears, dspcd still shows Minor alarm with PORT ILMI fail.
Condition:
Happens on 5.0.13 AUSM firmware.
Workaround:
Execute find_out_port_fail_for_shelf_alarm under shellConn in AUSM. This will clear the problem.
|
CSCds58040
|
Symptom:
Cannot login to an 8250 switch using a newly created userid.
Conditions:
In 8250 switch releases 1.1.30 to 1.1.32, a new user account is created using the command adduser and subsequent command xcnfuser.
Workaround:
Create the new user account with the command adduser, then before the xcnfuser command is used for the newly created account, login using the new account from another terminal and logout.
|
CSCds90138
|
Symptom:
Upon receiving Path-RDI, the PXM status LED goes RED. No trap is generated. The alarm is reflected from the dspalm command display.
Conditions:
This symptom occurs when the Sonet line receives only Path-RDI alarm. Actually, this should happen in all versions of PXM prior to this fix version.
Workaround:
None.
|
CSCdt19187
|
Symptom:
The commands dspcons or dspchans increment the LocalVpIdNextAvailable by 2.
Conditions:
This problem occurs when the commands dspcons or dspchans are executed.
Workaround:
None. Not Service Impacting.
|
CSCdt28566
|
Symptom:
Frames are dropped due to port queue overflow without any frames being tagged on the egress direction. When the command dspchanct is executed for the channel, increasing values for FramesDiscarded count and FramesByteDiscarded in the transmit directions observed. When the command dspportcnt is executed for the port, increasing values for XmtFramesDiscXceedQDepth and XmtBytesDiscXceedQDepth in transmit direction are observed.
Conditions:
This problem occurs when the queue threshold for the port is configured very low.
Workaround:
Use the command cnfegrq to configure the queue threshold accordingly. Note that in the case of Ratio Based Servicing, the high priority queue number is 1 and low priority is 2. In the case of WFQ, use the class of service index to refer to the queue number.
Verify that the values are set properly using the shellConn command eseQueInfoShow. This command takes two parameters—the port number and the queue number.
After setting the threshold to proper values, reset the card to get the changes into effect.
Further Problem Description:
The command cnfegrq does not update the cached copy of the port queue thresholds. Therefore, it is necessary to perform a reset to implement the new configuration. More over, the dspegrq command should be unblocked to make it available, irrespective of the type of servicing algorithm used in the card. Also, the command cnfegrq should be fixed to update the cached data structure and display proper queue numbers to use during different servicing algorithms.
|
CSCdt87411
|
Symptom:
With an MGX configured and connected to an External clock source it has been observed that on a switchcc, the newly active PXM fails the external clock and switches to the internal clock for up to 10 seconds.
Conditions:
This problem occurs when an external clock is configured on the node.
Workaround:
None.
Further Description:
This problem, in turn, creates errors on 64K, unrestricted data calls and could cause problems on high speed modem calls.
|
CSCdu14185
|
Symptom:
User is unable to add an RPM connection.
Conditions:
This problem occurs when using the CWM interface to add the RPM to RPM connection from MGX8250 to MGX8230.
Workaround:
Use Configuration Manager to add 3-segment connection: ATM(RPM) - ATM(RPM).
|
CSCdu17838
|
Symptom:
Line alarms clear after a card reset if lines are connected back to back on the same card.
Conditions:
This problem occurs only when 2 lines on the same card are connected back to back.
Workaround:
Up the other side of the lines and delete it.
|
CSCdu31948
|
Symptom:
When an ABR1 XPVC is provisioned via proxy across a hybrid network, from MGX1/AUSM-8T1 to MGX1/AUSM-8T1,the "egress service rate" is not configurable. The resultant default is a rate that limits the egress traffic, preventing the AUSM from attaining its PCR setting. Consequently, the PCR/MCR traffic management feature is compromised.
Conditions:
This occurs when AUSM-8T1/8E1 is provisioned as an endpoint of an XPVC connection for ABR1.
Workaround:
None.
|
CSCdu39315
|
Symptom:
Sometimes can't add more than 3000 connections.
Condition:
Dangling connection in the PAR database taking up the last entry in a connection block. System still thinks it has one more free entry in the connection block to allocate and hence allocation of new block is not triggered. In reality, we don't have a free entry anymore it has already been taken up by the dangling connection.
Workaround:
None.
|
CSCdu51930
|
Symptom:
Some 3-segment connections originating from a PXM UNI port stays in FAILED status after the system has been reset or after a power cycle.
Condition:
This problem occurs when the PAR receives an interface trap for the feeder interface before LMI channels are configured. This usually happens when there are lots of connections configured on the node.
Workaround:
Perform a switchcc on the PXM, or perform addlmiloop and dellmiloop on the PXM. Alternatively, perform cnfenhlmi to enable enhanced LMI for traffic passing through those connections.
|
CSCdu79008
|
Symptom:
T1 alarm counters are missing.
Conditions:
This problem is observed on the FRSM-8T1E1.
Workaround:
None.
|
CSCdu88301
|
Symptom:
On a FRSM-HS1/B card, in instances when traffic in excess of CIR is received from the network side, it causes egress buffer overflow. Consequently, this causes the card to reset.
Conditions:
This problem occurs only on the FRSM-HS1/B running with Version 10.0.22.
Workaround:
Egress data buffer overflow can be checked by using the shellConn command SarShow on the FRSM-HS1/B. An upgrade of the FRSM-HS1/B firmware to 10.0.23 resolves this problem.
|
CSCdu02695
|
Symptom:
When MGX is running on external clock and SM lines are set to local timing, we intermittently see slips on attached device interface even though both the attached device and the MGX show they are both taking clock from the same external source.
Conditions:
This happens when external clock is the current clock for the node.
Workaround:
If the external clock is disconnected and reconnected from the Active PXM UI card, the clock slips then stop and all is OK.
|
CSCdu12023
|
Symptom:
With a 120 ohms E1 clock source plugged into a PXM-UI= card (via RJ45 port), configuring the external clock type via the cnfextclk command to an incorrect value does not impair the clock source attached. The MGX still reflects the presence of the E1 external clock source when executing a dspcurclk command.
For example, configuring the external clock source type as T1, does not disturb the presence of the external E1 clock source physically plugged into the PXM-UI=. dspcurclk will continue to accept the external E1 clock source as the current clock, irrescpective of what is configured via the cnfextclk.
Conditions:
This Symptom occurs when an external Clock source is used.
Workaround:
None.
|
CSCdu27251
|
Symptom:
CESM card sometimes gets stuck in the failed state if a resetcd is done on it. The CESM may also go in the failed state if a cc is done to the card or the addcon command is executed on it.
Conditions:
This happens if the PXM has a UI-S3 back card and a switchcc is done. The shelf needs to be running on Stratum-3 level internal oscillator for this symptom to occur.
Workaround:
If the shelf is running on Stratum-3 level internal oscillator and there is a switchcc, re-execute the following command on the new active card:
cnfclklevel 3
Further Problem Description:
Please contact cisco TAC for a workaround referencing this bug id.
CESM shows up as failed on the PXM. A shellConn command scmConnShow will not show a connection built to the failed card.
In example:
-> scmConnSho scmConnShow 6
<SCM> Connection with standby PXM is up <SCM> Connection with SM 1 is up <SCM> Connection with SM 2 is up <SCM> Connection with SM 5 is up <SCM> Connection with SM 13 is up <SCM> Connection with SM 14 is up <SCM> Connection with SM 17 is up <SCM> Connection with SM 18 is up <SCM> Connection with SM 30 is up value = 1 = 0x1
Here we do not see the connection with SM 6 and this the card 6 (CESM) shows up as failed when you do a dspcds on the PXM.
|
CSCdu29422
|
Symptom:
The trap manager doesn't get deleted from the standby card.
Condition:
This symptom occurs on MGX Release 1 switches, Version 1.1.33Al. Trap managers are added; this gets updated on the standby, too. Upon aging, they are deleted only on the active card and not on the standby card. (On a switchcc, trap managers are seen as enabled, despite aging).
Workaround:
Not known.
|
CSCdu54264
|
Symptom:
The command switchapsln s x does not work.
Conditions:
This symptom occurs when APS is configured.
Workaround:
None.
|
CSCdu58229
|
Symptom:
The APS switches are working to protect on the BXM side but not on the PXM side.
Conditions:
This symptom occurs with the following combination: a BPX switch with APS configured as bidirectional, non revertive and a remote node on an MGX Release 1 PXM switch with the same APS configuration. The following sequence of events occurs:
1. Due to either a manual switch or a force switch, the protection line is the active line.
2. There is a fiber-cut/LOS on the receive side of protection line at the BPX end.
Workaround:
Perform an APS lock on the PXM and do an APS clear.
|
CSCdu58798
|
Symptom:
Following a replacement of the PXM card addcon fails when adding a connection between the PXM and an AUSM (other card types were not tried).
Conditions:
During automatic deletion (triggered by Resync) of a complete connection the Slave end is not deleted from the PAR database but was deleted from the SM/SPM database. This will disable the user from reading the slave connection.
Workaround:
None.
|
CSCdu62613
|
Symptom:
On a BPX switch (BXM), a clearing request APS Force W->P switches the active line to working.
Conditions:
This symptom occurs with a APS 1+1, bidirectional, non revertive configuration om a BXM connected to a PXM. In sequence, both nodes start on "protect" with no requests. On the PXM, a manual P->W. On a BXM, force W->P. On a BXM, clear requests.
Workaround:
Clear any request on PXM before issuing a request on the BXM.
|
CSCdu72190
|
Symptom:
On an active PXM, a reset occurs due to "Software Error Reset." The standby PXM took over, and there was no service impact.
Conditions:
This symptom occurs when CiscoView is running and SRM T3 lines are enabled. The time it takes for the PXM to reset depends upon the number of instances of CiscoView running. The PXM reset happens approximately every 4 hours when running more than 80 instances of CiscoView.
Workaround:
None.
|
CSCdu17049
|
Symptom:
On an MGX 8250 switch running Version 1.1.25, if an addcon is done on an RPM and the remote end of the connection is on port 256 of a FRSM-2CT3, the command is rejected with the following message:
Error:addcon:0:Connection add request to PXM failed.
If an attempt is made to add a connection from the RPM to a port numbered 255 or lower, the connection is added.
If an attempt is made to add a connection from another module, for example, an AUSM, to port 256 on the FRSM, the connection is added.
This problem is reproducible in version 1.1.32.
Conditions:
Connection is provisioned from RPM to FRSM-2CT3 with the port number on the FRSM as 256.
Workaround:
The current workaround is to use a port number less than 256 when adding connections between the FRSM-2CT3 and the RPM.
|
CSCdu32873
|
Symptoms:
The command dspnovram does not have options to dump SRM backcard information.
Conditions:
This symptom occurs in all versions where this command is implemented up to (not including) the version where this is fixed.
Workaround:
None.
|
CSCdu36455
|
Symptom:
After creating more than 20 users, some of the users encounter password corrupted.
Conditions:
This symptom occurs in instances when large number of users are added to the node.
Workaround:
None.
|
CSCdu42117
|
Symptom:
The command dsplog display the following message:
Unable to config requested clock source because clock source 8 is unknown.
Conditions:
This message is seen when the clock source or the node changes.
Workaround:
None.
|
CSCdu62281
|
Symptom:
The command dspnovram 1 bkpl command fails on an MGX 8230 switch with Translation Lookaside Buffer (TLB) exception.
Conditions:
This symptom occurs when executing the dspnovram command.
Workaround:
None.
|
CSCdu63686
|
Symptom:
The port M32EgressQueThresh is not preset in the CF file. This impacts CWM.
Conditions:
This symptom occurs during a TFTP of.CF file.
Workaround:
None.
|
CSCdu74317
|
Symptom:
When sending SNMP queries to some par related objects, a memory leak occurs.
Conditions:
Always.
Workaround:
None.
|
CSCdu83011
|
Symptom:
The misleading message:
"possible red table corruption"
is displayed when trying to do a softswitch.
Conditions:
Message is displayed when the redundancy card is cover card A and a softswitch it tried from card B to the redundant card.
Workaround:
None. No actual impact. other than the warning message creating confusion.
|
CSCdv00405
|
Symptom:
The LMI protocol version negotiation is unsuccessful between MGX2 and MGX1; however, this is not detected by the system.
Conditions:
The symptom occurs when MGX Release 2 initiates LMI version negotiation with a version other than 0, 1, 2 or 3 with MGX Release 1. MGX Release 1 will acknowledge this version, even though it does not support it. MGX Release 1 supports LMI version 0,1, 2 and 3 at this point in time.
Workaround:
None.
|
CSCdv04213
|
Symptom:
1. Both the primary and the secondary cards are in active state.
2. The secondary card is locked, and unable to change card to the card.
3. The line on CESM T3 generates alarms.
Conditions:
This symptom occurs when a "softswitch" is done from primary (active) to the secondary (stdby), followed by a reset of the active (secondary).
Workaround:
Unknown.
|
CSCdv08621
|
Symptom:
IP connectivity to the Release 1 MGX switch node stops working.
Conditions:
IP connectivity is via a PVC configured between a UNI port and 7.34 on the PXM.
Workaround:
Delete the connection and read it.
|
CSCdv44080
|
Symptoms:
Delete sub-interface from RPM using "no int sw1.xxx". But it will reappears in PXM Database after the periodic bulk update.
Condition:
When the sub-interfaces gets deleted on the RPM, it will also remove that sub-interface's entry from PXM database. But the periodic bookplate (sent every 2 hours by RPM to PXM) will update the PXM database with wrong data about this deleted sub-interface. After the bulk update, PXM database will show that sub-interface exists (in PXM database) but in reality it won't exist on the RPM. CWM RPM port table will also show this inconsistency.
Workaround:
None.
|
Known Anomalies for Platform Software Release 1.1.40 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.1.40 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCdk63771
|
Symptom:
AUSM and FRSM cards do not display expected alarm activity in bulk distribution mode.
Conditions:
Tis symptom occurred during the following conditions:
1. Added lines in FRSM, and configured for bulk mode.
2. Added a loopback in the SRM-3T3 card. All the lines in FRSM went out of alarm.
3. Removed the SRM card. The FRSM lines didn't go into alarm. (Not expected)
4. Reset the FRSM card. It came up with the lines in alarm. (Expected)
5. Inserted the SRM card. The FRSM lines were still in alarm. (Not expected)
6. Reset the FRSM card. Came back without alarm. (Expected)
Workaround:
After removing and reinserting SRMs, reset the AUSM and FRSM cards under bulk distribution to clear alarms.
|
CSCdm10722
|
Symptom:
Execution of the newrev command before the install is not rejected by the PXM.
Conditions:
During a graceful upgrade of the image on SMs, execution of the newrev command before the install is not rejected by the PXM.
If the commands (1) install (2) newrev (3) commit are not given in this order, two different images can be running on the primary and the secondary cards.
Workaround:
Assuming that these commands were given out of order, and there are two different images running on the primary and the secondary, use the following key to follow the steps below:
f1=Old image version
f2=Newly downloaded image
1. Reset the secondary card so that it comes up with f2.
2. Do a softswitch between the two cards so that secondary takes over and becomes active. At the same time, the primary is reset and comes up with f2.
3. You can now do a softswitch to revert back to the original primary, thus restoring normal state.
|
CSCdm18830
|
Symptoms:
Using the command cnfdate to configure a year greater than 2020 generates software error 22102.
Workaround:
Only configure the year up to 2020.
|
CSCdm92345
|
Symptom:
This problem occurs with a VHS service module having either DAX or FEEDER connections on the logical port, simulated with some type of signalling. With the simulated line in logical (diagnostic) loopback, the CWM shows failed connections. However, after deleting the diagnostic loopback from the line, and despite the fact that traffic runs well through the connections, the connections do not come back in OK state. The CLI shows the correct status of the connections, but CWM does not show the correct status of the connections once they go to the fail state.
Conditions:
There could be a problem in trap handling.
Workaround:
None.
|
CSCdp00537
|
Symptom:
When the fan tray is removed, the Shelf Integrated Alarm is not correctly updated and traps are not consistently sent.
Conditions:
This symptom occurs when a fan tray is removed.
Workaround:
None.
|
CSCdp44837
|
Symptom:
When deleting a large number of connections using a script, resources were not properly freed for some connections.
Conditions:
Unknown.
Workaround:
Do a switchcc.
|
CSCdp50045
|
Symptom:
During boot time, "VC create failed" message is displayed.
Conditions:
This message appears when there is a VC configuration in the config. file.
Workaround:
There is no impact on the functionality.
|
CSCdp55811
|
Symptom:
On the FRSM 2CT3 when a DS3 is enabled, all the 28 DS1s also gets enabled. Then alarms are observed on the unused lines. The problem is differentiating between false alarms and the usual alarms.
Conditions:
The symptom occurs when only a few of the DS1s are used out of a DS3.
Workaround:
Ignore the alarm or add a loop from the CPE devices.
|
CSCdr71479
|
Symptom:
The symptom occurs when using 1:N redundancy on the MGX8250 switch or the MGX 8850 switch (PXM1). If slot 9 or 25 are configured in the 1:N group, upon transitioning to or from slot 9 or 25, line alarms are generated. To date, the alarms observed have been RcvLOS (Receive Loss of Signal). The alarm clears upon returning to the original service module.
Conditions:
1:N redundancy must be configured with slot 9 and/or 25 as either the redundant card (1) or in the working group (N). Upon a transition to or from slot 9 or 25, the physical lines will go into alarm. To date, the alarms observed have been Loss of Signal.
This symptom has been seen in 1.1.21, 1.1.23, 1.1.3x, and 1.1.32. This has been confirmed with CESM and AUSM, but is not service module specific.
Workaround:
The only known workaround is to not use slot 9 or slot 25 in the 1:N redundancy group.
|
CSCds11679
|
Symptom:
The BPX 8600 switch receives lots of trap (50609, 50612) from the MGX feeder.
Conditions:
The APS line continuously changes state when the backcard is not inserted properly.
Workarounds:
1. Remove and insert the backcard properly.
2. Delete the configured APS configuration.
|
CSCds12647
|
Symptom:
From Cisco Wan Manager, v9.2.07, Connection Manager, customer tries to create a new nrtVBR3 connection on MGX8850.
There are three passwords: login, password, and RPM enable password. Customer has verified that:
login = PXM login password = PXM password RPM enable password = RPM enable password.
In order to connect to this device using Connection Manager, the customer must configure on the MGX the RPM vty password and enable password as the same. This is NOT ACCEPTABLE due to a possible security breach. If a customer knows the vty login, then they will also know the enable password to the RPM.
Workaround:
None.
|
CSCds15474
|
Symptom:
The CESM confirms incorrect configuration modifications.
Conditions:
This symptom occurs when you try to modify the timeslot value for an unstructured port.
Workaround:
Under investigation.
|
CSCds28525
|
Symptoms:
The alarm status for the connection shown on the CESM and the PXM do not match. The commands tstcon and tstdelay fails for these connections.
Conditions:
Of note, one condition appears to be for a low partial-fill value.
Workaround:
Assigning a partial-fill value of 47 sometimes solves the problem.
|
CSCds48471
|
Symptom:
This symptom is observed when an IMA port and an ATM port are added in a AUSM card and ILMI is enabled on both. After an ILMI failure clears, and the dspcd command is executed, the display still shows Minor alarm with PORT ILMI fail.
Condition:
This symptom happens on 5.0.13 AUSM firmware.
Workaround:
Execute find_out_port_fail_for_shelf_alarm under shellConn in AUSM. This will clear the problem.
|
CSCds52875
|
Symptom:
The Ingress/Egress traffic was stopped after the card was reset or upgraded for ports configured for algorithm 4. The Maxbwinc value is not retained after the reset/upgrade. The value of Maxbwinc is reset to 0 after this action; hence, traffic is stopped.
Conditions:
This happens when the card is reset/upgraded.
Workaround:
Problem under investigation.
|
CSCds59688
|
Symptom:
The CESM T3/E3 card fails to upgrade to 10.0.20. The card is stuck in standby mode.
Conditions:
An upgrade to 10.0.20 fails for CESM T3/E3 cards. While the port/connection disappears from the CESM card, the PXM retains some information.
Workaround:
None.
|
CSCds65528
|
Symptom:
The statistics alarms are not shown in the command display for dsplns. It is not implemented.
Conditions:
The statistics alarm in the command display for dsplns always shows NO.
Workaround:
None.
Further Problem Description:
The statistics alarm for CESM was never implemented. Therefore, the statistics column in dsplns command always displays NO.
|
CSCds65622
|
Symptom:
The command dspcons status on the PXM and on the CESM are inconsistent.
Conditions:
Channel failure might create this situation.
Workaround:
None.
Further Problem Description:
Channel level traps are not sent from the SM to PXM because of some design limitation on PXM. This is the reason why we see inconsistency.
|
CSCds72807
|
Symptom:
When configuring LMI on port 2 VHS2CT3, LMI failure results. Even after reversing the values, the port still remained in alarm.
Conditions:
The symptom occurred on a PXM with an 0C3 line, Release 1.1.3x and VHS2CT3 card. All conditions and alarms were normal before trying to configure LMI. The command cnfport 2 S n n was executed, then dsplns to show port 2 in alarm. An attempt was made to reverse the LMI values, but the port still remained in alarm.
Workaround:
None.
Further Problem Description:
None.
|
CSCds73028
|
Symptom:
After deleting the master side of the connection from the RPM, there is still an assigned channel for this connection on the PXM.
Conditions:
This symptom occurs when deleting a master connection on the RPM side.
Workaround:
None.
|
CSCds81358
|
Symptom:
When you configure a 3-segment connection on CESM cards, one of the cards stays in alarm state even though the other side is out of alarm.
Conditions:
This symptom is observed when a 3-segment connection is added.
Workaround:
Deleting and reading the connection intermittently brings the connection out of alarm.
Further Problem Description:
Under Investigation.
|
CSCds82759
|
Symptom:
The console port to the RPM is sometimes stuck after running copy start to running-config. However, another telnet session can be opened, and there is no impact to traffic flow.
Conditions:
This symptom occurs when copying the startup config to the running config from the console port.
Workaround:
None.
|
CSCds86720
|
Symptoms:
One end of a frame-forwarding connection is continuously on alarm.
Conditions:
This symptom occurs whena frame-forwarding connection is added using a DLCI other than 1000.
Workaround:
Delete the connection, then add it using DLCI = 1000.
|
CSCds86780
|
Symptom:
The commands dspcd, dspln, dsplns, dspport, dspports, dspcon and dspcons never prompt after adding multiple 3-segment connections.
Conditions:
This symptom is observed when adding multiple 3-segment connections on an MGX 8850 switch using a script.
Workaround:
None.
|
CSCds88404
|
Symptom:
A pattern slip occurs on a CESM-8E1 connection under the following two situations.
•Changing CDVT for CESM connection —pattern slips intermittently for a few minutes.
•switchcc—pattern slips intermittently for one minute.
Conditions:
This symptom is observed when 3- segment connections are added on CESM-8E1 cards.
Workaround:
None.
|
CSCds88422
|
Symptom:
Cell loss occurs twice after a switchcc is executed on the PXM.
Conditions:
This symptom is observed when CESM is used as the primary. Cell loss occurred twice after switchcc on PXM.The first cell loss occurred when switchcc was executed on the PXM. The second cell loss occurred when the status of PXM, which was reset by switchcc, became the standby.
|
CSCds90056
|
Symptoms:
DAX connections on the FRSMHS1B in alarm are freed after removing one of the two cards used to establish those connections.
Conditions:
Remove one FRSMHS1B and check the connections status on the remaining side.
Workaround:
None.
|
CSCds91139
|
Symptom:
A node becomes unreachable; multiple causes for LMI fail.
Conditions:
This symptom can occur due to bad hardware or a low memory buffer on PXM. It was observed that line errors on the service modules deplete the buffer.
Workaround:
Execute the command addlmiloop on the MGX switch and the command addfdrlp on the BPX switch. Then note and correct errors causing the SAR buffer to deplete. The SAR buffers can be monitored via shellConn using the sarShow command. Look at the used versus free buffer count on the medium buffers.
|
CSCdt01370
|
Symptom:
Using the CWM Connection Manager GUI, user is not able to "Add PVC On Slot" after "PVC Deleted" is executed.
Conditions:
This symptom occurs from the CWM Connection Manager GUI, when PVCs are deleted.
1. Logged onto the node and deleted the ports.
2. Readded the ports at different speeds.
Could not read two PVCs onto the ports.
Workaround:
None.
|
CSCdt18347
|
Symptoms:
After a switchcc, no trunk failure alarm is seen on the BPX switch when a loss of service (LOS) and Minor alarm are indicated on the PXM.
Conditions:
Normal.
Workaround:
No known workaround.
|
CSCdt19164
|
Symptom:
Sometimes, TFTP times out.
Conditions:
Normal conditions.
Workaround:
None.
|
CSCdt19187
|
Symptom:
The commands dspcons or dspchans increment the LocalVpIdNextAvailable by 2.
Conditions:
This symptom occurs when executing the commands dspcons or dspchans.
Workaround:
None. This problem is not service impacting.
|
CSCdt19763
|
Symptom:
When a switchyred is executed, the service modules do not return to their original state.
Conditions:
Normal conditions.
Workaround:
A node rebuild clears the problem, as well a executing a softswitch.
|
CSCdt19805
|
Symptom:
Executed the command switchyred on FRSM cards and PVCs in alarm; however, they showed clear in the display shown when the command dspcds is used.
Conditions:
Workaround:
No known workaround.
|
CSCdt22274
|
Symptom:
A Sonet port is receiving errors.
Conditions:
This symptom occurs when the port is in local loopback. After almcnt is cleared, the port errors continue to increment.
Workaround:
None.
|
CSCdt24657
|
Symptom:
It takes 6-8 minutes for conn resynch to complete on a 2000 i/f card after softswitch.
Conditions:
On a heavily loaded card (2000 sub-interfaces), after a resetcd or softswitch, it takes nearly 6-8 minutes for the connection status to change from Unknown to InSynch. It is not customer impacting as it does not affect the traffic.
Workaround:
Unknown.
|
CSCdt24682
|
Symptom:
The PXM reports empty slots as having RPM or RPM-PR cards in reserved state.
Condition:
This symptom occurred on a shelf with 6 cards in different slots. The configuration is done after executing the clrallcnf command.When resetsys command is executed, empty slots now show as RPM or RPM-PR in reserved state.
Workaround:
Executing the command clrallcnf on the empty slots resolves the problem.
|
CSCdt27067
|
Symptom:
The command tstconseg fails intermittently when executed from the PXM.
Conditions:
Normal conditions.
Workaround:
None.
|
CSCdt28447
|
Symptom:
A Software Error Reset alarm is displayed on multiple nodes.
Conditions:
This symptom occurs while swapping PXMs from shelf to shelf.
Workaround:
None.
|
CSCdt29566
|
Symptom:
The channel went into alarm on slot #21 for an AUSM port.
Conditions:
This symptom occurred after a switchcc was done from slot 7 to slot 8.
Workaround:
None.
|
CSCdt30489
|
Symptom:
For a 3-segment connection, one PXM shows "rmt abit alarm." The remaining segments (on a BPX switch and a far-end PXM) are OK.
Conditions:
This symptom occurred during a switchyred on the BXM card and APS switchovers, with LMI running on the BXM card for that trunk.
Workaround:
Run the commands addlmiloop and dellmiloop on the PXM.
|
CSCdt32153
|
Symptom:
When the command dsplog is executed, the display shows multiple fail messages, but no clear messages.
Conditions:
This symptom is observed when an APS Line Failure occurs.
Workaround:
None.
|
CSCdt33218
|
Symptom:
CWM is receiving too many traps from the MGX switch.
Conditions:
This symptom is observed when an APS line failure occurs and a message is logged on the MGX switch.
Workaround:
None.
|
CSCdt35150
|
Symptom:
The console port connection stopped while taking some captures. It did not come up after executing the commands delserialif 1and addserialif 1.
Conditions:
None.
Workaround:
None.
|
CSCdt42797
|
Symptom:
Software errors are appearing in the log file.
Condition:
The symptom occurs during an AUSM softswitch and FRSM provisioning.
Workaround:
None.
|
CSCdt43225
|
Symptom:
Some channels are stuck in alarm. The command dspchancnt display shows that the channels are receiving OAM AIS, but the command dspsarcnt does not display that OAM AIS is received. The far end is not sending OAM AIS either.
Conditions:
This symptom occurred when the CPE equipment was connected to the port.
Workaround:
Fail the port and recover it by changing the port signalling.
|
CSCdt43296
|
Symptom:
The LMI configuration cannot be changed on a port with the cnfport command. When this is attempted, it returns an error message to the effect that DLCI 0 or DLCI 1023 is configured on that port. However, these DLCIs are not configured on the port.
Conditions:
Conditions leading to this problem are not clear at this point.
Workaround:
Reset the FRSM-2CT3 card.
|
CSCdt43425
|
Symptom:
Ports move in and out of alarm.
Conditions:
This symptom occurs when LMI with AsynchronousMsgs=UPD_UFS is enabled on the port.
Workaround:
Set the value for AsynchronousMsgs to UPD only on the port.
|
CSCdt45112
|
Symptom:
When CIR is modified for a PVC, the egress service rate does not get changed. The egress service rate should track the value of CIR for a channel.
Conditions:
Unknown.
Workaround:
None.
|
CSCdt46258
|
Symptoms:
Customer is seeing discards on ingress for a VBR-rt connection on a FRSM.
Conditions:
The symptom is observed before the CIR data rate is increased.
Workaround:
None.
|
CSCdt49909
|
Symptom:
Sometimes when a PVC is in alarm, it is incorrectly reported as OK on the PXM.
Conditions:
This symptom is observed when a PVC is in alarm.
Workaround:
None.
|
CSCdt50211
|
Symptom:
A PSU Failure is not indicated when the commands dsplog or dspshelfalm are executed.
Conditions:
This symptom occurs when there is a PSU failure.
Workaround:
None.
|
CSCdt51584
|
Symptom:
When changing the MTU setting on an RPM in a MGX with a PXM1 controller, if the MTU value is less than 4000, the RPM may lockup or crash upon a reload.
Conditions:
The problem has only been found with MTU settings of less than 4000 bytes on the Switch interface in the RPM.
Workaround:
Change the MTU setting on the RPM Switch interface to 4000 bytes or higher. If a specific MTU setting is required on a sub-interface it can be set there, the main Switch interface must be 4000 bytes or larger.
|
CSCdt63269
|
Symptom:
The SES trunk cannot recover from a feeder trunk failure even though the IGX shows trunk "Clear - OK."
Conditions:
This symptom is observed when an SES feeder trunk failed and recovered.
Workaround:
Replug the cable.
|
CSCdt67828
|
Symptom:
A channel on an AUSM card was deleted from both the PXM card and the AUSM card; however, the segment still exists on the BPX switch.
Conditions:
The condition under which the symptom is observed is not known, but could be attributed to a resynch.
Workaround:
None.
|
CSCdt70642
|
Symptom:
On a PXM switchover, a PXM line hooked up to an Adtech port receives LOS momentarily.
Conditions:
This symptom occurs when a PXM port is connected to an Adtech port. During a switchcc the Adtech port receives a momentary LOS. A switchcc should be graceful; getting an LOS during a switchcc is not acceptable.
Workaround:
Unknown.
|
CSCdt71179
|
Symptom:
The statistics reserve parameter for MGX switch trunks cannot be modified. When the command is executed, the changed value of the parameter is not accepted.
Condition:
This symptom is observed with a BPX switch running Version 9.3.11 and an MGX switch running Version 1.1.32.
Workaround:
Under Investigation.
|
CSCdt73062
|
Symptom:
The configuration file has no EOF.
Condition:
This symptom occurs after copying from an RPM using "copy run TFTP."
Workaround:
Open the configuration file using VI (or any other editor) and save it again.
|
CSCdt76729
|
Symptom:
The remote loopback operation is not blocked by CiscoView on a AUSM 8T1 line. After a remote loopback is added and removed, there is no traffic continuity on the line.
Conditions:
This symptom is observed when adding and then removing a remote loopback on an AUSM8T1 line. Data continuity is lost.
Workaround:
After adding and removing the remote loopback on the AUSM line via CLI, add and remove a local loop on that line using CiscoView.
Further Problem Description:
None.
|
CSCdt80471
|
Symptom:
The event log reports that an RPM sub-interface has been added instead of deleted. It does not receive a trap when the sub-interface is re-added.
Condition:
This symptom is observed when an RPM sub-interface is deleted using the CLI shutdown command and re-added using no shutdown command.
Workaround:
Unknown.
|
CSCdt80701
|
Symptom:
The primary RPM card goes to mismatch state on a softswitch command.
Condition:
This symptom occurred when RPM added to redundancy 1:N following the command clrsmcnf. At that time, RPM had more than 700 connections and sub-interfaces.
Workaround:
Issue a second resetcd command to the RPM card following the command clrsmcnf.
|
CSCdt82044
|
Symptom:
Channels remain in alarm condition.
Condition:
This symptom was observed after the command resetsys was executed with several thousand connections between slots and the PXM.
Workaround:
Channels are working, only reporting an alarm condition.
|
CSCdt89913
|
Symptom:
The commands dspcds and dspred show different output.
Conditions:
This symptom was observed with RPM 1:N redundancy configured and a softswitch was performed.
Workaround:
None.
|
CSCdt92706
|
Symptom:
The clock does not resynchronize when power is switched on or off during system resets.
Conditions:
Under Investigation.
Workaround:
Deconfigure and reconfigure the clock. For example:
|
CSCdt96482
|
Symptom:
Par i/f on slot (configured for redundancy) goes into Failed state.
Condition:
This symptom is observed when par i/f on the RPM-PR slot that is configured for redundancy goes into Failed state. Traffic is not disrupted.
Workaround:
Execute a switchcc.
|
CSCdu03185
|
Symptom:
The policing function on the VBR.2 (rt/nrt) connections on an AUSM 8T1 permitted more CLP1 cells to enter the network than expected. This could potentially lead to network congestion.
Condition:
Unknown.
Workaround:
Unknown.
|
CSCdu06781
|
Symptom:
Back-to-back forced/manual (W->P followed by P->W) switch was permitted when the latter external user request is initiated from the remote end.
Condition:
Check to see if remote request of equal priority is not in place.
Workaround:
None.
|
CSCdu11046
|
Symptom:
Customer observed the FRSM service module coming up in card init state and reserved state.
Conditions:
This symptom is observed when the active service module is physically reset, and the standby becomes active. The service module in the standby slot comes up in the reserved state. When the command dspcds is executed, the display does indicate that the card is in the reserved state, but when the command dsplog is executed, it does not show the card insertion. Additionally, the FRSM card was removed and reinserted on a different shelf 30 minutes later, and it gets stuck in the init state.
Workarounds:
None determined at the present time.
|
CSCdu12589
|
Symptom:
The value of the varbind 'sonetLineCurrentStatus' is not consistent in the sonet line traps: 50108 (line alarm trap) and 50109 (line no alarm trap).
Conditions:
When the sonet line on PXM goes in and out of alarm.
Workaround:
None.
Further Problem Description:
Till now, CWM was just looking at the value of this varbind 'sonetLineCurrentStatus' to decide whether to put the lines into alarm or not irrespective of the trap no. So because of this inconsistent definitions, sometimes it use to put the connections in alarm even after receiving 50109. Now it has been agreed that they will make this decision based on the trap no rather than the varbind value. Once that is done, the impact of this issue will become less.
|
CSCdu12986
|
Symptom:
Cannot run dsplog CLI command on the node. (on the active card) Can run other command like version and dspcds. Impacts the execution of proactive scripts running on the node to collect logs on a daily basis.
Conditions:
Unknown.
Workaround:
Unknown.
Further Problem Description:
None.
|
CSCdu17346
|
Symptom:
CLI clock source commands does not return accurate information about the external clock.
Condition:
With the external clock configured for E1, 75 ohms impedance and a 1.544 MHz T1 clock coming in, all commands to examine clock status say the external clock is OK and being used. This even though the "E1" clock is running at 1.544 MHz, not 2.048 MHz. T1 clock is supplied from Fireberd4000 T1/FT1 interface, slaved to a HP33120A frequency synthesizer at 1.544000.0 MHz. Looked at the 8K clock and the external clock and they were not synched. This indicates the board rejected the wrong frequency clock and switched back to its internal clock, to generate the 8K clock. Yet all information we can see says the external E1 clock is being used.
Workaround:
None.
|
CSCdu17838
|
Symptom:
Line alarms clear after a card reset if lines are connected back to back on the same card.
Conditions:
Only when 2 lines on the same card are connected back to back.
Workaround:
Up the other side of the lines and delete it.
|
CSCdu19822
|
Symptom:
Frames gets CLP tagged when DE is disabled at the ingress and ingress is pumped at more than CIR.
Conditions:
DE is disabled at the ingress and ingress is pumped at more than CIR.
Workaround:
None.
|
CSCdu25060
|
Symptom:
PXM rejects addconn request.
Conditions:
Could be due to a lot of reasons like PXM busy, db sync has not happened yet.
Workaround:
None.
|
CSCdu28611
|
Symptom:
If you have a NNI connection built from a FRSM 3T3 via the PXM feeder trunk to an IGX, the IGX won't see ABIT alarm even if the FRSM is receiving ABIT alarm on the NNI link to another network.
Conditions:
Unknown.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu29306
|
Symptom:
Card stops passing data. dsportcnt will show LMI signalling timeouts, data incrementing only in the Tx direction. Port will register LMI failure.
Conditions:
Workaround:
Card reset.
Further Problem Description:
None.
|
CSCdu30510
|
Symptom:
Configuration of the stanby RPM-PR card is not restricted.
Conditions:
Add 1:N redundancy between two RPM-PR cards.Try configuring interface and resource partition and connection on the standby card.It adds the interface and the resource partition without giving any error messages.For connection addition, it just adds the segment on the standby card and the synch status of that segment will be shown as unknown.
Workaround:
Configuration of standby card should not be done.
|
CSCdu31770
|
Symptom:
Display connections don't display newly added connections
Condition:
When the new connections are added it doesn't show up on the display. However, tstcon and tstdelay passes.
Workaround:
Unknown at present.
|
CSCdu31905
|
Symptom:
BPX shows Far end Prot Err.
Conditions:
APS 1+1 lines (Bidirectional and revertive) and multiple switchccs.
Workaround:
None.
|
CSCdu31948
|
Symptom:
When a ABR1 XPVC is provisioned via proxy across a hybrid network, from MGX1/AUSM-8T1 to MGX1/AUSM-8T1. The "egress service rate" is not settleable. The resultant default is too rate that limits the egress traffic which prevents the AUSM attaining its PCR setting consequently the PCR/MCR traffic management feature was compromised.
Conditions:
When AUSM-8T1/8E1 is provisioned as an endpoint of an XPVC connection for ABR1.
Workaround:
None.
|
CSCdu34648
|
Symptom:
Error message is inappropriate when trying to softswitch when the secondary is blocked.
Condition:
Have 1:N Red (at least 1:2). do a softswitch once.secondary goes to blocked. Try a second softswitch on the other pair.
Workaround:
None.
|
CSCdu34875
|
Symptom:
Can't delete a port on FRSM-2T3 card, due to inconsistency in connections between SM and PXM.
Condition:
Unknown.
Workaround:
None.
|
CSCdu36591
|
Symptom:
The CWM does not display the correct values of Ingress Percentage Utilization, Egress Percentage Utilization Connection, Percentage Utilization Connection, Remote Percentage Utilization.
Conditions:
These MIB objects are not included in the TFTP config upload file.
Workaround:
No workaround.
Further Problem Description:
None.
Problem Investigation details:
At present CWM is setting %util values(lper_util, rper_util) to -1. CWM will get these values from * TFTP config UpLoad File * SNMP UpLoad file. CWM will parse these values and update Database. For FSRM (4T, 4E, 8T, 8E.), AUSM, VISM, CESM cards we are not getting lper_util & rper_util values in TFTP upload and SNMP upload files. But these values are there on CLI. It is required to have these %util values in TFTP & SNMP config Upload files for all cards, so that CWM can prase these values and populate in DataBAse.
|
CSCdu38671
|
Symptom:
Clock controller running on internal oscillator after upgrade.
Conditions:
After upgrade from 1.1.23 to 1.1.3x.
Workaround:
Reconfigure the clock. For the current scenario, from dspcurclk we find that the Trunk Interface 7.1 is set as Primary, to set the same the command is cnfclksrc 7.1 p.
|
CSCdu39150
|
Symptom:
dspchancnt 2000 gives an error message on FRSM-2CT3.
Conditions:
MGX 8230/8250 FRSM-VHS card has channel number 2000 enabled.
Workaround:
None.
|
CSCdu39929
|
Symptom:
Line module mismatch error not generated on addred.
Condition:
When an addred is issued between two cards that have a different set of backcards (Primary has FE, Secondary has none or Primary had FE, Secondary has 4E etc.), a "line module mismatch" error should be generated on addred but is not being generated.
Workaround:
None.
|
CSCdu40171
|
Symptom:
Sometimes primary clock reference is not selected initially after switchcc.
Conditions:
After a switchcc.
Workaround:
Non.e
|
CSCdu40820
|
Symptom:
Primary and secondary AUSM rebooted simultaneously.
Conditions:
While doing a switchcc.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu40885
|
Symptom:
AUSM channels are showing in alarm.
Conditions:
Upon SRM active card removal.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu41961
|
Symptom:
Data transfer stopped for approx 1min, 25 secs.
Conditions:
Upon SRM active backcard removal.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu45324
|
Symptom:
Traffic test using gn netester inputting 60cps across 500 SIW connections built from BPX network running 9.2.37 and passing through two ATM NNI gateways and terminating on a PXM1 feeder and FRSM card. Shows dicards on FRMS due to CRC and assembly errors. PXM1 running 1.1.32 This mainly occurs on the last 5 ports of the FRSM.
Conditions:
FRSM heavily loaded test environment.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu47467
|
Symptom:
Software Error 21205 seen after node resets.
Conditions:
When node reset is done.
Workaround:
None.
|
CSCdu48231
|
Symptom:
ILMI failure on ports while traffic continuity.
Condition:
MGX:8250 PXM:1.1.34.
Workaround:
Under Investigation.
|
CSCdu49191
|
Symptom:
The command cnfimatst does not correctly report back the status if the link if the pattern 255 is used. It will always report "failed" even when the link is fully operational.
Conditions:
This will happen under all conditions. It is know to exist is version 10.0.21
Workaround:
The test appears to work with data values other that 255. The command cnfimatst can be used to change the data value of the test:
|
CSCdu49464
|
Symptom:
FRSM-2CT3 card in slot 11 stuck in the reserved state.
Conditions:
Occurred right after a resetsys.
Workarounds:
None.
Further Problem Descriptions:
None.
|
CSCdu52789
|
Symptom:
Port alarm present on the AUSM card.
Conditions:
Even after an upgrade there are no port alarms or line alarms.
Workaround:
Wait awhile and the alarm finally clears itself.
Further Problem Description:
None.
|
CSCdu52855
|
Symptom:
chkslotcon is not representing the correct connection information.
Conditions:
This occurred right after a switchcc on the shelf.
Workaround:
None.
Further Problem Description:
None.
|
CSCdu54413
|
Symptom:
LAN IP change is not reflected on NW Browser.
Condition:
When the LAN IP is changed.
Workaround:
None.
|
CSCdu55166
|
Symptom:
IMA lines removed from the IMA grp when slot #28 is covering for slot #30.
Conditions:
When a switchcc is performed.
Workaround:
Just restart the imagrp, and all lines come up as present.
Further Problem Description:
None.
|
CSCdu59142
|
Symptom:
APS Line does not switch to PROT line after removing the back card on which working line resides. Also the working line is shows as OK.
Conditions:
Remove the PXM back card on which working (active) line resides.
Workaround:
Before the back card is removed, the following things need to be done.
1. PXM directly associated (same slot as the back card) with the back card which is to be removed, should be in STANDBY state. (i.e. if back card of slot 7 is to be removed, then PXM in slot 7 should be in STANDBY state). This can be achieved with a switchcc.
2. All the APS line should be switched to the back card which is directly associate with the ACTIVE PXM. (i.e. back card in the same slot as the front card of Active PXM). This can be done using a command switchapsln.
|
CSCdu61217
|
Symptom:
dspcds and dspcd shows card in major alarm because of line failure. dsplns shows everything is fine.
Conditions:
Unknown.
Workaround:
Unknown.
Further Problem Description:
None.
|
CSCdu61609
|
Symptom:
CiscoView shows inconsistent status for lines in 1:1 FRSM-2T3 in MGX8250
Conditions:
1:1 red. between cards.
Workaround:
N/A.
|
CSCdu63420
|
Symptom:
Traceback errors logged on redundant card after shelf is reset (resetsys).
Condition:
IPC INVALID traceback errors logged on RPM after resetsys.
Workaround:
Unknown. Not service-impacting.
|
CSCdu63700
|
Symptom:
MGX1 connected to MGX2 with OC12 1+1APS. When the WLine failed, MGX2 switched to PLine; but MGX1 stayed at WLine although it detected WLine in Alarm.
Conditions:
Connected MGX1 to MGX2 as feeder via OC12 1+1APS, WLine as active line. Removed the WLine Backcard from MGX2 side, WLine in SF, PLine in OK; MGX1 WLine in ALM, PLine in P_D states, with TxK1=C0, RxK1=C1.
Workaround:
Manual Switchaps to PLine before removing the WLine Backcard.
|
CSCdu63979
|
Symptom:
Secondary card in a redundant pair (slots 1, 2) stops responding after resetsys followed by softswitch.
Condition:
After a resetsys on the shelf, and then a softswitch from primary to secondary, the secondary card stops responding and is generating a huge number of "Bad VCD" error messages on the console. This is seen with a constant traffic stream of the order of 75 Mbps on the main switch interface coming via the PXM backcard.
Workaround:
Use "logging rate-limit all 1" in the RPM configuration that would rate limit the console messages OR Switch back to primary card.
|
CSCdu66750
|
Symptom:
CoreCardSwitch trap is not received after switchcc.
Conditions:
When switchcc is executed.
Workaround:
None.
|
CSCdu66767
|
Symptom:
pxmCurClkSourceTrap is not generated properly.
Conditions:
When there is a clock switch.
Workaround:
None.
|
CSCdu67926
|
Symptom:
The traps 50231 and 50230 are received with incorrect varbind ids but the correct information for the varbind listLinksPresentInImaGrp, the varbind listLinksInImaGrp is sent instead.
Conditions:
These traps are always sent with the wrong varbinds, but the information contained does represent the correct varbind i.e even though the varbind listLinksInImaGrp is being sent it actually contains the list of links present in the ima group at present.
Workaround:
None.
|
CSCdu71151
|
Problem Description:
Customers upgrading to 12.2(2)T2 image with RPMs might see some e-BGP sessions not coming up when the CE router is running an older version of IOS (12.0, 12.0.xT). This issue was first encountered with CE running 12.0(7)T image. In such case, the CEs running old IOS versions were not able to create BGP sessions to PEs with the newer image (12.2(2)T2).
The issue is fixed in 12.2(2)T3. Customers who face the problems described with the 12.2(2)T2 image, may upgrade to 12.2(2)T3 image. The IOS 12.2(2)T3 can be downloaded from the following CCO URL:
http://www.cisco.com/kobayashi/sw-center/index.shtml
Symptom
MPLS PE doesn't advertise BGP network to CE router running an older IOS image.
Conditions
A Cisco router that is running Cisco IOS Release 12.2(3.1)T or 12.2(2)T and is configured as a provider edge (PE) router may not support Label Distribution Protocol (LDP). This defect might cause the PE router not to advertise any Border
Gateway Protocol (BGP) routes to a Cisco 2600 series customer edge (CE) router that is running Cisco IOS Release 12.0(18). However, the CE router will advertise routes to the PE router. Entering the neighbor ce-ipaddress don-capability-negotiate command on the PE router does not correct this defect.
Workaround
Upgrade the CE router from Cisco IOS Release 12.0(18) to Cisco IOS Release 12.2(2)T3.
|
CSCdu72197
|
Symptom:
On an MGX 8250 switch, an AUSM card experienced Fail-Over due to a WatchDogTimeOut.
Conditions:
This AUSM card failure was observed only once.
Workaround:
Unknown.
|
CSCdu72202
|
Symptom:
The CESM card in slot 4 switched to slot 14, and slot 14 is not active. No alarms indicate why the switch took occurred.
Conditions:
Conditions are unknown—neither the MGX 8250 switch logs nor CWM logs indicate a reason for the behavior described in the symptom.
Workaround:
None.
Further Problem Description:
After analysis of the node logs and the core file from this node, the reason for the card reset is unknown.
|
CSCdu73201
|
Symptom:
Active line switches to working.
Conditions:
This happens if we switchcc with Protection line as active.
Workaround:
None.
|
CSCdu76037
|
Symptom:
Traffic not running as advertised. The FRSM-2T3E3 card fully loaded (2 ports with 1000 paths on each port) discards traffic at a line rate of 70%.
Condition:
This symptom occurs when either port is running at line rate, but when both have traffic applied to them, they both discard traffic.
Workaround:
None.
Further Problem Description:
Changing frame size from 1600 to 4000 does not fix the problem.
|
CSCdu76247
|
Symptom:
A lock request is not blocked by signal fail condition on the protection line.
Conditions:
This symptom is observed when there is signal fail.
Workaround:
None.
|
CSCdu77273
|
Symptom:
Frames are being dropped when traffic is pumped at full T1 rate. But when the traffic rate is 98% of T1 rate, there were no drops.
Conditions:
Not known.
Workaround:
None.
|
CSCdu77367
|
Symptom:
The command line interface does not show conn/PVCs in alarm, but the Configuration Manager GUI and associated database tables and columns show a failure.
Conditions:
Unknown.
Workaround:
Before using the connections, it is advised to first do a node re-synchronization with the feeder nodes. However, if the connections are bouncing, this manual node resynchronization may not help.
|
CSCdu77558
|
Symptom:
For RPM cards, if the command resetcds is issued multiple times followed by the command switchcc, the shelf is reset.
Condition:
On a fully loaded shelf (with 12 RPMs in multiple redundant groups).
Workaround:
Wait for at least 5-10 minutes after the command resetcds before issuing the command switchcc.
|
CSCdu78911
|
Symptom:
No trap is generated for the clear/lockout command.
Conditions:
This symptom occurs when APS is configured and a clear is done.
Workaround:
None.
|
CSCdu79008
|
Symptom:
T1 alarm counters are missing.
Conditions:
This symptom is observed with the FRSM-8T1E1 card.
Workaround:
None.
|
CSCdu79023
|
Symptom:
Reset of the primary PXM is permitted even if the secondary card is not available.
Conditions
This symptom occurs all the time.
Workaround:
None.
|
CSCdu82341
|
Symptom:
dspred will show blocked for 1:N redundancy. Both primary and secondary vism reboot. Redundancy not available.
Conditions:
AIS generated from AUSM, the alarm will not clear on vism card. The voatm set up is
3810---ais---ausm_vism-----4ess oam f5 between vism and 3810.
Workaround:
None.
|
CSCdu84496
|
Symptom:
The line enabled on the PXM 1 card is not reflected on CWM GUI (network browser).
Condition:
This symptom occurs when a line is enabled on PXM1.
Workaround:
None.
|
CSCdu85852
|
Symptom:
Major Communication failure reported on the PXM.
Conditions:
Unknown.
Workaround:
Execute a switchcc.
|
CSCdu86095
|
Symptom:
The RIF/RDF can't be set on an MGX 8230 switch feeder, AUSM-8T1 card.
Conditions:
This symptom is observed with the following setup: an XPVC across the MGX 8230 switch, AUSM-8T1 card and an MGX 8220 switch, FRSM-8T1 card with ABR-FS service type using user-specified RIF/RDF values.
Workaround:
None. Only system default values are available.
|
CSCdu86525
|
Symptom:
PXM1 resets due to watchdog timeout reset.
Conditions:
Unknown.
Workaround:
None. This problem is a pure software issue and there is no need to replace hardware. PXM will reset due to watchdog timeout and come up to active/standby state.
Further Problem Description:
Software exceptions due to unknown reason. From the current exception logs in the core, it is not sufficient to decide the root cause of the first exception. However, the events after the first exception showed some flaws in design.
|
CSCdv01949
|
Symptom:
A line goes into alarm. The command cnfln accepts the line code as AMI for CESM-8E1 with CCS.
Conditions:
This symptom is observed when the line is configured as AMI.
Workaround:
This happens only if there is end-to-end loopback. If we send valid traffic on one end of the line instead of having a loopback, the alarm goes away.
|
CSCdv02276
|
Symptom:
After a softswitch, the primary PXM card is in a failed state.
Conditions:
This symptom occurs when the PXM is running Release 1.1.34 with two AUSMs in 1:N redundancy and running 10.0.11 version. Then, an upgrade of the AUSM is done to10.0.22 (by doing a softswitch twice).
Problem: When doing the softswitch from the secondary, it's observed that the primary gets stuck in a failed state by running the command dspred.
Workaround:
Reset the secondary card before the first softswitch.
|
CSCdv08231
|
Symptom:
One end of the connection is connected to a failing port and the other end is connected to a non-failing port. Check spmdspportabit <slot>, <port> under shellConn and lmiS bit for both ends are set to 0.
Conditions:
One end of the connection should be connected to a failing port and the other end should be connected to a non-failing port.
Workaround:
None.
Further Problem Description:
None.
|
CSCdv09418
|
Symptom:
CBR XPVC at POP1 AUSM-8E1 experience cell discard while its peer ABR traffic is not ramping down with the congestion.
Condition:
A CBR XPVC and an abrstd XPVC met at a POP1/AUSM-8E1 with traffic congestion.
Workaround:
Do not oversubscribe the interface.
|
CSCdv10310
|
Symptom:
The PXM stops sending traffic on the port.
Conditions:
Unknown.
Workaround:
Switch to the secondary PXM using the command switchcc.
|
CSCdv19084
|
Symptom:
ABR/VBR-nrt does not work correctly on RPM-PR if the CB clock is set at 21Mhz. The PCR or SCR values or not enforced correctly.
Condition:
Traffic shaping test ABR/VBR-nrt with CB at 21Mhz.
Workaround:
Change CBC to 42Mhz but better with another card on the same CB. Or design the shaping values to accommodate this variation.
|
CSCdv19158
|
Symptom:
MGX nodes are failing PXM bootcode burns.
Condition:
Every instance when this symptom occurs, the log has a message to the effect that "DB table is full all 20 entries used."
Workaround:
Patch Memory and upgrade the bootcode.
Further Problem Description:
During the upgrade, in instances when the bootcode upgrade doesn't work, check the log for error messages of database table full and software errors.
|
CSCdv19895
|
Symptom:
RPM-PR and FRSM Interop.
Condition:
During the connection management.
Workaround:
Unknown.
|
CSCdv25041
|
Symptom:
When using virtual access for PPP on a RPM only the first 5 sessions get connected.
Conditions:
Unknown.
Workaround:
None.
|
CSCdv26571
|
Symptoms:
Communication between PXM and all RPM in the shelf is very slow. "sho ipc queue" shows that the queue is full.
Conditions:
cc to RPM using two parallel sessions and run extended ping on each of the sessions.
Workaround:
Run extended pings from telnet sessions instead of cc to the card.
|
CSCdv29288
|
Symptom:
ModConn Test failing
Conditions:
Cannot do modconn via GUI for updating MIR,QIR at the same time.
Workaround:
Change MIR, QIR one at a time instead of at the same time via GUI
|
CSCdv30001
|
Symptom: RPM and PXM shows the inconsistent info on rpm connections.
Condition: A node with 12 RPM-PR connections: 700 connections were 3-segment connection connected to
another node the rest more than 1200 connections were dax connection connected to PXM.
all the connection on PXM card and the second node show in OK status
Workaround: Unknown.
|
CSCdv32805
|
Symptom:
In CWM database, user is unable to find any statistics for all objects on FRSM card.
Conditions:
Customer was using CWM 10.4.01 Patch 3 and was able to get stats for a few days. CWM/SCM was collecting stats files from nodes but in CWM database, there is data for other objects but not for objects on FRSM cards.
Workaround:
This bug gets resolved as a fix to CSCdv30411. The problem was because of incorrect data handling which is fixed in CSCdv30411.
|
CSCdv37568
|
Symptom:
With Frame forwarding port type, not able to add 248th connection.
Conditions:
Port no as 248 and adding connection to this port is blocked.
Workaround:
Unknown at present.
|
CSCdv39292
|
Symptom:
Some items could not be set up from statsmgr.
Conditions:
CWM:9.2.09(Patch 10) Popeye:1.1.25 BPX:9.2.38.
Workaround:
None.
|
CSCdv39324
|
Symptom:
When FRSM 8e1-t1 with 10.0.20 have been provisioned or added without specifying a channel service type the default is blank. IF the card is upgraded to 10.0.22 the channels are automatically put into CBR queue and if new channels are provisioned the default service type is CBR. This causes problems with enabling foresight on these connections.
Conditions:
If connections have been added on the FRSM with a default chanservtype. And the card is then upgraded. This default is changed to CBR rather than null. This causes problems with enabling foresight as it believes its a none ABR service. Code affected is when upgrading MGX8250 FRSM code from 10.0.20 to 10.0.22
Workaround:
None, unless chanservtype has already been selected other than default to ABR servicetype.
|
CSCdv39397
|
Symptom:
You cannot change the -cas option of a connection on a CESM when you use the xcnfchan & xcnfcon commands.
Conditions:
Workaround:
The only workaround is to delete & re-add the connection with the new parameter.
|
CSCdv48190
|
Symptom:
Connection doesn't go into failed state on PXM.
Condition:
Down the subinterface.
Workaround:
None.
|
CSCdv48287
|
Symptom:
Enable password defaults to cisco after RPM reload.
Conditions:
If the RPM configuration is not saved on the auto_config_slot## file on the PXM hard drive, it will get saved only on the RPM NVRAM. The problem is seen after a reload of the RPM.
Workaround:
Have the statement "boot config c:auto_config_slot##" in the running configuration and save it. ##' refers to the slot numbers 01, 02, 03,...,09, 10, 11,...16.
|
Compatibility Notes
MGX 8230/8250/8850 Software Interoperability with Other Products
Platform Software:
|
PXM 1.1.40
|
Compatible BPX Switch Software:
|
Switch Software 9.2.30 release or higher for BPX and BXM firmware (Refer to the Switch Software Release Notes)
|
Compatible MGX Release 2 Switch Software
|
MGX Rel. 2 Software 2.x.x
|
Network Management Software:
|
10.5
|
|
Note CWM 10.4.10 will support 1.1.40 but only when deployed with 1.1.34 features. CWM 10.4.10 also supports bug fixes in 1.1.40. CWM 10.5 supports bug fixes and new features in Release 1.1.40.
Boot File Names and Sizes
The following table displays the boot file names and sizes for System Release 1.1.40.
File Name
|
File Size (in bytes)
|
ausm_8t1e1_AU8_BT_1.0.02.fw
|
377836
|
cesm_8t1e1_CE8_BT_1.0.02.fw
|
264592
|
cesm_t3e3_CE8_BT_1.0.02.fw
|
303936
|
frsm_8t1e1_FR8_BT_1.0.02.fw
|
297988
|
frsm_hs1_HS1_BT_1.0.02.fw
|
293052
|
frsm_vhs_VHS_BT_1.0.02.fw
|
467156
|
pxm_bkup_1.1.40.fw
|
1323296
|
rpm-boot-mz.122-4.T
|
2621760
|
vism_8t1e1_VI8_BT_2.0.03.fw
|
245232
|
VISM and RPM Firmware Compatibility
The following firmware compatibility matrix is for System Release 1.1.40.
PCB Descriptions
|
CW2000 Names
|
Latest F/W
|
Min F/W
|
File Name
|
File Size
(in bytes)
|
MGX-VISM-8T1 and
MGX-VISM-8E1
|
VISM-8T1
|
2.1.1
|
2.1(0)
|
vism_8t1e1_002.001.001.000.fw
|
2284856
|
MGX-RPM-128M/B and MGX-RPM-PR
|
RPM
|
12.2(4)T
|
12.2.2T2
|
rpm-js-mz.122-3.6.T (IOS)
|
8582116
|
MGX 8250/8850 Firmware Compatibility
The following firmware compatibility matrix is for System Release 1.1.40.
PCB Description
|
CW2000 Name
|
Latest F/W
|
File Name
|
File Size
(in bytes)
|
PXM1
|
PXM-1
|
1.1.40
|
pxm_1.1.40.fw
|
2290712
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.1.40
|
pxm_1.1.40.fw
|
2290712
|
PXM1-4-155
|
PXM1-4OC3
|
1.1.40
|
pxm_1.1.40.fw
|
2290712
|
PXM1-1-622
|
PXM1-OC12
|
1.1.40
|
pxm_1.1.40.fw
|
2290712
|
MGX-SRM-3T3/B
|
SRM-3T3
|
n/a
|
n/a
|
n/a
|
AX-CESM-8E1
|
CESM-8E1
|
10.0.22
|
cesm_8t1e1_10.0.22.fw
|
678592
|
AX-CESM-8T1
|
CESM-8T1
|
10.0.22
|
cesm_8t1e1_10.0.22.fw
|
678592
|
MGX-AUSM-8E1/B
|
AUSMB-8E1
|
10.0.23
|
ausm_8t1e1_10.0.23.fw
|
1194816
|
MGX-AUSM-8T1/B
|
AUSMB-8T1
|
10.0.23
|
ausm_8t1e1_10.0.23.fw
|
1194816
|
MGX-CESM-T3
|
CESM-T3
|
10.0.22
|
cesm_t3e3_10.0.22.fw
|
606768
|
MGX-CESM-E3
|
CESM-E3
|
10.0.22
|
cesm_t3e3_10.0.22.fw
|
606768
|
AX-FRSM-8E1/E1-C
|
FRSM-8E1
|
10.0.23
|
frsm_8t1e1_10.0.23.fw
|
831792
|
AX-FRSM-8T1/T1-C
|
FRSM-8T1
|
10.0.23
|
frsm_8t1e1_10.0.23.fw
|
831792
|
MGX-FRSM-HS2
|
FRSM-HS2
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2CT3
|
FRSM-2CT3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2T3E3
|
FRSM-2T3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2T3E3
|
FRSM-2E3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-HS1/B
|
FRSM-HS1/B
|
10.0.23
|
frsm_hs1_10.0.23.fw
|
761040
|
MGX 8230 Firmware Compatibility
The following firmware compatibility matrix is for System Release 1.1.40.
PCB Description
|
CW2000 Name
|
Latest F/W
|
File Name
|
File Size
(in bytes)
|
PXM1
|
PXM-1
|
1.1.40
|
pxm_sc_1.1.40.fw
|
2290292
|
PXM1-2-T3E3
|
PXM1-2T3E3
|
1.1.40
|
pxm_sc_1.1.40.fw
|
2290292
|
PXM1-4-155
|
PXM1-4OC3
|
1.1.40
|
pxm_sc_1.1.40.fw
|
2290292
|
PXM1-1-622
|
PXM1-OC12
|
1.1.40
|
pxm_sc_1.1.40.fw
|
2290292
|
MGX-SRM-3T3/B
|
SRM-3T3
|
n/a
|
n/a
|
n/a
|
MGX-SRM-3T3/C
|
SRM-3T3
|
n/a
|
n/a
|
n/a
|
AX-CESM-8E1
|
CESM-8E1
|
10.0.22
|
cesm_8t1e1_10.0.22.fw
|
678592
|
AX-CESM-8T1
|
CESM-8T1
|
10.0.22
|
cesm_8t1e1_10.0.22.fw
|
678592
|
MGX-AUSM-8E1/B
|
AUSMB-8E1
|
10.0.23
|
ausm_8t1e1_10.0.23.fw
|
1194816
|
MGX-AUSM-8T1/B
|
AUSMB-8T1
|
10.0.23
|
ausm_8t1e1_10.0.23.fw
|
1194816
|
MGX-CESM-T3
|
CESM-T3
|
10.0.22
|
cesm_t3e3_10.0.22.fw
|
606768
|
MGX-CESM-E3
|
CESM-E3
|
10.0.22
|
cesm_t3e3_10.0.22.fw
|
606768
|
AX-FRSM-8E1/E1-C
|
FRSM-8E1
|
10.0.23
|
frsm_8t1e1_10.0.23.fw
|
831792
|
AX-FRSM-8T1/T1-C
|
FRSM-8T1
|
10.0.23
|
frsm_8t1e1_10.0.23.fw
|
831792
|
MGX-FRSM-HS2
|
FRSM-HS2
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2CT3
|
FRSM-2CT3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2T3E3
|
FRSM-2T3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-2T3E3
|
FRSM-2E3
|
10.0.23
|
frsm_vhs_10.0.23.fw
|
939540
|
MGX-FRSM-HS1/B
|
FRSM-HS1/B
|
10.0.23
|
frsm_hs1_10.0.23.fw
|
761828
|
Comparison Matrix
This multiservice gateway comparison matrix is designed to identify capabilities supported in the MGX 8220, 8230, 8250, and 8850 platforms.
Feature
|
MGX 8220
|
MGX 8230
|
MGX 8250
|
MGX 8850, PXM1
|
Slot Capacity
|
|
|
|
|
Total Number of Slots
|
16 single-height
|
14 single-height/
7 double-height, or combination
|
32 single-height/
16 double-height, or combination
|
32 single-height/
16 double-height, or combination
|
Slots for Processor cards (PXM1s)
|
2 single-height (plus 2 slots reserved for BNM)
|
2 double-height
|
2 double-height
|
2 double-height
|
Slots for Service Modules (SMs)
|
10 single-height
|
8 single-height/
4 double-height or combination
|
24 single-height/ 12 double-height, or combination
|
24 single-height/
12 double-height combination
|
Slots for SRM Cards
(Service Resource Modules)
|
2 single-height
|
2 single-height
|
4 single-height
|
4 single-height
|
| |
Physical Attributes
|
8220
|
8230
|
8250
|
8850
|
Height (in inches)
|
8.75
|
12.25
|
26.25 to 29.75
|
26.25 to 29.75
|
Width (in inches)
|
17.45
|
17.72
|
17.72
|
17.72
|
Depth
|
20.0
|
23.5
|
21.5
|
21.5
|
| |
Services
|
8220
|
8230
|
8250
|
8850
|
MPLS (IP +ATM)
|
No
|
Yes
|
Yes
|
Yes
|
Voice
|
No
|
Yes
|
Yes
|
Yes
|
ATM
|
Yes
|
Yes
|
Yes
|
Yes
|
Frame Relay
|
Yes
|
Yes
|
Yes
|
Yes
|
Frame Relay-to-ATM network interworking
|
Yes
|
Yes
|
Yes
|
Yes
|
Frame Relay-to-ATM service interworking
|
Yes
|
Yes
|
Yes
|
Yes
|
Circuit Emulation
|
Yes
|
Yes
|
Yes
|
Yes
|
| |
Local Switching
|
8220
|
8230
|
8250
|
8850
|
| |
No
|
Yes
|
Yes
|
Yes
|
| |
Feeder
|
8220
|
8230
|
8250
|
8850
|
Feeder to BPX 8600
|
Yes
|
Yes
|
Yes
|
Yes
|
Feeder to MGX 8850 PXM-45
|
No
|
Yes
|
Yes
|
Yes
|
Feeder to IGX
|
No
|
Yes
|
No
|
No
|
| |
Automatic Protection Switching
(APS 1+1)
|
8220
|
8230
|
8250
|
8850
|
| |
No
|
Yes
|
Yes
|
Yes
|
| |
Switching Capacity
|
8220
|
8230
|
8250
|
8850
|
| |
320 Mbps
|
1.2 Gbps
|
1.2 Gbps
|
1.2 Gbps
|
| |
Trunk/Port Interfaces
|
8220
|
8230
|
8250
|
8850
|
T3/E3
|
1
|
2
(one feeder trunk)
|
2
(one feeder trunk)
|
2
|
OC-3c/STM-1
|
1
|
4
(one feeder trunk)
|
4
(one feeder trunk)
|
4
|
OC-12c/STM-4
|
No
|
1
|
1
|
1
|
OC-48c/STM-16
|
No
|
No
|
No
|
No
|
n x T1/E1
|
Yes
|
Yes
|
Yes
|
Yes
|
| |
Service Module Front Cards
|
8220
|
8230
|
8250
|
8850
|
AX-FRSM-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8T1-C
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-8E1-C
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-HS2
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-FRSM-HS1
|
Yes
|
No
|
No
|
No
|
MGX-FRSM-HS1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-2T3/E3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-FRSM-2CT3
|
No
|
Yes
|
Yes
|
Yes
|
AX-AUSM-8T1
|
Yes
|
No
|
No
|
No
|
MGX-AUSM-8T1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-AUSM-8E1
|
Yes
|
No
|
No
|
No
|
MGX-AUSM-8E1/B
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-IMATM-8T1/B
|
Yes
|
No
|
No
|
No
|
AX-IMATM-8E1/B
|
Yes
|
No
|
No
|
No
|
AX-CESM-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-CESM-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-CESM-T3E3
|
No
|
Yes
|
Yes
|
Yes
|
AX-SRM-T1E1/B
|
Yes
|
No
|
No
|
No
|
AX-SRM-3T3
|
Yes
|
No
|
No
|
No
|
MGX-SRM-3T3/B
|
Yes
|
No
|
Yes
|
Yes
|
MGX-SRM-3T3/C
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-VISM-8T1
|
No
|
Yes
|
Yes
|
Yes
|
MGX-VISM-8E1
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RPM-128/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RPM-PR
|
No
|
Yes
|
Yes
|
Yes
|
PXM1
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-2T3E3
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-4-155
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-1-622
|
No
|
Yes
|
Yes
|
Yes
|
| |
Service Module Back Cards
|
8220
|
8230
|
8250
|
8850
|
AX-SMB-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-RJ48-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-RJ48-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-SMB-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-RJ48-8E1
|
Yes
|
Yes
|
Yes
|
Yes
|
AX-R-RJ48-8T1
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-SCSI2-2HSSI/B
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-12IN1-4S
|
Yes
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2T3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2E3
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-2E3A
|
No
|
Yes
|
Yes
|
Yes
|
MGX-BNC-3T3-M
|
No
|
Yes
|
Yes
|
Yes
|
PXM1-UI
|
No
|
Yes
|
Yes
|
Yes
|
MGX-MMF-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFIR-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFLR-4-155/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFIR-1-622/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-SMFLR-1-622/B
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RJ45-FE
|
No
|
Yes
|
Yes
|
Yes
|
MGX-MMF-FE
|
No
|
Yes
|
Yes
|
Yes
|
MGX-RJ45-4E
|
No
|
Yes
|
Yes
|
Yes
|
RPM Compatibility Matrix
MGX SW version
|
1.1.24
|
1.1.3x
|
1.1.32
|
1.1.34
|
1.1.40
|
"Bundled" IOS SW version
|
12.1(3)T
|
12.1(3)T
|
12.1(5.3)T_XT
|
12.2(2)T2
|
12.2(4)T
|
IOS Version for RPM-PR
|
12.1(5.3)T_XT
|
12.1(5.3)T_XT
|
12.1(5.3)T_XT
|
12.2(2)T2
|
12.2(4)T
|
IOS for RPM/B in MGX 8230
|
12.1(5.3)T_XT
|
12.1(5.3)T_XT
|
12.1(5.3)T_XT
|
12.2(2)T2
|
12.2(4)T
|
CWM
|
9.2.08
|
10.3
|
10.4.01
|
10.4.01 Patch 1
|
10.5
|
Note *Support for RPM-PR is FCS with Release 1.1.32.
|
|
|
Special Installation and Upgrade Requirements
Existing customers should use the upgrade procedure Service Module Boot/Firmware Download Procedure to upgrade. A graceful upgrade from any release previous to the current release is supported. For new customers, the image will be pre-installed as 1.1.40 and should use the PXM installation procedure to upgrade to future maintenance releases.
A graceful upgrade from any release previous to the current release is supported, but a graceful downgrade is not supported. Abort or fallback to the previous release is supported at any stage during the upgrade. For abort instructions, refer to Instructions to Abort PXM Upgrade.
Special Instructions for Networks Containing FRSM 2 CT3
Under certain conditions with the FRSM 2 CT3, a script must be ran in order to properly upgrade from previous releases to Release 1.1.34. The script resolves the FREEDM buffer issue described in anomaly CSCds66176; namely, that ports are lost sometimes after softswitch or resetcd. The algorithm to allocate FREEDM buffers was changed in order to fix this anomaly. Because of the algorithm change, ports might be lost when upgrading from a release (FRSM version < 10.0.22) with the older algorithm. The script identifies cards which will lose ports if the card is upgraded to Release 1.1.32 or greater.
A README file contained in the Release 1.1.40 bundle TAR file located on CCO describes how to run the script and shows an example of the script output.
Executing the Script
Execute the script:
•On all shelves with FRSM-2CT3 prior to an upgrade from any version to Release 1.1.32 (FRSM VHS version 10.0.22) or higher.
•For upgrades from releases prior to Release 1.1.32 for the MGX 8250, MGX 8230, or MGX 8850. To fix this issue, an algorithm change was made in Release 1.1.32 (10.0.22 version of FRSM 2 CT3).
Script Functionality
The script applies the new algorithm for buffer allocation to existing ports to determine if all the ports will remain intact during the upgrade process. After application of the new algorithm, a log file is created for each FREEDM chip on all the FRSM 2CT3 cards on the shelf. The log file contains confirmation that the buffer allocations are OK or NOTOK. If the log file contains NOTOK for a card, then upgrading the card to the new release will cause the card to lose ports. Therefore, ports must be moved to another card before upgrading this card.
Single PXM Installation Procedure
Step 1 Save your current configuration.
Step 2 Get the filename by listing the CNF directory:
-------- ------ ------ --------
512 APR-08-1999 08:16:18 . <DIR>
512 APR-08-1999 08:16:18 .. <DIR>
512 APR-09-1999 05:26:42 TMP <DIR>
45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip
45433 APR-09-1999 05:28:42 NODENAME.zip
total space : 819200 K bytes
free space : 787787 K bytes
Step 3 On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp shelf.ip.address
tftp> get CNF/NODENAME_0409990528.zip
Received 45433 bytes in 0.4 seconds
Step 4 Download the release to upgrade PXM Backup boot image to the PXM . For example:
unix-prompt> tftp <node_name or IP address>
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
Step 5 Download the release to upgrade PXM runtime image to the PXM. For example:
tftp> <node_name or IP address>
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
Step 6 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Use the TFTP put command:
tftp <node_name or IP address>
Step 7 On the PXM type the following when the transfer is done:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 8 Execute install bt <new_rel>.
Step 9 Execute install <new_rel>. At the end of the display, enter yes.
redundancy is not available
the other card is not available
you are not in redundant mode,
do you want to try an ungraceful upgrade
Installation Procedure for Redundant PXMs
This section applies to upgrades from 1.1.23 and all later releases.
Caution Do not remove old firmware until the upgrade is done.
Note First you must ensure that the shelf IP address and the PXM IP address are set. The PXM must have its own unique IP address and there must be a another unique IP address for the shelf.
To set the PXM address, use the bootChange command:
'.' = clear field; '-' = go to previous field; ^D = quit
inet on ethernet (e) : 172.29.37.220:ffffff00
gateway inet (g) : 172.29.37.1
ftp password (pw) (blank = use rsh):
Set the "inet on ethernet (e) :" field with the first part of the entry (before the :) as the IP address, and the second part as the subnet mask.
Set the "gateway inet (g) :" with the gateway address.
This must be done on both PXMs. This can also be done in backup boot from the VxWorks prompt "->".
To set the shelf IP address:
node-prompt> cnfifip 26 shelf.ip.address subnet.mask broadcast.address
•The second argument is the shelf IP address.
•The third argument is the subnet mask.
•The fourth argument is the broadcast address.
Step 1 Save your current configuration.
Step 2 Get the filename by listing the CNF directory:
-------- ------ ------ --------
512 APR-08-1999 08:16:18 . <DIR>
512 APR-08-1999 08:16:18 .. <DIR>
512 APR-09-1999 05:26:42 TMP <DIR>
45433 APR-09-1999 05:28:42 NODENAME_0409990528.zip
45433 APR-09-1999 05:28:42 NODENAME.zip
total space : 819200 K bytes
free space : 787787 K bytes
Step 3 On the workstation, upload the saved configuration to the workstation:
unix-prompt> tftp shelf.ip.address
tftp> get CNF/NODENAME_0409990528.zip
Received 45433 bytes in 0.4 seconds
Step 4 Verify that one PXM is Active and the other Standby.
Step 5 From the workstation, download the PXM Backup boot image.
unix-prompt> tftp pxm.ip.address
tftp> put pxm_bkup_<new_rel>.fw POPEYE@PXM.BT
Step 6 From the workstation, download the PXM FW.
unix-prompt> tftp pxm.ip.address
tftp> put pxm_<new_rel>.fw POPEYE@PXM.FW
Sent 1982672 bytes in 18.3 seconds
Make sure that the transfer is successful by looking at the message displayed on the PXM console after the transfer:
Calculated checksum = 0xd9779bc6 stored checksum = 0xd9779bc6
Note Bytes sent, program length, and receive time vary per release. Also, see the Compatibility Matrixes for current file sizes and file names.
Step 7 Download the ComMat.dat file to the C:/FW directory of the Active PXM. Use the TFTP put command:
unix-prompt> tftp <node_name or IP address>
Step 8 After the transfer is done, type the following on the PXM:
PXM.a> copy ComMat.dat /FW/ComMat.dat
Step 9 Execute the command install bt <new_rel>.
Step 10 Execute the command install <new_rel>.
Step 11 After the Standby card is reset and successfully enters the hold state, on the Active PXM, execute the command newrev <new_rel>.
The Active card will be reset and go to hold state.
After the newrev, use the command dspcd to show the firmware revision onthe new, active PXM.
During the graceful upgrade procedure, if after the newrev command the non-active card enters the "MISMATCH" state, do the normal commit command. You will get a warning message:
other card not found,
do you still want to complete the commit operation
Answer yes and then reset the non-active card.
If you get the MISMATCH during the upgrade process, after you finish, you will still have the MISMATCH. To correct the mismatch, you must check your back cards; they must be identical.
Step 12 After the Active PXM is reset and successfully enters the hold state, on the new Active PXM, execute commit <new_rel>.
Instructions to Abort PXM Upgrade
A graceful downgrade is not supported. However, abort or fallback to the previous release is supported at any stage during the upgrade. The following procedure should be used to abort to a previous release.
Upgrade from Release 1.1.3x
If the upgrade needs to be aborted for any reason during the upgrade process, follow these instructions.
Step 1 Execute abort <release no>
PXM.a> abort <release no>
Upgrade from Release 1.1.2x
If the upgrade needs to be aborted for any reason during the upgrade process, follow these instructions.
Step 1 If the abort is required before the newrev command is entered, skip to Step 2.
a. Execute the following commands if the upgrade process is past the newrev stage.
b. On the Active PXM, execute shellConn
c. Execute smCardMibVer = 21
d. Execute saveDBToArchive <PXM SlotNo>, 0
e. Execute uploadBram <PXM SlotNo>, <PXM SlotNo>
The <PXM SlotNo> should be 7 for the MGX8850 Switch and for the MGX 8250 Switch (even if the Active PXM is in slot 8, use slot 7).
The <PXM SlotNo> should be 1 for the MGX8230 Switch (even if the Active PXM is in slot 2 use slot 1).
The example that follows is for the MGX8850.
f. If RPM cards also are on this node, perform the following for each RPM card:
Inside shellConn on Active PXM, execute:
saveDBToArchive <RPM_slot#>, 1
d &arcMem+<RPM_slot#>*4
Copy down the 4 byte address that is displayed after executing the d&arcMem+<RPM_slot#>*4
command and enter it in the following command.
rmSlotArchFileSave <RPM_slot#>, <4 byte address>
For example, for an RPM in slot 9, the result is:
8051cb90: 8702 bad8 0000 0000 0000 0000 * ..........*
8051cba0: 0000 0000 0000 0000 0000 0000 0000 0000
-> rmSlotArchFileSave 9,0x8702bad8
Step 2 Execute abort <release no>.
PXM.a> abort <release no>
Service Module Boot/Firmware Download Procedure
The following procedure describes how to download the boot and the service module firmware for slot-independent and slot-dependent images.
Step 1 Download the boot image for the service module onto the PXM hard disk.
unix-prompt> tftp <node_name or IP address>
tftp> put <backup boot> POPEYE@SM_1_0.BT
Step 2 Download the boot image onto the respective service module using the command:
install bt sm <slot #> <version>
Repeat for each of the service modules on the node.
Step 3 Now, choose instruction for slot-independent or slot-dependent firmware. See below.
For slot-independent image:
Download the selected revision of service module firmware onto the PXM hard disk.
unix-prompt>tftp <node_name or IP address>
tftp> put <FW file> POPEYE@SM_1_0.FW
You cannot do two puts in the same TFTP session.
Repeat for each service module type and for each slot-independent firmware.
For slot-dependent image:
For a slot-specific image (in this example the service module is tied to slot 1),
unix-prompt> tftp <ip address of the MGX 8850 shelf>
tftp> put <sm FW file name> POPEYE@SM_1_1.fw
Note If the checksums are not the same when you remove the service module then the service module will not boot when it is plugged in and the service module will have to be RMA'ed.
Note Please consult your Support Representative before performing any software upgrade.
Service Module Firmware Download Procedure
For slot independent image:
Step 1 Download the selected revision of service module firmware on the PXM hard disk.
unix-prompt> tftp <node_name or IP address>
tftp> put <backup boot> POPEYE@SM_1_0.BT
tftp <node_name or IP address>
tftp> put <FW file> POPEYE@SM_1_0.FW
You cannot do two puts in the same TFTP session.
Repeat for each service module type and for each slot-independent firmware.
For slot dependent image:
Step 1 For a slot-specific image (in this example the service module is tied to slot 1),
unix-prompt> tftp <ip address of the MGX 8850 shelf>
tftp> put <sm FW file name> POPEYE@SM_1_1.fw
Note If the checksums are not the same when you remove the service module then the service module will not boot when it is plugged in and the service module will have to be RMA'ed.
Note Please consult your Support Representative before performing any software upgrade.
Manual Configuration of Chassis Identification
MGX as a Standalone Node
If any MGX box is to be used as a standalone node for testing, the intended model number from the PXM firmware configuration should be matched MANUALLY by running the "runConfigurator" utility.
Example: ipfrnj40 was running 1.1.24 as a 8850 node:
If the node's model number is set to 8250 by default after a 1.1.32 firmware upgrade, but the ipfrnj40 is still configured as a 8850 standalone node on the CWM side, then CWM will reject the node on discovery, and the node will remain undiscovered.
Solution: On every standalone node, manually verify that the runConfigurator settings match the switch.
Chassis Identification During a Firmware Upgrade
On the CWM side, the emd.conf must be modified to a one second wait time so it can help clean up the emc process's internal cache and CWM database (regarding any slot that has sent the functional removal trap). This ensures that CWM will sync up whatever is current with the switch after the upgrade.
Before a firmware upgrade is begun, complete the following steps:
Step 1 Change the following line in emd.conf:
"Hold for 300 secs before deleting the card after a func module trap is received".
to
"Hold for 1 secs before deleting the card after a func module trap is received".
Note This prevents race conditions in updating the database table from the firmware version upgrade.
Step 2 After emd.conf is changed, send HUP signals to all EMC processes.
Step 3 After the firmware upgrade is complete, reset the hold time back to 300 seconds.
Step 4 Send HUP signals to EMC processes to confirm the changeback.
Interoperability of Service Module on MGX 8220 and MGX 8250 Switches
Caution Graceful downgrade for the Service Module is not supported.
If you are moving service modules from an existing MGX 8220 platform to the MGX 8850, the MGX 8220 service modules (AX-FRSM-8T1/E1, and AX-CESM-8T1/E1) need to have the boot flash upgraded to MGX 8220 Release 5.0.00 common boot code (1.0.01 version) before they can be plugged in the MGX 8850 chassis. All MGX 8220 service module versions that use Release 4.0.xx of boot code and earlier are not supported in the MGX 8850.
SPARE DEPOT: Customers receiving a replacement service module via the TAC (through the RMA process) will have the common boot code image that works for MGX 8220 Release 4.x, 5,x, and MGX 8850 installed on legacy service modules. (Spare service modules received directly from manufacturing through the normal ordering process will have the correct boot code image already loaded.)
If loading of the correct common boot code image is required then it will have to be performed on an MGX 8220 chassis, and cannot be performed on an MGX 8850 chassis. Please refer to the procedure below, which is also outlined in the Cisco MGX 8850 Installation and Configuration Guide on the documentation CD.
Use ftp to port the Axis 5 common boot image for the service module to a workstation.
Plug in the card into the MGX 8220 shelf.
Download the proper MGX 8220 shelf Release 5.0 boot image using the following commands from the workstation:
unix-prompt> tftp <ip address of the MGX 8220 shelf >
1tftp> put <boot filename> AXIS_SM_1_<slot#>.BOOTkj
Now you must insure that TFTP downloaded the appropriate boot code by verifying the flash checksums.
Login to the shelf.
unix-prompt> tftp cc <slot #>
Verify that the two checksums are the same.
If NOT, repeat the process until they are the same. If they are the same, then you can safely remove the card. At this point the service module can be used in the MGX 8850 shelf.
Service Module Upgrades
The following steps need to be followed for service module upgrades. Service module firmware images cannot be downloaded as specific versions, because only 1 slot independent image can be present on the disk. Hence, the user cannot revert back during the installation process.
Step 1 Download the service module firmware to the shelf. Refer to Service Module Firmware Download Procedure.
Note To upgrade all the service modules, load all the firmware files and boot files to the node. Then execute the command resetsys. Make sure that the configuration is saved.
Step 2 For non-graceful upgrades, just reset the card and the service module will come up with the new image.
Step 3 For graceful upgrades, a secondary card should be backing up the service module that needs to be upgraded. Configure the redundancy and issue the command:
install sm <slot> <version>
where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
Note The concept of version is redundant here, since there is only one service module image on the disk. However we do check that the version given by the user matches the image on the disk to make it consistent with PXM upgrade/downgrade.
newrev sm <slot> <version>
where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
commit sm <slot> <version>
where <slot> is the service module that is being upgraded
and <version> is the service module image on the disk.
Note There is no abort command for service module upgrade.
Route Processor Module (RPM) Addendum
This section describes the installation requirements and guidelines for RPM modules installed with this release.
About the Cisco IOS 12.2(4)T Release
The Cisco IOS 12.2(4)T or higher is used with MGX Release 1.1.40. This IOS release supports new RPM features and continues to support existing features on the RPM/PR and RPM/B cards.
Note that MPLS inter AS, MPLS TE, and POS port-adapter are not supported features on RPM for this release.
About the Cisco IOS 12.2(2)T2 Release
The Cisco IOS 12.2(2)T2 is used with MGX Release 1.1.34. This IOS release does not support new RPM features, but has been tested with 1.1.34 and continues to support existing features on the RPM/PR and RPM/B cards.
About the Cisco IOS 12.1(5.3)T_XT Release
The Cisco IOS 12.1(5.3)T_XT or higher is used with MGX Release 1.1.32 and provides support for:
•RPM-PR in any MGX chassis
(Note: RPM-PR is FCS with Release 1.1.32; and General Availability with Release 1.1.34.)
•RPM/Bs in an MGX 8230 chassis
•Multiple RPM card types
•IOS 12.1(5.3)T_XT offers no other software features for the RPM.
Note To locate IOS-related anomalies or problems fixed, please refer to IOS release notes.
Problems Fixed with IOS 12.1(5.3)T_XT
Please refer to the IOS 12.1 Release Notes at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121relnt/index.htm
Bypass Feature for RPM in 12.2(4)T IOS Release
Note Information about the bypass feature and the IOS commands used to support it was not available at the time of the printing of the RPM documents; therefore, it is included in the these release notes.
RPM cards have a maximum storage of 128 KB for the NVRAM. This size limitation creates a problem for customers with large configurations, who find it impossible to store the complete configuration in the NVRAM, even with compression enabled.
In order to support storage of large configuration files, a new bypass feature is now available in the 12.2(4)T IOS Release. With the bypass feature enabled, the enhanced "write memory" is used to bypass the NVRAM and save the configuration on:
•For MGX Release 2, the file auto_config_slot## located in E:/RPM.
•For MGX Release 1, the file auto_config_slot## located in C:/RPM.
Where"##" represents the zero-padded slot number in which the RPM card is seated in the MGX chassis.
To enable the bypass feature, issue the command rpmnvbypass from the IOS run time image—not in the IOS boot image.
To disable the bypass feature, issue the command no rpmnvbypass.
To verify that the bypass feature is either enabled or disabled, issue the show running-configuration command. If the bypass feature is enabled, rpmnvbypass is seen on the display. If it is not seen, the feature is not enabled.
Note Since the bypass feature bypasses NVRAM, it is not necessary to compress the configuration file using the command service compress-config.
Table 2contains cautions important to the successful usage of the bypass feature.
Table 3 Boot Cautions
Caution
|
Why is This Important?
|
When using the bypass feature, you can only load the run time IOS image from the PXM hard-drive or from the boot flash.
|
In the case of an RPM module, the IOS image can be loaded in 3 ways:
3. From the PXM hard-drive.
4. From the boot flash.
5. From the network (e.g. via TFTP) from the RPM backcard (Ethernet or Fast Ethernet).
When the bypass feature is enabled, the "boot config" statement:
c:auto_config_slot## is automatically generated. The NVRAM configuration is cleared upon a "write memory". In order to load from the network, the RPM has to have an IP address for its backcard. This information is part of the NVRAM configuration, which was just cleared by enabling the bypass feature. Hence, it is not possible to load the IOS image from the network upon a reload of the RPM after the "rpmnvbypass" and "write memory" have been executed.
|
Do not execute the command no boot config because doing so may prevent the bypass feature from working properly.
|
When the bypass feature is enabled, the "boot config" statement:
is automatically generated, and the NVRAM configuration is cleared.
Any writes now are directed to the "boot config" file. This is essential, as a "write memory" expects the "boot config" statement to be present.
If the "boot config" statement isn't present, it would write the configuration into the NVRAM, which of course, is not desirable when the objective is to save a complete configuration when the configuration is large and requires more space.
|
If the command write memory is issued with the bypass feature enabled, and is consequently followed by an RPM card reset, previous versions of the boot image will trigger the RPM card to go into boot mode (unable to load run-time IOS).
|
For safety purposes, the location of the system image is stored in a special area (called the ROMMON area) in the NVRAM. The ROMMON is always intact.
The 12.2(4)T boot image accesses and reads ROMMON in order to load the IOS image. Boot images prior to 12.2(4)T do not read the ROMMON area.
Generally, the IOS boot and run-time images are of the same versions. However, if the user changed his boot image to one prior to 12.2(4)T, on a reload, the boot image would see that the NVRAM configuration is empty (of course, this is normal when the bypass feature is enabled). However, since boot images prior to 12.2(4)T cannot access the ROMMON area, it cannot read there the location of the IOS image. Unable to see the IOS image, it instead loads itself.
|
Example 1 through Example 5 illustrate how the bypass feature is enabled and disabled, and how to validate each of these actions from the configuration display.
Example 1 Running configuration without the bypass feature enabled
rpm_slot02#show running-config
Building configuration...
Current configuration : 470 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
snmp-server community public RO
snmp-server community private RW
Example 2 Enable the bypass feature (rpmnvbypass)
rpm_slot02#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
rpm_slot02(config)#rpmnvbypass
The "boot config" statement has been (re)added to your
runing configuration. Do not remove it else risk not
using the nvbypass feature
Example 3 Running configuration with bypass feature enabled (note rpmnvbypass at end of output)
rpm_slot02#show running-config
Building configuration...
Current configuration : 515 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02 <==== Line added as per output above
snmp-server community public RO
snmp-server community private RW
Example 4 Disable the bypass feature (no rpmnvbypass)
rpm_slot02#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
rpm_slot02(config)#no rpmnvbypass
Example 5 Running configuration after the bypass feature is disabled
rpm_slot02#show running-config
Building configuration...
Current configuration : 503 bytes
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
boot system c:rpm-js-mz.122-3.6.T1
boot config c:auto_config_slot02
snmp-server community public RO
snmp-server community private RW
Refer to Route Processor Module (RPM) Addendum for more specific information about the RPM.
Upgrading from an MGX-RPM-128M/B Card to an MGX-RPM-PR Card
To replace an MGX-RPM-128M/B card with an MGX-RPM-PR card, the PXM must be running MGX Software Release 1.1.34 or later, and the RPM must be running IOS release 12.2(4)T or later. Then perform the following procedure.
Step 1 Insert the RPM-PR in a test node.
Step 2 Copy the new RPM-PR boot image to the flash. Verify that the boot image is the first file in the flash.
Step 3 Modify the configuration of the file to use the latest IOS image on the c: drive by entering the boot system c:<IOS_filename> command.
Step 4 Enter the write memory command to save the configuration file in NVRAM.
Step 5 Enter the show bootvar command to check the BOOT variable and to verify that the card us configured to boot from the latest image.
Now the MGX-RPM-PR card is ready to replace an MGX-RPM-128M/B card.
Step 6 Verify the following before inserting the RPM-PR in the node:
•PXM must be running a minimum firmware release of 1.1.34.
•PXM disk contains the latest IOS image specified for the MGX-RPM-PR.
Caution Once an MGX-RPM-128M/B card is replaced with a MGX-RPM-PR card, the MGX-RPM-128M/B card can not be re-installed. If an attempt is made to re-install the MGX-RPM-128M/B, the module will be put into 'Mismatch'.
Caution After installing the MGX-RPM-PR card, be sure not to mix card redundancy.
Booting the RPM
When the RPM is booted, the boot image must be the first file in the bootflash. If the bootflash does not have a valid boot image as a first file, the card may not be able to boot and can result in bootflash corruption. If the bootflash is corrupted, you will have to send the card back for an external burn with a valid boot image.
You can reboot the RPM from the PXM by entering the command resetcd <card_number> from the switch CLI, where card_number is the slot number of the RPM that is being rebooted.
Note Omitting the card number resets the entire system.
Also, you can reboot the RPM from the RPM using the RPM console port and entering the reload command.
Each time you turn on power to the RPM by inserting the RPM into the MGX 8850, it goes through the following boot sequence:
1. The RPM runs diagnostics on the CPU, memory, and interfaces.
2. The system bootstrap software, which is the boot image, executes and searches for a valid Cisco IOS image, which is the RPM runtime software.
The source of the Cisco IOS image is determined by the configuration register setting. To verify this setting, you can enter either the show version or show bootvar command.
•If the configuration register is set to the factory-default setting of 0x01, RPM will come up and stay in boot mode.
•If the configuration register is 0x2, the RPM will look for the runtime image either in bootflash or on the PXM C:RPM drive.
3. The search for runtime image is determined by which boot system command is entered.
•Entering the boot system c:<runtime_image_name> command will result in a search for a runtime image on the PXM C:RPM drive.
•Entering the boot system bootflash:<runtime_image_name> command will result in a search for a run time image in the bootflash.
4. If the runtime software is not found after three attempts, the RPM reverts to the boot mode.
5. If a valid Cisco IOS image is found, then the RPM searches for a valid configuration, which can reside in NVRAM or as a configuration file either on the PXM hard disk C: drive or in bootflash.
If you want to load from a specific configuration file, you should enter either the boot config bootflash:<config_file> command or the boot config c:<config_file> command.
6. For normal RPM operation, there must be a valid Cisco IOS image on the PXM C: drive or in bootflash, and a configuration in NVRAM or configuration file in bootflash or on the PXM disk.
The first time you boot the RPM, configure the RPM interfaces and save the configuration to a file in NVRAM. For information on the Cisco IOS instructions, refer to the link below:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/8850r21/rpm/21appc.htm
RPM Bootflash Precautions
The RPM bootflash is used to store boot image, configuration and "run time" files. The Flash stores and accesses data sequentially, and the RPM boot image must be the first file stored to successfully boot the card. Erasing the boot image or moving it from the first position on the Flash will cause the card to not boot.
The RPM boot image, which comes loaded on the Flash, will work for all RPM IOS images. Therefore, there is no reason to ever delete or move the factory installed boot image.
Note Erasing or moving the boot image can cause RPM boot failure. When this happens, the RPM must be returned to Cisco and re-flashed.
In order to avoid this unnecessary failure, requiring card servicing, you should
•Never erase the boot file from the RPM Flash
•Never change the position of the boot file on the RPM Flash
•Use care when "squeezing" the Flash to clean it up.
As long as the boot file remains intact in the first position on the flash, the RPM will successfully boot.
Upgrading with 1:N Redundancy
The following procedure describes how to upgrade redundant RPM cards.
Note Redundancy must be established before you use this procedure.
Step 1 On the primary RPM card, upgrade the software. Refer to the 1.1.40 Version Software Release Notes Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Switches.
Tips Enter the copy run start command to save the configuration change.
Step 2 Switch to the secondary card using the softswitch command.
mgx8850a.7.PXM.a > softswitch <fromSlot> <toSlot>
This step makes the secondary card active and resets the primary RPM card. When the primary card resets, it loads the upgraded software defined in Step 1.
Step 3 After the secondary card is active, configure it to upgrade the software. (See Step 1.)
Step 4 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 runs the upgraded software.
Step 5 If there are other primary cards with redundant (secondary) cards, repeat this procedure for each primary card.
Upgrading Non-redundant MGX-RPM-PR Cards
The following procedure describes how to upgrade non-redundant MGX-RPM-PR cards.
Step 1 Configure the MGX-RPM-PR card to store its configuration on the PXM hard disk by entering the boot config c:auto_config_<slot#> command or by saving it in NVRAM by entering the WR MEM command.
Step 2 Modify the running configuration to boot from the new upgrade software by entering the boot system command.
Step 3 Enter WR MEM to save the configuration.
Step 4 Reset the MGX-RPM-PR card by entering the reset command from the PXM or the reload command from the MGX-RPM-PR.
Historical Information from the 1.1.3x Baseline
Features Introduced in Release 1.1.34
Release 1.1.34 is a feature release. The following Reliability, Availability, and Serviceability (RAS) features are available for the MGX 8850, MGX 8250, and MGX 8230 with Release 1.1.34.
Features that require 1.1.34
|
Feature
|
Availability
|
IOS
|
CWM
|
Online Diagnostics on PXM
|
Release 1.1.34
|
12.2(2)T2
|
10.4.01 patch 1
|
Power on self test (POST) for PXM
|
Release 1.1.34
|
12.2(2)T2
|
10.4.01 patch 1
|
Enhanced ATM-LMI
|
Release 1.1.34
|
12.2(2)T2
|
10.4.01 patch 1
|
Buffer allocation priority
|
Release 1.1.34
|
12.2(2)T2
|
10.4.01 patch 1
|
VISM 2.1(0) support
|
Release 1.1.34
|
--
|
--
|
Online Diagnostics
The online diagnostics feature provides you with the tools to proactively monitor the hardware and software components on the PXM. While diagnostics usually focuses solely on hardware, equally critical software resources can impact network availability. The online diagnostics feature provides support in critical software areas and allows you to:
•Run non-destructive tests on some of the hardware and software components on the PXM.
•Execute tests periodically in the background on either the Active and Standby PXM, with a minimum time interval of 1 minute.
•Choose from a series of available, configurable diagnostic tests, that can be used as part of online diagnostics
•Configure start times, iterations and in some cases parameters, for each test.
•View test results from various interfaces (CLI, CWM). Tests will generate logs, card alarms, and traps.
The following table lists the commands used to configure, run, and display the online diagnostics. More information about each command, along with examples of the command, are found in the sections that follow the table.
New Command
|
Description
|
See
|
adddiagtest
|
Adds a test as part of the online diagnostics.
|
adddiagtest
|
cnfdiagparams
|
Configures diagnostic test parameters.
|
cnfdiagparams
|
deldiagtest
|
Deletes a test configured as part of online diagnostics.
|
deldiagtest
|
cnfdiagtest
|
Modifies the parameters of a diagnostic test.
|
cnfdiagtest
|
dspdiagresults
|
Displays the results of the configured tests.
|
dspdiagresults
|
dspdiagtests
|
Displays the configured tests and their parameters.
|
dspdiagtests
|
showdiagtests
|
Displays the list of available tests
|
showdiagtests
|
rundiagtest
|
Executes individual diagnostics tests.
|
rundiagtest
|
clralldiagtests
|
Deletes all diagnostics tests currently configured.
|
clralldiagtests
|
clrdiagresults
|
Clears diagnostics test results.
|
clrdiagresults
|
pausediag
|
Temporarily stops the diagnostics test.
|
pausediag/resumediag
|
resumediag
|
Resume a diagnostics test that was paused.
|
pausediag/resumediag
|
adddiagtest
Description
Adds a test as part of the online diagnostics on ASC.
Syntax
adddiagtest <testNumber> <testState>
Parameter
|
Description
|
<testNumber>
|
A test number, 1-15. Use the command showdiagtests to display a list of tests and their corresponding numbers. Run showdiagtests <testNumber> to see a description of the test.
1-BRAM Checksum (software)
2-Hard Disk Access (hardware)
3-Framer Access (hardware)
4-CBC Access (hardware)
5-QE Access (hardware)
6-RCMP Access (hardware)
7-Ethernet Test (hardware)
8-SRM M13 Access (hardware)
9-DRAM Memory Availability (software)
10-SAR Buffer Availability (software)
11-CPU Performance Monitor (software)
12-Trap Frequency Monitor (software)
13-QE ASIC Error Counter Monitor (hardware)
14-CBC ASIC Monitor (hardware)
15-CBC Path Test (hardware)
|
<testState>
|
Card state in which to execute the command.
1-active PXM
2-standby PXM
3-active and standby PXM
|
Example
Test Number 1 ? "BRAM Checksum" added to Online Diagnostics
Use Unique Test ID 16 to refer to this test
cnfdiagtest
Description
Modifies the parameters of a diagnostic test that is configured as part of online diagnostics.
Syntax
cnfdiagtest <Unique Test ID> <startTime> <period> <iterations>
Parameter
|
Description
|
<Unique Test ID>
|
An ID value obtained from the command dspdiagtests.
|
<startTime>
|
Specify the test start time in the format HH:MM, or specify "Now" to execute the test immediately.
|
<period>
|
Frequency with which the test needs to be executed. The minimum time period that can be configured is 1 minute. The range is 1-1439.Period in minutes
|
<iterations>
|
Number of times the test should be repeated. When the value is specified as -1, the test will continue to execute.
|
Example
PXM.a > cnfdiagtest 10 NOW 15 -1
Test added to start executing immediately, every 15 minutes, forever.
PXM.a > cnfdiagtest 5 12:00 1440 -1
cnfdiagparams
Description
Modifies test input parameters of a test added as part of online diagnostics
Syntax
cnfdiagparams <Unique Test ID> <param1> <param2>
Parameter
|
Description
|
<Unique Test ID>
|
An ID value obtained from the command dspdiagtests.
|
<param1>
|
First parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>.
|
<param2>
|
Second parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>. If the second parameter is not entered, the value will be zero.
|
Example
PXM.a > cnfdiagparams 10 10 0
dspdiagtests
Description
Displays the configured tests and their parameters.
Syntax
dspdiagtests
Output Field
|
Description
|
ID
|
A test number, 1-15.
|
Test Name
|
One of the following tests:
BRAM Checksum
Hard Disk Access
Framer Access
CBC Access
QE Access
RCMP Access
Ethernet Test
SRM M13 Access
DRAM Memory Availability
SAR Buffer Availability
CPU Performance Monitor
Trap Frequency Monitor
QE ASIC Error Counter Monitor
CBC ASIC Monitor
CBC Path Test
|
State
|
Card state in which test is executed. Values are, Active, Standby, or Act/Stb (active and standby).
|
Start Time
|
Specify the test start time in the format HH:MM, or specify "Now" to execute the test immediately.
|
Period
|
Frequency with which the test needs to be executed. The minimum time period that can be configured is 1 minute. The range is 1-1439.Period in minutes
|
Iteratns
|
Number of times the test should be repeated. When the value is specified as -1, the test will continue to execute.
|
Param1
|
First parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>.
|
Param2
|
Second parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>. If the second parameter is not entered, the value will be zero.
|
Example
ID Test Name State Start Time Period Iteratns Param1 Param2
-- ------------------------------- ------- --------------- --------- ---------- ----------- -----------
1 BRAM Checksum Act/Stb FOREVER 1 FOREVER N/A N/A
2 Trap Frequency Monitor Active FOREVER 1 FOREVER 50 N/A
3 Hard Disk Access Standby FOREVER 1 FOREVER N/A N/A
4 Framer Access Act/Stb FOREVER 1 FOREVER N/A N/A
Online Diagnostics : RUNNING
dspdiagresults
Description
Display the results of the configured tests.
Syntax
dspdiagresults
Output Field
|
Description
|
ID
|
A test number, 1-15.
|
Test Name
|
Name of the test.
|
Result
|
Status of the test; whether it has passed or failed.
|
Pass Count
|
Number of times the test has passed.
|
Fail Count
|
Number of times the test has failed.
|
Example
ID Test Name Result Pass Count Fail Count
-- ------------------------------- --------- --------------- --------------
1 BRAM Checksum PASS 5603 0
2 Trap Frequency Monitor FAIL 5602 1
3 Hard Disk Access PASS 5603 0
4 Framer Access PASS 5603 0
clrdiagresults
Description
Clears the results of all the configured tests. To confirm that the results have been cleared, you can run the command dspdiagresults.
Syntax
clrdiagresults
Example
ID Test Name Result Pass Count Fail Count
-- ------------------------------- --------- --------------- --------------
1 BRAM Checksum PASS 5603 0
2 Trap Frequency Monitor FAIL 5602 1
3 Hard Disk Access PASS 5603 0
4 Framer Access PASS 5603 0
ID Test Name Result Pass Count Fail Count
-- ------------------------------- --------- --------------- --------------
2 Trap Frequency Monitor N/A 0 0
3 Hard Disk Access N/A 0 0
showdiagtests
Description
Displays the list of available tests when executed without the optional parameter. When the optional parameter Test Number is used, displays the meaning of the test, as well as test parameter options.
Syntax
showdiagtests [<Test Number>]
Parameter
|
Description
|
Test Number
|
A test number, 1-15.
|
Example 1
------------------ ---------
9 DRAM Memory Availability
10 SAR Buffer Availability
11 CPU Performance Monitor
12 Trap Frequency Monitor
13 QE ASIC Error Counter Monitor
Example 2
Function : Monitors the Trap Frequency
An Alarm is reported if Trap Frequency cross the threshold.
Input Parameter : Threshold : (0 > = 0) Th4reshold for permissible
trap numbers to be sent per second.
Example 3
Function : Performs BRAM Checksum Test
deldiagtest
Description
Removes a test from being executed in the background.
Syntax
deldiagtest <Unique Test ID>
Parameter
|
Description
|
Unique Test Id
|
A test number, 1-15.
|
Example
rundiagtest
Description
Executes an individual diagnostics test.
Syntax
rundiagtest <Test Number> <param1> <param2>
Output Field
|
Description
|
Test Number
|
A test number, 1-15.
|
Param1
|
First parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>.
|
Param2
|
Second parameter for the diagnostics test. The meaning of this parameter differs for different tests. To find the meaning of the parameter, use the command showdiagtests <testNumber>. If the second parameter is not entered, the value will be zero.
|
Example
PXM.a > rundiagtest 10 10 0
SAR Buffer Availability PASSED
pausediag/resumediag
Description
The pausediag command temporarily pauses diagnostic test execution. After running this command, you can execute the dspdiagtests command; "online diagnostics" at the bottom of the display will indicate PAUSED.
Run the resumediag command to remove the pause and resume the diagnostics test.
Syntax
pausediag
Example
Online Diagnostic Tests are Paused
ID Test Name State Start Time Period Iteratns Param1 Param2
-- ------------------------------- ------- --------------- --------- ---------- -----------
-----------
1 BRAM Checksum Act/Stb FOREVER 1 FOREVER N/A N/A
2 Trap Frequency Monitor Active FOREVER 1 FOREVER 50 N/A
3 Hard Disk Access Standby FOREVER 1 FOREVER N/A N/A
4 Framer Access Act/Stb FOREVER 1 FOREVER N/A N/A
Online Diagnostics : PAUSED
clralldiagtests
Description
Deletes all tests from online diagnostics that are currently configured. Confirmation of this command can be seen by running the dspdiagtests command, which will show "No tests configured to run online."
Syntax
clralldiagtests
Example
Cleared all Online Diagnostic tests
Online Diagnostics : No tests configured to run online
Diagnostics Failure Reporting
The following examples show the log and card output. Both examples show the alarms generated by failed diagnostics test.
Example 1 log output
05/29/2001-16:19:56 08 tOnlnDiag ONLI-7-ONLNDIAG_CARDIN
Card in alarm: Online Diag Test SAR Buffer Availability Unique ID: 1 Failed
05/29/2001-16:19:56 08 tOnlnDiag ONLI-7-ONLNDIAG_TEST_F
Online Diag Test SAR Buffer Availability Unique ID: 1 Failed
05/29/2001-16:19:56 08 tOnlnDiag ONLI-7-ONLNDIAG_TEST_F Online Diag test Failed.
SAR Buffer Availability Unique ID: 1 Pool: 0. PctAvlSarBuf = 99, Threshold = 100
Example 2 card output
FunctionModuleState: Active
FunctionModuleType: PXM1-T3E3
FunctionModuleSerialNum: SBK042500A3
FunctionModuleFWRev: 1.1.34l
FunctionModuleResetReason: Upgrade Reset
SecondaryLineModuleType: LM-BNC-2T3
SecondaryLineModuleState: Present
configChangeTypeBitMap: No changes
cardIntegratedAlarm: Minor
cardMajorAlarmBitMap: Clear
cardMinorAlarmBitMap: Online Diags Failure on slot 8
BkCardSerialNum: SBK043601D1
TrunkBkCardSerialNum: SBK0310007T
FrontCardPCBNumber: 800-05760-02
TrunkBkCardPCBNumber: 800-04057-02
Power On Self Test (POST) on PXM
The Power On Self Tests (POST) on the PXM are destructive tests executed on key components, and are used to detect component failure. The PXM Boot code executes the POST tests, and therefore, are executed on every reset.
Because some components cannot be turned on during the bootup, POST is limited to testing the components that are on during the bootup phase.
POST Failure is reported through the CLI, log messages, card alarms, and traps.
POST Tests on PXM include:
•BRAM Checksum test
•QE RAM test
•CBC RAM test
•Ethernet Register test
•PCI_IDE Register test
•Clock Mux test
•Framer Access test
•RCMP RAM test
Example 1 PXM boot capture
POST: BRAM checksum...PASSED
POST: Ethernet reg...PASSE
POST: PCI-IDE reg...PASSED
POST: Framer access...PASSED
Copied POST results to 0x80001000, 704 bytes
Initializing the disk driver ...
......................................
Example 2 dsppostresults and dspcd commands
Use the command dsppostresults on Active and Standby PXM to determine the POST results for the respective PXM cards.
Test Description Result Detail Description
---------------- ------ ------------------
Use the command dspcd to display the card alarms. Notice the alarm Post Failure on slot 8.
FunctionModuleState: Active
FunctionModuleType: PXM1-T3E3
FunctionModuleSerialNum: SBK042500A3
FunctionModuleFWRev: 1.1.34l
FunctionModuleResetReason: Upgrade Reset
SecondaryLineModuleType: LM-BNC-2T3
SecondaryLineModuleState: Present
configChangeTypeBitMap: No changes
cardIntegratedAlarm: Minor
cardMajorAlarmBitMap: Clear
cardMinorAlarmBitMap: POST Failure on slot 8
BkCardSerialNum: SBK043601D1
TrunkBkCardSerialNum: SBK0310007T
FrontCardPCBNumber: 800-05760-02
TrunkBkCardPCBNumber: 800-04057-02
Enhanced ATM-LMI
Enhanced ATM-LMI is designed to protect data traffic in the case of a ATM-LMI failure. ATM-LMI is an important protocol used between a feeder and a switch; for example, the MGX 8230 used as a feeder and connected to a BPX 8600. Motivation. Any failure of this protocol fails all the PVCs on the node; therefore, this protocol should be highly reliable and fail only for genuine reasons.
When an ATM-LMI protocol failure occurs, and enhanced ATM-LMI is enabled, the data continuity will be checked before conditioning the PVC's into alarm.
In order for the feature to provide full coverage, the similar feature must exist in the version of software running on the BPX 8600 or other ATM switch. Also, it depends on the presence of data traffic.
Use the commands cnfenhlmi and dspenhlmi to configure and display Enhanced ATM-LMI.
Syntax
cnfenhlmi <slot.port> <EnhLmiEnable> <dataContRetry>
Parameters
|
Description
|
<slot.port>
|
A slot number 1-32; a port number 1-256.
|
<EnhLmiEnable>
|
Enable or disable enhanced ATM-LMI feature; enter Yes or No. The default is No; disabled.
|
<dataContRetry>
|
The data continuity retry in seconds. The range is 1-600 seconds. The recommended retry is 5 secs.
|
Example
PXM.a > cnfenhlmi 7 1 Yes 5
TRK ENHANCED LMI ENABLED CNF RETRY
-----------------------------------------
Buffer Allocation Priority
SAR buffers are shared by all applications on the PXM. If a low priority application operates inefficiently and overutilizes SAR buffers, it impacts higher priority and more critical applications by forcing them to operate without adequate buffers. Such conditions impact it impact network availability.
The buffer allocation priority feature distinguishes SAR buffer allocation between high priority and low priority applications. This directly supports ATM-LMI and SCM polling, both of which are considered high priority applications.
The feature is available once a successful upgrade to Release 1.1.34 is completed, and cannot be enabled or disabled.
Problems Fixed in Release 1.1.34
Bug ID
|
Description
|
CSCds67533
|
yellow alarm should not be sent on CLEAR (unstructured) E1 line
|
CSCds87925
|
Axis:buffer overflow problem causes one way traffic
|
CSCdt22219
|
Connections added to alarmed PXM port do not recover properly
|
CSCdt33066
|
RPM card never goes to Failed State and this may impact 1:N redundancy also
|
CSCdt36828
|
PXM switchover on a channel modification
|
CSCdt37479
|
continuous failed traceback message RPM_VIRTUAL_PORT-3-VRTLERR
|
CSCdt41897
|
mcrBwd is different from mcrFwd, pcrFwd and pcrBwd
|
CSCdt47663
|
After power cycle of the shelf trunk backcard inaccessible
|
CSCdt49644
|
dspcd is not working on card that shows mismatch
|
CSCdt50606
|
Interface on MGX slot 7 shows failed APS on both BPX and MGX shows OK
|
CSCdt50905
|
Does not show the right interface when back card PXM is removed.
|
CSCdt51645
|
After multiple switchcc, PXM in slot #8 is stuck in CardInit state
|
CSCdt56636
|
Exception while using dspnovram on SRM cards
|
CSCdt60892
|
Core shows Device Driver Error on shelf.
|
CSCdt60998
|
Core dump shows software error while running 1.1.33Ac.
|
CSCdt61771
|
On clrsmcnf, PXM prints some string on console which might break expect script
|
CSCdt61936
|
Under low memory conditions Active PXM can get reset because of watchdog
|
CSCdt65310
|
Not Responding state is not a part of MIB and hence will cause problems
|
CSCdt66754
|
PXM does not recognize SRM card in slot 14 when RPM in slot 6.
|
CSCdt67137
|
Unable to cc into an RPM in boot mode
|
CSCdt67556
|
Switchcc message missed - No retransmission- RPM in failed state
|
CSCdt67767
|
Software error Mar. 03 file name nj42_s4_02mar on slot #8
|
CSCdt68144
|
Cannot telnet to shelf after shuffling PXMs between shelves
|
CSCdt69590
|
Standby FRSM card reset twice while coming up
|
CSCdt70311
|
RPM in Reserved state (in Rommon state) after continuous Resetcd.
|
CSCdt70488
|
Cannot configure RPM after doing cc from PXM if RPM in Boot state
|
CSCdt70786
|
clrsmcnf does not clear RPM configuration
|
CSCdt71121
|
Core dump shows software error occurred on 3_11.
|
CSCdt71524
|
SwitchOver Msg not sent to RPM, when switchcc follows softswitch (Pri->Sec)
|
CSCdt75765
|
clrsmcnf to rpm participating in 1:N red clears the auto_config
|
CSCdt78616
|
Cannot delete port on FRSM unless command is invoked twice.
|
CSCdt88238
|
Can not cc to SM after PXM failover
|
CSCdt93357
|
Upon resetting the Active FRSM-2CT3, both the cards seen stuck in standby
|
CSCdt93367
|
SRM and PXM state change not updated after standby PXM get into HOLD state
|
CSCdt94118
|
Missing PDUs from ports 2,4,6 & 8 on AUSM-8E1/B during traffic test
|
CSCdt97663
|
Unable to disable stats on a PXM1 node
|
CSCdu07281
|
After second resetsys, standby PXM Empty, SM reserved.
|
CSCdu12023
|
MGX external clock input is not correctly accepted
|
CSCdu12917
|
AUSM-8T1/E1 cards stuck in CardInit state during boot up
|
CSCdu30080
|
Softswitch failed, cant cc to the active AUSM.
|
CSCdu31239
|
After repeated softswitches, RPM and FRSM-2CT3 cards gets stuck in CardInit
|
CSCdu32432
|
DS3 does not show any alarm when Tx and Rx cable are removed from SRM
|
CSCdu45583
|
AUSM slot #30 and #28 softswitch back upon switchcc.
|
CSCdu54665
|
Connections on FRSM-8T1E1 do not show a service type
|
CSCdu54875
|
Cannot configure a channel after upgrade to 1.1.34
|
CSCdu61035
|
FE stops responding after traffic passes for 8 hrs, rpm says int. OK
|
Known Anomalies for Platform Software Release 1.1.34 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.1.34 software. Included with each is a brief discussion of the problem. A more in-depth discussion is available in the Release Note enclosure of the problem record in Bug Navigator.
Bug ID
|
Description
|
CSCds58040
|
This bug is closed, and was fixed in Release 1.1.40.
|
CSCds83090
|
This bug is closed because there was insufficient information to reproduce the bug.
|
CSCds83554
|
This bug is closed because it was a user error.
|
CSCdt03252
|
This bug is closed because it was a user error.
|
CSCdt03580
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt05474
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt28249
|
This bug was determined to be an IOS bug.
|
CSCdt38056
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt42041
|
This bug is a duplicate of CSCdt18401, which was fixed in 1.1.34.
|
CSCdt42778
|
This bug is closed, and was fixed in Release 1.1.34.
|
CSCdt44373
|
This bug is a duplicate of CSCdu12917, which was fixed in 1.1.34.
|
CSCdt44475
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt45706
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt53527
|
This bug is closed, and was fixed in Release 1.1.34.
|
CSCdt58037
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdt63497
|
This bug is closed. A DRAM memory test was implemented in 1.1.34.
|
CSCdt67828
|
This bug is in the "I" state, and the customer agreed to monitor it.
|
CSCdt70642
|
Symptom:
On a PXM switchover a PXM line hooked up to Adtech receives LOS momentarily.
Condition: A PXM port is connected to adtech. On a switchcc the adtech port receives a momentary LOS. Switchcc should be graceful and getting an LOS on switchcc is not acceptable.
Workaround:
Unknown.
|
CSCdt71240
|
This bug is a duplicate of CSCdu39315, which was fixed in 1.1.40.
|
CSCdt75500
|
This bug was determined to be an IOS bug.
|
CSCdt95937
|
This bug is closed because there was insufficient information to reproduce the bug.
|
CSCdt96671
|
This bug is closed, and was fixed in Release 1.1.40.
|
CSCdu02695
|
This bug is closed, and was fixed in Release 1.1.40.
|
CSCdu07060
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu07122
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu11132
|
This bug is closed because the problem could not be reproduced, and the customer agree to close it.
|
CSCdu18583
|
This bug is a duplicate of CSCds79660, which was fixed in 1.1.34.
|
CSCdu21136
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu21155
|
This bug is closed because a maximum of 50 users are supported.
|
CSCdu21988
|
This bug is closed because it is similar to CSCdt18401, which was fixed in 1.1.34.
|
CSCdu22398
|
This bug is closed because it is a design issue that cannot be resolved at this time.
|
CSCdu23948
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu25295
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu26869
|
This bug is closed because it was decided that the switch is behaving correctly.
|
CSCdu27251
|
This bug is closed, and was fixed in 1.1.40.
|
CSCdu27272
|
This bug is closed because the configuration was incorrect.
|
CSCdu27733
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu31686
|
This bug is closed because it was decided that the switch is behaving correctly.
|
CSCdu35704
|
This bug is closed because it was decided that it was a hardware problem, and CSCdu40524 is the bug ID.
|
CSCdu36455
|
This bug is closed, and was fixed in 1.1.40.
|
CSCdu36970
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu36978
|
This bug is closed because it was decided that it was a hardware issue.
|
CSCdu38240
|
This bug is closed because the configuration was incorrect.
|
CSCdu38845
|
This bug is closed because it is a duplicate of CSCdu38671.
|
CSCdu39325
|
This bug is closed because it was decided to be an IOS problem.
|
CSCdu39799
|
This bug is closed because it is a duplicate of CSCdu47467.
|
CSCdu40067
|
This bug is a duplicate of CSCdu39315, which was fixed in 1.1.40.
|
CSCdu40524
|
Duplicate anomaly. Please refer to CSCdu35704 for a description of the problem.
|
CSCdu40820
|
This bug is in the "I" state because more information is needed from the customer.
|
CSCdu40885
|
This bug is in the "I" state because more information is needed from the customer.
|
CSCdu41352
|
This bug is closed since a design modification would be required.
|
CSCdu42177
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu44086
|
This bug is closed because the configuration was incorrect.
|
CSCdu45565
|
This bug is closed because the problem could not be reproduced after upgrading the AUSM.
|
CSCdu45583
|
This bug is closed, and was fixed in Release 1.1.34.
|
CSCdu45874
|
This bug is closed because the problem could not be reproduced.
|
CSCdu49424
|
This bug is closed because despite many attempts it was unreproducible.
|
CSCdu49464
|
This bug is in the "I" state, and the customer agreed to monitor it.
|
CSCdu51152
|
This bug is a duplicate of CSCdu27251, which was fixed in 1.1.40.
|
CSCdu51707
|
This bug is a duplicate of CSCdv08621, which was fixed in 1.1.40.
|
CSCdu53799
|
This bug is closed because it is a duplicate of CSCdu78911.
|
CSCdu53814
|
This bug is closed, and was fixed in release 1.1.40.
|
CSCdu72190
|
This bug is closed, and was fixed in release 1.1.40.
|
Features Introduced in Release 1.1.32
RPM features that require 1.1.32 bundled with IOS 12.1(5.3)T_XT
|
Feature
|
Availability
|
IOS
|
CWM
|
Support for Multiple RPM Card Types
|
Release 1.1.32
|
12.1(5.3)T_XT
|
10.4.01
|
Support for RPM-PR module for MGX-PXM1
|
Release 1.1.32*
|
12.1(5.3)T_XT
|
10.4.01
|
Support for RPM/B in MGX 8230
|
Release 1.1.32
|
12.1(5.3)T_XT
|
10.4.01
|
Feature Descriptions
Note Please refer to the "Route Processor Module (RPM) Addendum" section for additional information and special instructions on the installation of RPM modules with Release 1.1.32.
Support for Multiple RPM Card Types
When multiple RPM card types are present in the network, the PXM1 will recognize and display the correct RPM card type. The current RPM card types are RPM/B and RPM-PR. The MGX 1.1.32 Release contains PXM code base changes that recognize the multiple RPM card types.
Support for RPM-PR Module with MGX-PXM1
The RPM-PR provides the following features:
•More than twice the forwarding performance of the RPM/B.
•Supports up to 512 Mbytes SDRAM.
•Provides integrated ATM SAR with OC-6 cell bus rates to the PXM1.
•Flash memory increased to 32M.
The higher-performance RPM requires Software Release 1.1.32, IOS version12.1(5.3)T_XT, and a minimum CWM version of 10.4.01.
Support for RPM/B in MGX 8230
Installation of the RPM/B in the MGX 8230 requires Release 1.1.32 and IOS version 12.1(5.3)T_XT
Note Customers planning to use RPM/B in the MGX 8230 should upgrade to MGX Software Release 1.1.32 and CWM 10.4.01.
Features Introduced in Release 1.1.3x
The following features are available for the MGX 8850, MGX 8250, and MGX 8230 with Release 1.1.3x and IOS 12.1(3)T:
Features that require 1.1.3x bundled with IOS 12.1(3)T
|
Feature
|
Availability
|
CoS Map for FRSM-8
|
Release 1.1.3x
|
DS3 Loopback on PXM-T3
|
Release 1.1.3x
|
ForeSight and Standard ABR Coexistence Guidelines
|
Release 1.1.3x
|
Independent Service Rate on FRSM-HS1/B
|
Release 1.1.3x
|
Online Diagnostics for PXM
|
Release 1.1.3x
|
SRM in MGX 8230
|
Release 1.1.3x
|
Standard ABR on AUSM
|
Release 1.1.3x
|
Standard ABR on FRSM-8 and FRSM8-C Modules
|
Release 1.1.3x
|
Stratum-3 Clocking
|
Feature not available.
|
VBR-rt on AUSM
|
Release 1.1.3x
|
VISM 1.5.05 on MGX 8250/8850
|
Release 1.1.3x
|
VISM 2.0.0 on MGX 8230/8250/8850
|
Release 1.1.3x
|
Problems Fixed in Release 1.1.32
Bug ID
|
Description
|
CSCdp38293
|
dspcd on SRM displays b/c 800 # as f/c 800 #
|
CSCds09448
|
lper_util & rper_util not available in TFTP & SNMP config upload files
|
CSCds24381
|
SLT:PXM7 switched to PXM8 overnight, w/Reset Code= Software Error
|
CSCds25261
|
ILMI Failure trap causes HP OPenview to crash
|
CSCds31371
|
Phantom switchcc
|
CSCds37482
|
BERT fails intermittently with general error. RESETCD required to resume
|
CSCds38566
|
The SCM Queue reports an overflow for the slots containing RPM cards
|
CSCds43238
|
rt-vbr in dsploads
|
CSCds43415
|
SLT:Telnet session lost after clrsmcnf CLI, several SMs in Boot states.
|
CSCds48811
|
Manual refresh of CiscoView Chassis causes MGX8230 Standby PXM to fail
|
CSCds52286
|
Infinite loop on the telnet input task, causing PXM switchovers
|
CSCds55580
|
Latest IOS changes direct structure which breaks dir c:
|
CSCds60208
|
Switch reboots sometimes when switchcc is entered.
|
CSCds65330
|
RPM went into failed/not responding state after upgrade from 1.1.24 to 1.1.3xA
|
CSCds66048
|
Bit errors seen on BERT tests for CESM cards
|
CSCds66176
|
Ports are lost sometimes after a softswitch/resetcd on the FRSM-2CT3
|
CSCds67365
|
PREFIX: Resolve warnings reported by prefix tool
|
CSCds71795
|
Core dump shows errors on Standby PXM
|
CSCds72478
|
Core Dumped caused by Software Error reset
|
CSCds72620
|
Softswitch from secondary to primary puts the primary card to failed state.
|
CSCds73092
|
PXM does not allow RSRCPRTN Resync
|
CSCds73935
|
vhs oam buffers overflow
|
CSCds75559
|
Connection with SrcDst behavior stops forwarding traffic after few seconds
|
CSCds76985
|
After the upgrade, chassis type changed from MGX8850 to MGX8250
|
CSCds81247
|
Inband clk fails to become primary when it fails and recovers
|
CSCds82530
|
RPM gets stuck in go active /go standby stage on resetsys and resetcd
|
CSCdt00463
|
Switch sends wrong card type (-32600) to CWM
|
Known Anomalies for Platform Software Release 1.1.32 and Service Module Firmware
The following is the list of known anomalies in the service module firmware and the Release 1.1.32 software. Refer to Bug Navigator for a current description of these problems, or to the 1.1.32 Version Software Release Notes Cisco WAN MGX 8850, 8230, and 8250 Software.
Bug ID
|
Description
|
CSCdk54268
|
When sending cells of VPI=0, VCI=0, and CLP=1 from a UNI port, dspportcnt reports the cells as being discarded due to VpiVciErr and the cell rate also gets updated.
|
CSCdk71643
|
End-to-end connectivity with full recovery in cases of error does not fully function with current design.
|
CSCdk86638
|
When using CWM to add connections, if the connection addition request times out, subsequent addition of the same connection may fail as well, complaining that the connection already exists (even though it timed out).
|
CSCdm05358
|
When modifying a particular protected memory address on CESM8p, which causes CESM HW watchdog reset, PXM got reset or lost SAR functionality.
|
CSCdm10722
|
SM upgrade should be done with the following commands in this order: install, newrev and commit.
|
CSCdm11410
|
When listing a directory, some file names contain either illegal characters or a timestamp for the name instead of a standard DOS file name.
|
CSCdm22510
|
Connection traps are not sent out when receiving A-bit update from CPE.
|
CSCdm31437
|
SV+ needs a trap when a line is added or deleted.
|
CSCdm33351
|
An Endpoint Added Trap message and an Endpoint is Active message are sent to the manager from VISM.
|
CSCdm33605
|
When a switchover to a redundant VISM card takes place due to a reset/failure of the active VISM card, the display on CWM is not correct.
|
CSCdm33638
|
When a switchover to a redundant VISM card takes place, the display of active lines is not consistent between the shelf and CiscoView.
|
CSCdm42849
|
An execution of the dlmi command to display LMI messages results in a system reboot.
|
CSCdm43053
|
Connection addition fails.
|
CSCdm48639
|
Better error checking needs to be provided for SM boot and firmware download. It's possible to download the boot image as firmware and vice versa.
|
CSCdm53758
|
Channel alarms do not get propagated to the middle segment if NNI signaling is enabled.
|
CSCdm56094
|
The far-end device cannot be put into a loopback using the "Far End Inband Loopback" or the "Far End ESF Loopback" options under the "DEVICE TO LOOP" menu in the cnfbert command.
|
CSCdm85931
|
There are display errors for FRSM-HS1 card for dspchancnt 17.
|
CSCdm91930
|
LED status in CWM is different for lines in same status in Active card/hot standby.
|
CSCdm92345
|
The VHS SM have either DAX or FEEDER connections on the logical port, which is simulated with some kind of signaling.
|
CSCdp00912
|
Core redundancy should be allowed in mismatch state
|
CSCdp11859
|
The ABCD bits that are produced on the egress of a CCS-to-CAS connection seem to have a random/unpredictable pattern.
|
CSCdp32043
|
SV+ node sync always failed because of timeout, due to TFTP very low.
|
CSCdp34543
|
Install backup boot fails when it tries to program the flash on the standby card.
|
CSCdp35772
|
This should not affect the normal running of the system as the background memory check checks for memory corruption and leaks.
|
CSCdp36477
|
The switchcc on 8850 causes a Sig_F APS line switch on BPX.
|
CSCdp39894
|
The software error is logged as a result of an attempt to refer to a transaction that is already complete.
|
CSCdp39900
|
The software error is logged when trying to allocate a msg buffer to send VSI commit for a connection.
|
CSCdp42349
|
A PXM1-155 alarm is issued.
|
CSCdp44837
|
When deleting a large number of connections using a script, it was found that for some connections, the resources were not properly freed.
|
CSCdp46927
|
VISM card in alarm after addcid.
|
CSCdp48790
|
This problem has not been reproducible.
|
CSCdp50045
|
During boot time, VC-create failed message will be displayed.
|
CSCdp50317
|
Information displayed using the dsphotstandby command is not consistent.
|
CSCdp51707
|
Removing a Service Module, then inserting an RPM in the same slot causes the RPM to go to Active State instead of Mismatch.
|
CSCdp52549
|
This software error has been a one-time occurrence when deleting a connection.
|
CSCdp52776
|
New CLI command to delportrscprtn for the AUSM and the FRSM.
|
CSCdp53342
|
Information on this anomaly is unavailable at this time.
|
CSCdp53347
|
If two different HS1 SM have too many master and slave connections, delete about 15 slaves first.
|
CSCdp59851
|
Per the log messages, PAR failed, followed by PVC deletion.
|
CSCdp60443
|
A data outage occurs on the FRSM-2CT3, up to 15 seconds in length.
|
CSCdp63530
|
FRSM-2T3 fails after upgrading causing switchover to secondary.
|
CSCdp63922
|
Connections could not be added successfully from a SM, with a particular port/DLCI combo that did not seem to be used.
|
CSCdp63924
|
SYSTEM ERROR 20102 (PV_DB_RMV_ERR) is reported when we try to refer a completed transaction. Duplicate of the bug CSCdp39894.
|
CSCdp65639
|
Existence of any such problem that can lead to time-out scenario described in the bug report would be the one to be addressed as the root cause.
|
CSCdp65652
|
The ImaGroupRxImaId is not updating properly on the AUSM when the TxImaGroupId parameter is manually changed via the Kentrox CPE.
|
CSCdp71408
|
No information is available about this anomaly at this time.
|
CSCdp75846
|
In the AAL1 cells generated by CESM for a Structured T1 CAS connection, the AAL1 pointer may not be pointing to the first 125 us frame of the multiframe.
|
CSCdp77451
|
Inserting standby PXM can cause the Telnet to be lost on the active PXM.
|
CSCdp81287
|
The clrsmcnf says unsupported SM for CESM-8E1.
|
CSCdp84145
|
When adding a connection from CWM using local and remote nodename, which is different from the one configured on the node (because CWM is not synced), the addcon request erroneously passes and the connection gets added.
|
CSCdp84773
|
It has been found that the Resource Partitioning of an AUSM card on the PXM is registered as zero instead of a value of three.
|
CSCdp86479
|
PVCs shown as UP on RPM even when they are deleted remotely.
|
CSCdp89717
|
In some cases, when RPM fails, it is not declared as failed on PXM, and any attempt to cc to this FAILED card fails, even though it is showing ACTIVE on PXM.
|
CSCdp92736
|
The line, port, channel counters are reset to zero, and start counting from 0 after a switchcc.
|
CSCdp93004
|
When a connection fails, the A-bit status displayed on the connection manager for the particular connection always stays as "ok".
|
CSCdp94060
|
Receiving user connection modification traps 25015 for no reason.
|
CSCdp96632
|
The table rpm_port parameter will have -1 value, even if the port is in the active state.
|
CSCdp99496
|
When FRSM-VHS2T3? is ran, the return display shows that dspportstats is a command. However, no such command exists.
|
CSCdr00016
|
This problem was encountered sometimes when deleting more than 500 connections using a single delchans command.
|
CSCdr01410
|
PXM resets if holding down the return key while cc'ed to a service module.
|
CSCdr01426
|
Error logs overwritten and no core dump. Information is not retained on reset.
|
CSCdr02667
|
When IMA ports are configured on AUSM via SRM (BULK distribution), execution of switchcc causes IMA port failure.
|
CSCdr04154
|
Customer has come upon a failed PXM in their shelf and would like to have EFA done on it to determine the root cause of the failure.
|
CSCdr05471
|
Softswitch caused FRSM-CT3 cards to go to failed state, and ed map in the PXM had the same slot number for both the entries.
|
CSCdr06052
|
The dspcd in PXM would show the FAB number as 800-XXX, which is actually the PCB number.
|
CSCdr10332
|
Upon switchcc, AUSM in bulk mode receives wrong VPI-VCI cells.
|
CSCdr11454
|
PVC alarm status was not reported correctly after a Softswitch was executed on FRSM-2CT3.
|
CSCdr14672
|
Standby FRSM shows not available under redundancy and hot standby table.
|
CSCdr15892
|
The addlnloop on the PXM causes SONET line alarms, which sometimes do not clear when the loop is removed.
|
CSCdr16499
|
RPM sends Trap 50600 after resetcd.
|
CSCdr16720
|
Softswitch caused the standby FRSM-VHS to Failed state. (Though Softswitch succeeded according to the CLI it really didn't occur.)
|
CSCdr17959
|
AUSM card hangs if 2 to 3 ILMI requests are sent on a port. It reboots if 5 ILMI requests are sent.
|
CSCdr19456
|
Sending five ILMI requests to an AUSM card makes the directly connected AUSM card reboot.
|
CSCdr20239
|
When the command tstcon is issued, it clears the alarm status of connection when connection is failed due to remote A-bit failure.
|
CSCdr21393
|
The AUSM-AUSM loopback connections go into alarm.
|
CSCdr22375
|
The added between SMs fails to report a feature mismatch but dspsmcnf shows identical feature bitmaps for the two SMs.
|
CSCdr23964
|
The 50012 trap is sent twice.
|
CSCdr25038
|
There are times when we are not able to send the cc frame to the RPM card and as such not able to do a cc.
|
CSCdr25083
|
Mod Conn fails with error "Wrong OID or problem with Varbind" for FRSM-VHS endpoint connections. Both DAX/NONDAX.
|
CSCdr25163
|
Details on this anomaly are not available at this time.
|
CSCdr26529
|
Able to restoresmcnf on a different slot.
|
CSCdr28177
|
During a switchcc, VISM lines go into yellow alarm for a very short interval.
|
CSCdr36469
|
CLI commands are required to display the NOVRAM contents of all the MGX 8850 cards.
|
CSCdr41616
|
Unable to Telnet to the active FRSM card even when there only one cc session initiated to that SM.
|
CSCdr43216
|
The stand-by PXM and all service modules go into a failed stated after 64-byte packet transmitted from RPM.
|
CSCdr44024
|
The MGX and BPX defaults are consistent. The solution is to explicitly configure the framing. AXSM needs to be changed.
|
CSCdr44337
|
The aveallcnf creates 2 identical files.
|
CSCdr44487
|
System error is printed onscreen.
|
CSCdr49478
|
One-time occurrence. After a sequence combination of adding and deleting SM redundancy and clrsmcnf, and connection deletion/addition, tstcon is not passing on certain connections
|
CSCdr53807
|
The LED on a card is green even though the card failed.
|
CSCdr57422
|
Channel Active or Channel Added trap was not received by CWM.
|
CSCdr58123
|
The card gets reset.
|
CSCdr58189
|
Alarm status is inconsistent for standby PXM card.
|
CSCdr60198
|
The Arbiter PLD on the existing 4E back cards is not compatible with the PCI rev2.1 Port Adapter bridges that are used on the RPM-PR.
|
CSCdr61309
|
MGX log fills up when the Frame Relay port is in alarm.
|
CSCdr61335
|
The card gets reset.
|
CSCdr61360
|
When the AUSM card is receiving AIS from the network side as well the A-bit alarm from PXM, duplicate AIS on the port side occurs.
|
CSCdr61544
|
No information is available about this anomaly at this time.
|
CSCdr62285
|
When running BERT tests on CESM lines or ports, the PXM might report a general error.
|
CSCdr62322
|
Some of the BERT test patterns, for example, QRSS, fail to synchronize with the new CESM-8T1 card.
|
CSCdr62361
|
Able to configure line parameters on an FRSM when BERT port tests are running.
|
CSCdr62370
|
BERT pattern tests on the SRM-3T3-C are intermittently not synchronized with the FRSM-8E1 module.
|
CSCdr66666
|
Some of the lines in IMA group become unavailable. Duplicate of CSCdr58168.
|
CSCdr68155
|
Sometimes the disk update messages for the simulated delete connection/delete port done when the clrsmcnf command is issued occurs after the database is removed.
|
CSCdr71479
|
Lines on AUSM/B in slot 9 of MGX 8850 are failed upon switchover to redundant AUSM/B.
|
CSCdr71982
|
CESM addred displays incorrect error message when the card is in Reserved State.
|
CSCdr73483
|
Information on this anomaly is unavailable at this time.
|
CSCdr82396
|
The srvovrd option is not functioning in cnfchansrvrate command.
|
CSCdr90512
|
Not able to collect statistics from the MGX 8850 Release 1 shelf.
|
CSCdr90658
|
Even though xaddcon/xcnfcon displays 38328 cps as the maximum value if calculated, do not configure it to a maximum of 38328 cps.
|
CSCdr90871
|
Customer is requesting additional information be provided in the log file when a PVC is deleted.
|
CSCdr90987
|
The cnfclklevel command succeeds for level 3 even if the old PXM UI back card is used.
|
CSCdr91331
|
Configurations, like bulk mode SRM configurations, seen in unused slots of the shelf.
|
CSCdr91665
|
The displayShelfBanner on Standby PXM does not display the right banner.
|
CSCdr92373
|
PUBLIC community string should be "READ-ONLY", on MGX "PUBLIC" can be used to write by SNMP.
|
CSCdr93342
|
Details on this anomaly are not available at this time.
|
CSCdr93376
|
Details on this anomaly are not available at this time.
|
CSCdr93664
|
Unused slots on 8250 show up as "reserved" even after a clrallcnf.
|
CSCdr96138
|
Configure the transmit FEAC code to be dsx3SendPayloadCode on DS1s, which should be rejected since DS3 application on PXM is unchannelized.
|
CSCdr98578
|
Parameter fields for command dspalms is not preceded with an -example: dspalms ds3 | e3 | SONET instead of dspalms -ds3 | -e3 | -SONET
|
CSCds03072
|
The soft reset path on the RPM-PR rommon is not re-initializing the TLB correctly.
|
CSCds04372
|
Initial Burst Size behavior (IBS) is not functioning correctly for the ABR connections.
|
CSCds05040
|
The major alarm LED on the active and the standby PXM on MGX 8850 are on, while the CLI commands do not show any indication of alarm.
|
CSCds05580
|
On doing a dspcon on a PXM connection, the remote end LCN is displayed as 0.
|
CSCds05593
|
Issue a clralm on the SRM and the AlarmState clears. Issue a clralm on any SM (AUSM, FRSM, CESM) and the AlarmState does not clear.
|
CSCds05978
|
On trying to use option "*" for VCI in the cnfilmi command as specified in the CLI help, the command returns an error.
|
CSCds07944
|
The clralmcnt -ds3 does not clear the counters.
|
CSCds08528
|
The ports do not go into signaling failure even after the two ports have a signaling mismatch.
|
CSCds09036
|
The version displays StrataCom instead of displaying Cisco.
|
CSCds09448
|
At present CWM is setting %util values(lper_util, rper_util) to -1. CWM will get these values from * TFTP config UpLoad File * SNMP UpLoad file.
|
CSCds10270
|
When a OC-12 feeder trunk is configured as 1+1 unidirectional mode, the PXM-622 OC-12 line had no option to specify "working" or "protection" line would be applied upon an external request.
|
CSCds10279
|
Request for user-friendly APS status information.
|
CSCds10286
|
The PXM displays the incorrect error message when trying to switch APS line using switchapsln CLI.
|
CSCds10287
|
An APS protection switch has occurred because of line alarm. When the status of dsptrks and dspalms are checked, they indicate that the lines are clear.
|
CSCds10377
|
When one of the OC-12/OC-3 lines are in alarm, the CLI dspapsln shows the line status as "ALM" instead of specifically indicating LOS/LOF.
|
CSCds10765
|
Software error 20304 was observed during resetsys/switchcc.
|
CSCds11679
|
No known workaround. To be fixed in later releases.
|
CSCds12647
|
From Cisco WAN Manager, v9.2.07, Connection Manager, customer tries to create a new NRTVBR3 connection on MGX 8850. There are three passwords: login, password, and RPM enable password.
|
CSCds13629
|
Issue clrallcnf on PXM, RPM-PR failed to erase the connection setup in NVRAM.
|
CSCds14812
|
During a switchcc, the AUSM Secondary active card LEDS show LOS for a while.
|
CSCds15610
|
PXM takes long time (10+ mins) to reprogram the connections after power recycle.
|
CSCds15835
|
When a user configures a CESM-T3 or E3 line in a local loopback, the dspalm display does not indicate that the loopback is configured on the line.
|
CSCds16990
|
When issuing clrsmcnf, an "auto:upLoadBram, Read file failure" can be seen on screen.
|
CSCds17001
|
Log file cannot be found for a particular slot.
|
CSCds18374
|
Reset of an FRSM-HS2 card corrupted the PXM card type matrix and it started displaying improper card types.
|
CSCds18459
|
The help string shows an incorrect value for the line rate.
|
CSCds18513
|
Error message while configuring the line rate gave a misleading reason for failure.
|
CSCds18524
|
Addcon help for CIR shows a range greater than the possible line rate.
|
CSCds18760
|
Local Connection ID returns wrong VPI on the slave side of addcon.
|
CSCds19141
|
The card goes into mismatched after the CLI cnfbctype.
|
CSCds19155
|
The tstcon passes for a deleted side of connection.
|
CSCds19333
|
The port loopbacks trap are not generated when the loopback is initiated using BERT.
|
CSCds19363
|
Details on this anomaly is not available at this time.
|
CSCds19477
|
Details on this anomaly is not available at this time.
|
CSCds19934
|
Port is generating a large number of async updates when the connection is made up/down.
|
CSCds20497
|
An alarm is not raised by the slave end when the corresponding master end is deleted.
|
CSCds25261
|
SNMP trap to indicate ILMI failure on AUSM card causes HP OpenView to crash.
|
CSCds25992
|
The command cnfplpp configures a line even when the line has not been added/enabled.
|
CSCds28525
|
The alarm status for the connection shown at CESM and PXM do not match. The CLIs tstcon and tstdelay fails for these connections.
|
CSCds38687
|
FRSM-8T1/E1 takes Invalid (lesser) no. of parameters in the addcon CLI and does not display any error message.
|
CSCds47676
|
When the clock level is configured to be STRATUM-3, the PXM trunk card does not receive the STRATUM-3 clock signal. The trunk card still gets the STRATUM-4 clock.
|
CSCds47699
|
The cnfupcvbr setting incorrect default ingress %util when parm=0.
|
CSCds47719
|
The xdspconstdabr and xdspcon displayed the contents of the first channel, when the channel number was given without the "-chn" prefix.
|
CSCds48610
|
Neither the VBR connections are getting higher bandwidth even when it has higher Maxbwinc values than CBR and ABR VCC's.
|
CSCds48615
|
The VBR connections are not getting a higher bandwidth even though their CLP-high and CLP-Low values are changed to Q-Max.
|
CSCds51198
|
RPM-PR crashes in boot mode when in dir c:
|
CSCds52875
|
The value of Maxbwinc is reset to 0 after this action and hence traffic is stopped.
|
CSCds52894
|
Maxbwinc in all queues can total up to more than 512; however, if the rtVBR queue set to Algorithm 3, the Minbwinc in nrtVBR, ABR, and UBR were set to 0; the rtVBR Minbwinc= 447.
|
CSCds53841
|
There are six type options available to set the CoS. No ConnServiceType option for rtVBR.
|
CSCds56829
|
After switchcc the Standby PXM back card still displays on.
|
CSCds59688
|
CESM/T3 & CESM/E3 failed to upgrade to 10.0.20 version.
|
CSCds60827
|
The FRSM 2CT3 VCCs were configured with CBR and CIR=4240.
|
CSCds63641
|
FRSM/T1 in an MGX1 Feeder node, added 470 CBR VCCs on port 1 with script.
|
CSCds64800
|
The FRSM/2T3 card was in Active, with 200 VCCs.
|
CSCds65754
|
Both PXM modules stuck in boot mode.
|
CSCds78615
|
Redundant PXM goes into failed state when restoring SM configuration.
|
CSCds81277
|
Adding a slave connection on FRSM-HS1/B returns a wrong Local Connection ID.
|
CSCds81743
|
A system error 21205 is sometimes seen after invoking a switchcc.
|
CSCds82088
|
The clrsmcnf gives wrong error message when the card is not present.
|
CSCds82667
|
Ports are Alarms Free when line and channels are on Alarms.
|
CSCds82670
|
delchans causes Telnet session to freeze.
|
CSCds83090
|
The clrsmcnf times out when deleting a non-existent port on FRSM-8E1.
|
CSCds83131
|
The clrsmcnf fails after a Service Module is replaced with an RPM.
|
CSCds83554
|
When doing a graceful upgrade, a system error is sometimes seen.
|
CSCds83584
|
The savesmcnf/restoresmcnf are not blocked for RPM cards even though the commands are not supported.
|
CSCds84695
|
Display for slot 14 disappears in MGX 8230.
|
CSCds85934
|
Restoring the SMs configuration takes a long time (8 to 20 mins) using CLI restoresmcnf <slot #>.
|
CSCds86720
|
One end of Frame Forwarding connection is permanently on Alarm.
|
CSCds86780
|
The dspcd, dspln, dsplns, dspport, dspports, dspcon, dspcons commands never prompt after adding multiple 3 segment connections.
|
CSCds87189
|
The RcvLOS count toggles between 0 and 252.
|
CSCds89200
|
SYSTEM ERROR 20301 logged after deleting a frame forwarding port.
|
CSCds89508
|
Able to configure the port N393 timer values less than N392.
|
CSCds89838
|
The delchans command causes SYSTEM ERROR 20404.
|
CSCds90056
|
DAX connections on FRSM-HS1/B are free of alarms after removing one of the two cards used to establish those connections.
|
CSCds91080
|
The addport command with wrong port type causes Data Bus Error.
|
CSCds92204
|
System Error 20617 caused by delchans command.
|
CSCdt00596
|
The dspcons command display is not aligned on FRSM-HS2
|
CSCdt00613
|
The dlecon or delchans commands when deleting connections cause System Error 20300.
|
CSCdt03252
|
The tstcon and tstdelay fail for the CESM-T3 to CESM-T3 three-segment connection.
|
CSCdt03580
|
Ungraceful upgrades of AUSM-8E1 sometimes fail when the configuration for the SM is lost. This problem occurred once.
|
CSCdt05474
|
A bit alarm on a three-segment connection is not propagated from PXM to FRSM-2T3
|
CSCdt05984
|
The xcnfchan command does not display the setup options correctly.
|
CSCdt07206
|
On a PXM to PXM feeder connection, when doing a dspchancnt on the ATM port side of the connection, "Discard Cells to Port" shows that cells have been discarded.
|
.
Features Introduced in Release 1.1.3x
For descriptions of the features introduced in Release 1.1.3x, see the following sections:
•CoS Map for FRSM-8.
•DS3 Loopback on PXM-T3.
•Stratum-3 Clocking
•ForeSight and Standard ABR Coexistence Guidelines.
•Independent Service Rate on FRSM-HS1/B.
•Online Diagnostics for PXM.
•SRM in MGX 8230.
•Standard ABR on AUSM.
•Standard ABR on FRSM-8 and FRSM8-C Modules.
•VBR-rt on AUSM.
•VISM 1.5.05 on MGX 8250/8850.
•This feature provides a mechanism for graceful upgrades. By enabling this feature, no new calls are allowed on the VISM while not disrupting the existing calls. Eventually, when there are no more active calls, the card is ready for a upgrade and/or service interruption..
CoS Map for FRSM-8
This feature implements the ATM Class of Service (CoS) on the FRSM-8 Module. This feature maps the connection with ATM Class of Service parameters to the appropriate queue in the ingress side of the FRSM-8 and PXM.
Previous versions do not support any CoS type of connections; only ForeSight and non-ForeSight type connections are supported. By mapping the CoS parameters, the connections can then be scheduled in the appropriate queue on the PXM.
The following service types are added to the existing service types: UBR, VBR, VBR-RT, VBR-nRT, and STD-ABR. The current limit on connection count is to be retained as far as possible. This feature is supported by CWM 10.4 (which is not targeted for General Availability).
DS3 Loopback on PXM-T3
This feature enables the active PXM to initiate the DS3 loopback code (program the T3 framers to generate the sequence of 16 bit FEAC codes, or Far End Alarm and Control codes). The main functions are:
•Send alarm or status information from the far-end terminal back to the near-end terminal.
•Initiate DS3 loopbacks at the far-end terminal from the near-end terminal.
The active PXM will initiate this code, which will also run on the standby PXM. This feature has CLI support and is supported by CWM 10.3 (which is not targeted for General Availability).
Stratum-3 Clocking
The Stratum-3 Clocking feature is not supported in Releases 1.1.34 or 1.1.40. Standard clocking in the MGX is supported with a built-in Stratum-4 clock source. For network applications that require a higher clock accuracy, the PXM-UI back card used with the Stratum-4 can be replaced with an optional PXM-UI-S3 back card that carries a Stratum-3 clock. This clock reference conforms to AT&T T1.5 and ITU G.824 specifications. A provision is also made for a Service Provider to connect an external clock source, if necessary.
Both holdover and fail-over modes are supported by the PXM-UI-S3. That is, if all clock sources fail, the Stratum-3 clock will hold the last best-known clocking frequency.
The default clock is the internal Stratum-4. Pertinent CLI and MIB support are provided for Stratum-3 configuration. The PXM-UI-S3 back card is also recognized by the Cisco WAN Manager.
Hardware Changes
A new PXM-UI-S3 back card replaces existing PXM-UI-B cards.
The new PXM-UI-S3 supports both T1 and E1 interfaces through an RJ-45/48 connector.
CLI
A new CLI cnfclklevel permits the user to set the STRATUM level desired.
Default Settings
The default clock source is set to be the Internal Oscillator. Subsequently, an External/Inband/SM clock can be configured to be the primary/secondary clock driving the node.
Limitations
There are two physical ports on the PXM-UI-S3 back card for providing External clock. However, only "Ext Clk 1" is currently supported. There are 2 physical LAN ports on the PXM-UI-S3 back card. However, only "LAN port 1" is currently supported.
Warning If an External clock was configured to drive the node in Stratum-4 clocking with the old UI back card, and this UI card is replaced with the new PXM-UI-S3 back card, the Stratum-3 clocking must be explicitly configured on the node to continue using the External clock source. The following CLI's must be executed:
* cnfclklevel 3
* cnfextclk (with T1/E1 option)
ForeSight and Standard ABR Coexistence Guidelines
With Release 1.1.3x, both ABR TM4.0 and ForeSight congestion control are supported on the FRSM and AUSM modules. This document contains the following:
•Description of the major differences between the TM 4.0-compliant standard ABR and ForeSight ABR.
•Guidelines for coexistence of ForeSight with standard ABR connections on the same network.
•Example configuration of the two different connection types to have similar characteristics.
Independent Service Rate on FRSM-HS1/B
This feature provides the capability to configure a connection service rate in the ingress direction. Users can also specify EIR if connection is "0" of CIR. This feature is already implemented in FRSM-8 and FRSM-VHS.
This functionality is the same as that provided in FRSM-8 and FRSM-VHS. This feature is not supported by CWM 10.3 (which is not targeted for General Availability).
Online Diagnostics for PXM
This feature provides hardware tests to check the health of the SRM and PXM modules (both active and standby). This test is non-intrusive and operates with minimum overhead while the shelf is running. Connections, states and tasks are not affected.
The Online Diagnostics are optional tests operated through CLI and SNMP interfaces. The test is invoked from the active PXM. If a standby PXM exists and is in standby state, it also will be tested. When the test is executed, each component is checked and the results are presented on the screen. The results of the diagnostics are written to a log file so they can be viewed and analyzed offline.
Initially, intelligence is not provided, but built-in intelligence may be considered as a future enhancement. The hardware and software components selected for running the diagnostics will be selected from field experience. The targets are hard disk and memory components. Although the intent is to check the health of the hardware, a switchover should not occur except under severe circumstances.
SRM in MGX 8230
This feature provides SRM support in the MGX 8230. Only the newest version of the SRM, MGX-SRM-3T3/C, is supported in the 8230 chassis. This feature is not supported by CWM 10.3 (which is not targeted for General Availability), but is planned for a future release.
Standard ABR on AUSM
This feature involves implementing the standards-based TM 4.0 ABR congestion control loop. The current AUSM-8 card only supports ForeSight, which is pre-standards-based. Standard ABR is required on AUSM cards in order for them to interoperate with third-party devices that support standard ABR and AXSM cards.
Support for standard ABR calls for implementing the RM cells to perform the flow control. All three modes are considered: EFCI, ER, and RR. Only modes that can be supported on the existing hardware are implemented. In addition, all appropriate behaviors are implemented. These behaviors include Source, Destination, and Switch. Connections with the standard ABR parameter are mapped to the appropriate queue. This feature includes new CLI and MIB support. Also expected for the CWM support is the appropriate formula. Due to current hardware limitation, VS/VD is not considered. This feature is supported by CWM 10.3 (which is not targeted for General Availability).
Standard ABR on FRSM-8 and FRSM8-C Modules
The feature implements TM 4.0 ABR service on the FRSM card. The current FRSM supports ForeSight, a pre-standard version of congestion control. This feature provides standards-compliant ABR congestion mechanism in addition to ForeSight. The module will generate RM cells to dynamically increase or decrease bandwidth rate. This includes all applicable modes of behavior: Source, Destination, and Switch. Only relevant modes need be considered. Connections with the standard ABR parameter will be mapped to the appropriate queues and will co-exist with ForeSight connection types.
This feature is implemented via appropriate MIBS and CLI. This feature is supported by CWM 10.3 (which is not targeted for General Availability). ABR license (similar to ForeSight license) is created and is a billable feature. One common license is available for either ForeSight or standard ABR on FRSM. Standard ABR fulfils the standards-compliance part of TM 4.0.
VBR-rt on AUSM
This feature involves implementing the standard Class of Service on the AUSM-8 Module. VBR-rT CoS is required for video and real time voice applications. In terms of conformance definition it is same as VBR-nRT, which is already supported. The connection parameters will be bounded by Peak Cell rate (PCR), Sustainable Cell Rate (SCR) and Maximum Burst Size (MBS). Cell Delay Variation Tolerance (CDVT) will be parameter to characterize the PCR.
This new CoS requires scheduling the appropriate queue in both the ingress and egress direction. It has lower priority than CBR but higher than VBR-nRT.
Appropriate CLI commands to configure the parameters are implemented. This feature is supported by CWM 10.3 (which is not targeted for General Availability).
•
VISM 2.0.0 on MGX 8230/8250/8850
VISM 2.0.0 supports all of the VISM 1.5.05 features listed above. VISM 2.0.0 is supported on MGX 8230/8250/8850. CWM 10.3 (which is not targeted for General Availability) supports VISM 2.0.0. VISM is not targeted for General Availability.
PRI Backhaul to the Softswitch Using RUDP
The PRI backhaul capability provides PRI termination on the VISM with the Softswitch providing call control. ISDN Layer 2 is terminated on the VISM and the layer 3 messages are transported to the Softswitch using RUDP.
Latency Reduction (<60 ms round-trip)
Significant improvements have been made to bring the round-trip delay to less than 60 ms.
Codecs Preference
VISM provides the capability to have the codecs negotiated between the two end-points of the call. The VISM can be configured, for a given end-point, to have a prioritized list of codecs. Codec negotiation could be directly between the end-points or could be controlled by a Softswitch
31 DS0 for E1 with 240 Channels Only
While all 31 DS0s on a E1 port can be used, there is a limitation of 240 channels per card.
VISM 1.5.05 on MGX 8250/8850
VISM 1.5.05 is supported on MGX 8250/8850. For VISM on MGX 8230, please use VISM 2.0.0 listed below. CWM 10.3 (which is not targeted for General Availability) supports VISM 1.5.05. VISM is not targeted for General Availability.
VoIP using RTP (RFC 1889)
VISMR1.5 supports standards-based VoIP using RTP (RFC1889) and RTCP protocols. This allows VISM to interwork with other VoIP Gateways.
VoAAL2 (With sub-cell multiplexing) PVC
The VISM supports standards-compliant AAL2 adaptation for the transport of voice over an ATM infrastructure. AAL2 trunking mode is supported.
Codec Support
G.711 PCM (A-law, Mu-law), G.726, G.729a/b
8 T1/E1 Interfaces
The VISM supports 8 T1 or 8 E1 interfaces when G.711 PCM coding is used. For higher complexity coders such as G.726-32K and G.729a-8K, the density drops to 6 T1 or 5 E1 interfaces (max 145 channels).
1:N redundancy using SRM.
T3 Interfaces (via SRM Bulk Distribution)
T3 interfaces are supported using the SRM's bulk distribution capability. In this case, the T3 interfaces are physically terminated at the SRM module. The SRM module breaks out the individual T1s and distributes the T1s via the TDM backplane bus to the individual VISM cards for processing.
Echo Cancellation
The VISM provides on-board echo cancellation on a per-connection basis. Up to 128 msec. user-configurable near-end delay can be canceled. The echo cancellation is compliant with ITU G.165 and G.168 specifications.
Voice Activity Detection (VAD)
VISM uses VAD to distinguish between silence and voice on an active connection. VAD reduces the bandwidth requirements of a voice connection by not generating traffic during periods of silence in an active voice connection. At the far-end, comfort noise is generated.
Fax/Modem Detection for ECAN and VAD Control
The VISM continually monitors and detects fax and modem carrier tones. When carrier tone from a fax or modem is detected, the connection is upgraded to full PCM to ensure transparent connectivity. Fax and modem tone detection ensures compatibility with all voice-grade data connections.
CAS Tunneling via AAL2 (For AAL2 Trunking Mode)
The VISM in AAL2 mode facilitates transport of CAS signaling information. CAS signaling information is carried transparently across the AAL2 connection using type 3 packets. In this mode, VISM does not interpret any of the signaling information.
PRI Tunneling via AAL5 (For AAL2 Trunking Mode)
VISM supports transport of D-ch signaling information over an AAL5 VC. The signaling channel is transparently carried over the AAL5 VC and delivered to the far-end. In this mode, VISM does not interpret any of the signaling messages.
Voice CAC
VISM can be configured to administer Connection Admission Control (CAC) so that the bandwidth distribution between voice and data can be controlled in AAL2 mode.
Type 3 Packet for DTMF
The VISM in AAL2 mode facilitates transport of DTMF signaling information. DTMF information is carried transparently across the AAL2 connection using type 3 packets.
Dual (Redundant) PVCs for Bearer/Control
The VISM provides the capability to configure two PVCs for bearer/signaling traffic terminating on two external routers (dual-homing). VISM continually monitors the status of the active PVC by using OAM loopback cells. Upon detection of failure, the traffic is automatically switched over to the backup PVC.
64 K Clear Channel Transport
The VISM supports 64 Kbps clear channel support. In this mode, all codecs are disabled and the data is transparently transported through the VISM.
DTMF Relay for G.729
In VoIP mode, DTMF signaling information is transported across the connection using RTP NSE (Named Signaling Event) packets
MGCP 0.1 for VoIP with Softswitch Control
VISM supports Media Gateway Control Protocol (MGCP) Version 0.1. This open protocol allows any Softswitch to interwork with the VISM module.
Resource Coordination via SRCP
Simple Resource Control Protocol (SRCP) provides a heartbeat mechanism between the VISM and the Softswitch. In addition, SRCP also provides the Softswitch with gateway auditing capabilities.
Full COT Functions
VISM provides the capability to initiate continuity test as well as provide loopbacks to facilitate continuity tests when originated from the far-end.
Courtesy Down
This feature provides a mechanism for graceful upgrades. By enabling this feature, no new calls are allowed on the VISM while not disrupting the existing calls. Eventually, when there are no more active calls, the card is ready for a upgrade and/or service interruption.
Problems Fixed in Release 1.1.3x
Bug ID
|
Description
|
*CSCdk82484
|
RPM Interface Software Inoperable in SweetPea node
|
CSCdk94100
|
ILMI signalling on AUSM-8T1 port does not work as it is expected
|
CSCdm06097
|
While SM is in a mismatch state, and switchcc occurs, the log file gets cluttered
|
CSCdm20583
|
PXM CLI:Unclear error message for dspcd command
|
CSCdm31793
|
Connections on the PXM does not go to fail state though channel is in alarm.
|
CSCdm41079
|
CESM does not put out a D4/AMI signal when line is configured as such
|
CSCdm55480
|
Flash download to be guarded against Soft Resets
|
CSCdm69318
|
FRSM-2CT3 stuck in boot if switchcc performed while FRSM is resetting
|
CSCdm84982
|
Additional information for test delay in CM GUI is wrong
|
CSCdp03640
|
dspshelf shows fan for 8830 that are not a option for the MGX8830 shelf
|
CSCdp11502
|
AUSM UBR1 cons modification though proxy fail with error Wrong Egress Service
|
CSCdp15496
|
Platform feature needs a password to turn on
|
CSCdp17122
|
Softswitch accepts invalid slot numbers as parameters
|
CSCdp23328
|
Inconsistency between syntax used for dspln vs dsplns
|
CSCdp30538
|
PXM hung when it did a CNTRL C while executing mem memShow command from conso
|
CSCdp31043
|
dspalm on FRSM-HSSI card need the x21 as the interface type for HSSI interface
|
CSCdp35123
|
Added user-id under ANYUSER group disappears after a few minutes
|
CSCdp37528
|
Duplicate 50045 traps
|
CSCdp38293
|
dspcd on SRM displays b/c 800 # as f/c 800 #
|
CSCdp41488
|
Trap 50037, secLineModuleMismatchTrap, is not generated
|
CSCdp42525
|
dsfwrevs command does not show boot code versions
|
CSCdp43643
|
AUSM card becomes active in a particular slot but card is not shown by the PXM
|
CSCdp45431
|
dspcurclk does not update from ext clock to int osc when ext clock fails
|
CSCdp46345
|
When the Active PXM back card pulled out PXM did not switchover
|
CSCdp51956
|
We need online diagnostics to check the health of PXMs.
|
CSCdp57090
|
E1 external clock config reverts to T1 after resetsys
|
CSCdp57673
|
Incorrect trap Status for RPM card removal Trap 50002
|
CSCdp60418
|
Invalid response accepted by CLI when burning bootcode
|
CSCdp66005
|
Conns. remain in alarm even after port alarm gets cleared
|
CSCdp69136
|
Failure of TFTP of ComMat.dat file
|
CSCdp69188
|
PXM returns invalid MIB version to SNMP query
|
*CSCdp70729
|
SNMP set switchCoreCard fails on popeye
|
CSCdp71073
|
After softswitch, wrong slot number used for some log msgs
|
CSCdp77492
|
1.1.22-inconsistency in behavior of ports with local loops
|
CSCdp91401
|
Cannot BERT Test AUSM card with defined IMA port/s
|
CSCdp97387
|
cnfegrqs is working in the FRQ, when it should show an error.
|
CSCdp99436
|
? shows dspportstats as command but there is no such command
|
CSCdr05045
|
Trap varbinds missing in ChanOAMLpbkStatus Trap 50311
|
CSCdr07250
|
APS:Lower priority external request asserted after higher priority req clears
|
CSCdr08987
|
APS:SDBER > 7 on line 4 causes PXM hang/reboot 1.1.22Ll
|
CSCdr09138
|
PortState declares Active when the line failed with yellow alarm.
|
CSCdr09927
|
Invalid varbind (imaPortState) value received for trap 50231:trapImaActive
|
CSCdr12555
|
Support for ZERO CIR connections...
|
CSCdr15892
|
1.1.22Ln:addlnloop on PXM results in line alarms, sometimes persistently
|
CSCdr17560
|
1.1.22Ln:Shelf reset due to the Root task [tSNMPAgent]
|
CSCdr18819
|
CLI display misalignment after adding a connection in PXM.
|
CSCdr19336
|
Not able to configure cnfchansrvrate after cnflnsubrate for zero cir
|
CSCdr21154
|
dsplog indicates date as 00 instead of 01 for frsm-8t1e1
|
CSCdr22345
|
Voice call gets dropped after switchcc when Secondary SM is Active
|
CSCdr22910
|
dspfst displays incorrect msgs
|
CSCdr23908
|
1.1.22Ln:Event log does not show FRSM-2CT3 conns in/out of alarm
|
CSCdr33265
|
dir bootflash:did not show the correct date. (auto)
|
CSCdr35833
|
Both stdby and active AUSMs rebooted after softswitch
|
CSCdr36153
|
Creating/clearing an LOS condition on aps P_line causes mult Fail/OK
|
CSCdr38808
|
ds3 loopback feature
|
CSCdr41646
|
PXM card reset, no traps indication of the state of the SRMs
|
CSCdr42000
|
rmCnfChangeUpdate():rmArchDbWrite fails when doing clrsmcnf
|
CSCdr43004
|
Card fails when IMA line set for loop timing and cnfbert local loop initiated
|
CSCdr43525
|
Port LCN used remains at 0 during add/delete of PXM port 34 management cons.
|
CSCdr45284
|
No slot-no check on clrsrmcnf command
|
CSCdr46692
|
Max port BW needs to be configurable on PXM UNI interfaces
|
CSCdr46699
|
Need to change the default VC/QBIN/VI thresholds to enable rate-based scheduling
|
CSCdr47445
|
bootChange netmask overrides cnfifip ethernet netmask on standby PXM.
|
CSCdr48918
|
AUSM:When clocking PXM from IMA line, line # must be same as IMA group #
|
CSCdr50184
|
clrsmcnf on rpm -resets rpm inspite of clrsmcnf not being supported on RPM
|
CSCdr56159
|
No trap sent when delln -sonet 8.3 on PXM on slot 8
|
CSCdr58168
|
After a switchcc, some of the lines in the IMA group becomes unavailable
|
CSCdr58663
|
restoresmcnf is not working even after SM redundancy is deleted
|
CSCdr59398
|
PVCs got deleted on lsnca95 when VPI range was lower
|
CSCdr59813
|
Increase queue scheduler rate in proportion to logical port speed
|
CSCdr61374
|
CESM Structured channel toggling idle flag, low throughput
|
CSCdr61803
|
Aborting clrsmcnf with cntrl-c need to be handled properly
|
CSCdr63304
|
Port counter PortXmtSgmtLpbkCells not clear on clrportcnt
|
CSCdr63533
|
cnfbert for a remoteloopback on cesm-8t1e1 does not indicate the line in loop
|
CSCdr69994
|
Foresight parameters do not get updated on the hot standby
|
CSCdr70797
|
AUSM E1 remote loop function without SRM, also sends F5 OAM AIS cells upstream.
|
CSCdr70820
|
1.1.24 does not support MGX8230
|
CSCdr72963
|
PSU failure events does not appear on dsplog
|
CSCdr74393
|
APS bidirection non-revertive mode Interoperability does not work.
|
CSCdr76747
|
CNFBERT local loop and no loop records intermittent tst results on FRSM8E1
|
CSCdr76819
|
The PXM does not latch the clock properly.
|
CSCdr77088
|
APS Protection line oscillation causes the node to hang.
|
CSCdr80198
|
Online Diagnostics failing Framer Test
|
CSCdr81334
|
Fixes for ssi memory routines
|
CSCdr83869
|
Need CLI command to display trunk thru. put
|
CSCdr86099
|
NBTM:clrportcnts does not clear a counter for rtVBR Conn
|
CSCdr86885
|
Ingress frames are getting DE tagged at the FRSM port though DE tagging is OFF
|
CSCdr87800
|
PVCs can be added on reserved VPI/VCIs without WARNING message
|
CSCdr88653
|
ChanDEtoCLPmap:field in dspcon is failing to update properly
|
CSCdr89017
|
oldiags running out of file descriptors
|
CSCdr90273
|
MasterEnd of a conn gets added through remote FR port DLCI is unspecified
|
CSCdr90635
|
xcnfcon/xaddcon displays incorrect range for VPI/VCI fields
|
CSCdr90909
|
oldclralm syntax display on 8230 asking for slots 7,8
|
CSCdr95869
|
PXM1 does not handle 4k NvRam
|
CSCdr98433
|
A PXM log is required for addition and deletion of all SM redundancy
|
CSCdr98519
|
login, logout and all user commands must be in event log, disable thresholding
|
CSCds00987
|
The state of the rt-VBR connection is skewed by 3 characters when displayed
|
CSCds01023
|
xcnfportq with the option qa=0 disables the corresponding egress port Q
|
CSCds01417
|
Invalid range of parameter in dspportq and xdspportq
|
CSCds01472
|
Invalid MaxLcn in cnfrscprtn, cnfportrscprtn and xcnfrscprtn
|
CSCds03756
|
TFTP config upload file is missing chanServType MIB object
|
CSCds03905
|
Defaults to MGX8250 and MGX8230
|
CSCds04145
|
FRF.5 NIW Compliance wrt FR-SSCS DLCI value of 1022
|
CSCds04697
|
Traps not received after more than 700 subinterfaces been added
|
CSCds05006
|
delln -ds3 x.x on SRM does not return LineLoopback command to default
|
CSCds05374
|
addcon on service module without full syntax creates PVC with VPI/VCI 0/0
|
CSCds06755
|
Ausm xcnfilmi CLI command options do not match the usage
|
CSCds07411
|
Register in Framer should not be 0x00 - FEAC at remote end.
|
CSCds09808
|
mod RPM-400 connection traffic parameters not updated in rpm_connection
|
CSCds11325
|
Watchdog timeout reset on AUSM-8
|
CSCds11410
|
Remove the xcnfalmcnt command, as this is not supported in FRSM-8.
|
CSCds13806
|
dspfeature causes smto enter an infinite boot or failure state
|
CSCds18765
|
UPC for ABR connection to be done on MCR
|
CSCds22296
|
atmfAtmLayerMaxVciBits object returns incorrect value 12
|
CSCds22476
|
Ilmi request ID should be checked with the incoming pdu ID.
|
CSCds22479
|
If keep alive polling is enabled on the fly, ILMI doesn't fail.
|
CSCds22483
|
Addr. reg can be enabled, even if ILMI is disabled.
|
CSCds22489
|
Port retains ILMI failure, even after deleting ILMI.
|
CSCds23602
|
BERT pattern test fails to CESM and FRSM 8T1 sms
|
CSCds23604
|
xcnfilmi syntax states -VPI is 1-255 and should be 0-255
|
CSCds24045
|
Missing addcons from the RPM-PR
|
CSCds24602
|
Reset of AUSM-8e1 causes Scramble disabled line to misbehave
|
CSCds25992
|
Able to configure PLPP on a line which is disabled
|
CSCds26096
|
dspplpp shows port_num instead of phys_port_num
|
CSCds27682
|
dspalmcnt does not register BPVs
|
CSCds32838
|
Override CAC parameter cannot be enabled/disabled
|
CSCds35958
|
hs2 lines enter alarm state after running several hours
|
CSCds38406
|
SLT:after switchcc, the prompt for new active still show standby
|
CSCds49185
|
dspcds command hangs and telnet sessions are blocked thereafter
|
Related Documentation
Note that for Release 1.1.40, the product documents (Command Reference, Overview, and Installation and Configuration Guides) were not updated. Use the Release 1.1.3 documents in addition to the Release Notes for Cisco WAN MGX 8850, MGX 8230, and MGX 8250 Software Version 1.1.40.
Product documentation for MGX 8850 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8850/1_1_31/index.htm
Product documentation for MGX 8230 is available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8230/1_1_31/index.htm
Product documentation for MGX 8250 is available at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/mgx8250/1_1_31/index.htm
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Follow the instructions at the top of the documentation page, prompting you to "Click here" to link to the Documentaion Survey form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL:
http://www.cisco.com
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped 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 through an annual subscription.
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, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.
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:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining 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 by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
•Streamline business processes and improve productivity
•Resolve technical issues with online support
•Download and test software packages
•Order Cisco learning materials and merchandise
•Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL:
http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.
Inquiries to Cisco TAC are categorized according to the urgency of the issue:
•Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.
•Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
•Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.
•Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:
http://www.cisco.com/tac
All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:
http://www.cisco.com/register/
If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL:
http://www.cisco.com/tac/caseopen
If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.
To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
This document is to be used in conjunction with the Cisco WAN Switching MGX 8850 Release 1, MGX 8250, and MGX 8230 publications.
Copyright © 2002, Cisco Systems, Inc.
All rights reserved.
Feedback
